Merge pull request #38 from UlfBj/master

Information type Data renamed to Vehicle data.

Author: UlfBj

README.md

@@ -24,6 +24,12 @@ that can be used to define tree structures representing information (see below)
 This repository is managed by the [COVESA Data Expert Group](https://wiki.covesa.global/display/WIK4/Data+Expert+Group),
 together with the [COVESA CVIS project](https://wiki.covesa.global/display/WIK4/CVIS+Meeting+Topics+and+Meeting+Notes).
 
+## Latest version
+[HIM version 1.0](https://github.com/COVESA/hierarchical_information_model/releases/tag/v1.0)
+
+## Previous versions
+None.
+
 ## HIM Overview
 
 The information of a domain that is described using HIM is represented in a graph made up of a tree structure with parent-child relationships,
@@ -38,14 +44,19 @@ This rule set aims at being domain agnostic and can thus be used to define the t
 Another ambition of HIM s that it shall support definition of taxonomies of different types of information,
 and not only the type here called "resource data".
 HIM currently supports the following "information types":
-- Resource data: Information defining the data that a resource produces or consumes.
-- Service data: Information defining the details of a "service" in the form of a procedure (name, input, output).
+- Vehicle data: Information defining the data that a vehicle produces or consumes.
+- Service: Information defining the details of a "service" in the form of a procedure (name, input, output).
 - Type definition data: Information defining complex/composite data types that are used by the other information types.
 
 HIM also provides a rule set for the definition of a "configuration file" that can be used by a HIM enabled data server in its management of
-a "forest" of multiple trees. This information can also by the server be provided to a client wanting to know what data or services the server
+a "forest" of multiple trees. This information can also by the server be provided to a client wanting to know what vehicle data or services the server
 has to offer.
 
+HIM uses profiles that defines subsets of the complete model.
+Currently the following profiles are defined:
+* Vehicle data profile: excludes the Service information type
+* Service profile excludes the Vehicle data information type
+
 What is not an ambition of HIM is to define how the information is transported between agents,
 which is left to projects defining transport protocols, interfaces, and the like.
 Neither is it aiming for defining the content of any tree, which is also left to other projects.

docs-gen/content/_index.md

@@ -18,7 +18,7 @@ A domain can in the HIM context be defined with the help of two dimensions:
   - Examples are a car, a truck, a trailer, an airplane, etc.,
 - an 'information type' dimension that is used in the description of a coherent dimension using a specific information type.
   - The currently defined information types are listed below.
-    - Data
+    - Vehicle data
     - Service
     - Type definitions
 
@@ -29,8 +29,8 @@ One example of such a project is the [Vehicle Signal Specification](https://gith
 
 The documentation is structured in the different rule sets shortly described below.
 
-## HIM Data Rule Set
-[Rules](/hierarchical_information_model/data_rule_set/) for describing data produced/consumed by resources that can be represented by static or dynamically changing data values.
+## HIM Vehicle Data Rule Set
+[Rules](/hierarchical_information_model/vehicle_data_rule_set/) for describing data produced/consumed by vehicles that can be represented by static or dynamically changing data values.
 
 ## HIM Service Rule Set
 [Rules](/hierarchical_information_model/service_rule_set/) for describing services that can be represented by procedure signatures.
@@ -49,28 +49,26 @@ The HIM model supports different information types,
 and a server exposing an interface that uses HIM for its data representation may have to implement features that its clients have no interest in.
 A server to be used in an environment where the Data type (i. e. classical signals) is used can then be
 implemented without support for a service oriented architecture (SOA).
-To support scenarios like this HIM specifies the three different profiles shown below.
+To support scenarios like this HIM specifies the different profiles shown below.
 
-A client that issues an inquiry on what profile is supported shall receive information on that in the response.
-
-### HIM Data Profile
-The HIM Data profile excludes use of trees that contain the Service data information type.
+### HIM Vehicle Data Profile
+The HIM vehicle data profile excludes use of trees that contain the Service information type.
 This profile is for example compatible with the VSS tree.
 
 ### HIM Service Profile
-The HIM Service profile excludes use of trees that contain the Data information type.
+The HIM Service profile excludes use of trees that contain the Vehicle data information type.
 This profile can for example be used in "pure" SOA architectures.
 
-### HIM All Profile
-The HIM All profile supports use of trees that contain data of any HIM specified information type.
+### HIM Complete Profile
+The HIM Complete profile supports use of trees that contain data of any HIM specified information type.
 This makes it possible for a server to serve clients that wants to have access to both "classical signals" and services represented by function calls.
 
 ## HIM enablers
 HIM enables a single server implementation to support use cases from multiple domains, e. g. telemetry via a tree such as the
 [COVESA VSS](https://github.com/COVESA/vehicle_signal_specification) tree,
 or diagnostics via a tree referring to diagnostics data, or trees describing the data or services of other domains.
 
-The same server can expose access to both data (signals) and services (procedures).
+The same server can expose access to both vehicle data (signals) and services (procedures).
 Instead of developing a new server and possibly also define a new interface when a new domain is to be served,
 a new tree containing the signals or services for the domain is created and linked to the server via the HIM configuration file.
 

docs-gen/content/configuration_rule_set/basics.md

@@ -36,15 +36,14 @@ Usage of a HIM configuration file is optional, but it is recommended in scenario
 
 The following node types can be used in a configuration tree:
 1. [Branch](/hierarchical_information_model/common_rule_set/node_types/branch/)
-2. [Direct](/hierarchical_information_model/configuration_rule_set/node_types/diect/)
+2. [Direct](/hierarchical_information_model/configuration_rule_set/node_types/direct/)
 3. [Proxy](/hierarchical_information_model/configuration_rule_set/node_types/proxy/)
 
 ## Configuration Tree Example
-This example shows a forest consisting of three local trees, and a remote tree:
+This example shows a forest consisting of three local trees:
 1. A local tree containing passenger car related signals, having the root node name VehicleData.
 2. A local tree containing passenger car related services, having the root node name VehicleServices.
 3. A local tree containing type passenger car related ype definitions, having the root node name Types.
-4. A remote tree containing charge station related signals, having the root node name ChargingStationData.
 
 ```YAML
 HIM:
@@ -54,10 +53,10 @@ HIM:
 
 VehicleData:
   type: direct
-  domain: Vehicle.Car.Data
+  domain: Vehicle.Car.VehicleData
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.VehicleData.X.Y.Z
   description:  ….
 
 VehicleServices:
@@ -73,14 +72,6 @@ Types:
   domain: Vehicle.Car.TypeDefinition
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.DataType.X.Y.Z
-  description:  ….
-
-
-ChargingStationData:
-  type: proxy
-  domain:ChargingStation.Vehicle.Data
-  version: X.Y.Z
-  public: https://himrepo.energyco.com?instance=ChargingStation.Vehicle.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.TypeDefinition.X.Y.Z
   description:  ….
   ```

docs-gen/content/configuration_rule_set/node_types/direct.md

@@ -61,9 +61,9 @@ An example of the specification of a `direct` node is given below.
 ```YAML
 HIM.Vehicle:
   type: direct
-  domain: Vehicle.Car.Data
+  domain: Vehicle.Car.VehicleData
   version: X.Y.Z
   local: file://<full-path-name>
-  public: https://himrepo.oem.com?instance=Vehicle.Car.Data.X.Y.Z
+  public: https://himrepo.oem.com?instance=Vehicle.Car.VehicleData.X.Y.Z
   description: This is a tree of type direct.
 ```

docs-gen/content/configuration_rule_set/node_types/proxy.md

@@ -66,7 +66,7 @@ The `local` points to a Unix domain socket for communication with a proxy server
 ```YAML
 HIM.Home:
   type: proxy
-  domain: HomeAutomation.Zigbee.Data
+  domain: HomeAutomation.Zigbee.Service
   version: X.Y.Z
   local: uds://path/to/uds-file
   description: Home automation proxy tree.

docs-gen/content/service_rule_set/_index.md

@@ -4,7 +4,7 @@ weight: 20
 chapter: true
 ---
 
-# HIM Service Data Rule Set
+# HIM Service Rule Set
 
 The rules that are specific for the information type `service` is described in this part of the document,
 and together with the rules in the [Common rule set part](/hierarchical_information_model/common_rule_set) it forms the overall rules for this information type.

docs-gen/content/data_rule_set/_index.md …/content/vehicle_data_rule_set/_index.mddocs-gen/content/data_rule_set/_index.md renamed to docs-gen/content/vehicle_data_rule_set/_index.md docs-gen/content/data_rule_set/_index.md renamed to docs-gen/content/vehicle_data_rule_set/_index.md

@@ -1,10 +1,10 @@
 ---
-title: HIM Data Rule Set
+title: HIM Vehicle Data Rule Set
 weight: 20
 chapter: true
 ---
 
-# HIM Data Rule Set
+# HIM Vehicle Data Rule Set
 
-The rules that are specific for the information type `data` is described in this part of the document,
+The rules that are specific for the information type `vehicledata` is described in this part of the document,
 and together with the rules in the [Common rule set part](/hierarchical_information_model/common_rule_set) it forms the overall rules for this information type.

…cs-gen/content/data_rule_set/actuator.md …ontent/vehicle_data_rule_set/actuator.mddocs-gen/content/data_rule_set/actuator.md renamed to docs-gen/content/vehicle_data_rule_set/actuator.md docs-gen/content/data_rule_set/actuator.md renamed to docs-gen/content/vehicle_data_rule_set/actuator.md

@@ -4,8 +4,8 @@ date: 2019-08-04T13:05:11+02:00
 weight: 1
 ---
 
-The rule set for Data is inherited from the [VSS rule set](https://covesa.github.io/vehicle_signal_specification/rule_set/).
-It is the leaf nodes of a tree that represents and defines the actual data.
+The rule set for vehicle data is inherited from the [VSS rule set](https://covesa.github.io/vehicle_signal_specification/rule_set/).
+It is the leaf nodes of a tree that represents and defines the actual vehicle data.
 The definition is expressed by metadata describing the data associated to the node.
 
 ## Node Types