Data information type added

docs-gen/content/_index.md

@@ -19,19 +19,25 @@ A domain can in the HIM context be defined with the help of two dimensions:
 - 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.
     - Vehicle data
+    - Data
     - Service
     - Type definitions
 
 HIM specifies rule sets for the different information types that can then be used to define taxonomies for different coherent domains.
+A HIM taxonomy must conform to the rule set of one information type.
+Use case scenarios where multiple information types are needed must define these in separate taxonomies.
 
 The creation of taxonomies for different domains is not done within the HIM project, it is expected to be done by other projects using the HIM rule sets.
-One example of such a project is the [Vehicle Signal Specification](https://github.com/COVESA/vehicle_signal_specification) project.
+One example of such a project is the [Vehicle Signal Specification](https://github.com/COVESA/vehicle_signal_specification) taxonomy.
 
 The documentation is structured in the different rule sets shortly described below.
 
 ## 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 Data Rule Set
+[Rules](/hierarchical_information_model/data_rule_set/) for describing data that can be characterized as having either read-write or read-only properties.
+
 ## HIM Service Rule Set
 [Rules](/hierarchical_information_model/service_rule_set/) for describing services that can be represented by procedure signatures.
 
@@ -45,32 +51,37 @@ The documentation is structured in the different rule sets shortly described bel
 [Rules](/hierarchical_information_model/common_rule_set/) that are commonly used in the other rule sets.
 
 ## HIM profiles
-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 different profiles shown below.
-
-### 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.
+The abstraction level of a model describing 'data' is different from the abstraction level of a model describing 'services'.
+This is reflected in the different HIM rule sets.
+The API exposed by a server supporting access to 'data' or 'services' will also differ due to the abstraction level differencies.
+To support use case scenarios where only one of these two models are used HIM defines two profiles:
+* HIM Data Profile
+* HIM Service Profile
+
+The profiles are described below.
+HIM does not restrict use case scenarios / server implementations to support only one of the profiles.
+supporting both in parallel is a valid option.
+
+### HIM Data Profile
+The HIM data profile excludes use of taxonomies that represent the Service information type.
+This profile is for example compatible with the [VSS](https://github.com/COVESA/vehicle_signal_specification) taxonomy that represents vehicle data.
+A taxonomy representing 'user data', e. g. data of the driver of  vehicle, could use the HIM Data information type.
 
 ### HIM Service Profile
-The HIM Service profile excludes use of trees that contain the Vehicle data information type.
+The HIM Service profile excludes use of trees that contain the Vehicle data or Data information types.
 This profile can for example be used in "pure" SOA architectures.
 
-### 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 common syntax model that is used in both profiles makes it feasible to develop a server that can expose APIs
+for access to both data and services.
+
+HIM makes it possible to abstract both 'data' and 'service' information as data in an API.
+This eliminates the need to update the API when updating the respective taxonomies as the information is carried in the API payloads
+and do not require any updates of the static parts of the API.
 
-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.
+This is also the case if entire new taxonomies (domains) is introduced as the HIM model supports scenarios with multiple taxonomies.
+The [HIM configuration](/hierarchical_information_model/configuration_rule_set/)
+file enables these updates to be implemented without requiring server restart if that is desireable.
 
 ## Heritage
 The ideas behind HIM originated in the [COVESA VSS](https://github.com/COVESA/vehicle_signal_specification) project,

docs-gen/content/data_rule_set/_index.md

@@ -0,0 +1,15 @@
+---
+title: HIM Data Rule Set
+weight: 20
+chapter: true
+---
+
+# HIM Data Rule Set
+
+The rules that are specific for the information type `data` 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.
+
+This datatype is functionally equivalent with the `vehicledata` information type.
+However, for use cases where the vehicle specific information type may appear as not fitting for the context this datatype can be used.
+This could e. g. be the case when data related to a driver, or passenger, of a vehicle is to be described.
+Instead of using node types like `sensor` or `actuator` the node types `ro` and `rw` can be used.

docs-gen/content/data_rule_set/basics.md

@@ -0,0 +1,22 @@
+---
+title: "Data model"
+weight: 1
+---
+
+It is the leaf nodes of a tree that represents and defines the actual data.
+The definition is expressed by metadata describing the data samples associated to the node.
+
+## Node Types
+
+The node types for representing data entries are:
+- Ro: for data that is read-only.
+- Rw: for data that is read-write.
+
+Please see the respective chapters for more information about these node types.
+
+## Vspec YAML extensions
+
+The vspec format is based on YAML that is extended with two features described in respective chapters shown below.
+
+* [Instances](/hierarchical_information_model/data_rule_set/vspec_extensions/instances)
+* [Include](/hierarchical_information_model/data_rule_set/vspec_extensions/include)

docs-gen/content/data_rule_set/readonly.md

@@ -0,0 +1,34 @@
+---
+title: "Read-only node"
+weight: 30
+---
+
+This node type shall be used for data that can only be read and not written to. The HIM node type name is `ro`.
+
+Nodes of the type `ro` must have the following mandatory metadata:
+- Name
+- Type
+- Datatype
+- Description
+
+For more information, see the [Common Rule Set: Mandatory Metadata](/hierarchical_information_model/common_rule_set/basics#mandatory-metadata).
+
+Besides the mandatory metadata mentioned above, the following optional metadata may be used
+- Unit
+- Min
+- Max
+- Allowed
+- Comment
+
+For more information, please see the [Common Rule Set: Optional Metadata](/hierarchical_information_model/common_rule_set/basics#optional-metadata).
+
+This node type must have a node of type `branch` as parent, and must not have any children.
+
+An example of the specification of a `ro` node is given below.
+
+```YAML
+Name:
+  type: ro
+  datatype: string
+  description: The name of a vehicle occupant.
+```

docs-gen/content/data_rule_set/readwrite.md

@@ -0,0 +1,35 @@
+---
+title: "Read-write node"
+weight: 30
+---
+
+This node type shall be used for data that may be read or written. The HIM node type name is `rw`.
+
+Nodes of the type `rw` must have the following mandatory metadata:
+- Name
+- Type
+- Datatype
+- Description
+
+For more information, see the [Common Rule Set: Mandatory Metadata](/hierarchical_information_model/common_rule_set/basics#mandatory-metadata).
+
+Besides the mandatory metadata mentioned above, the following optional metadata may be used
+- Unit
+- Min
+- Max
+- Allowed
+- Comment
+
+For more information, please see the [Common Rule Set: Optional Metadata](/hierarchical_information_model/common_rule_set/basics#optional-metadata).
+
+This node type must have a node of type `branch` as parent, and must not have any children.
+
+An example of the specification of a `rw` node is given below.
+
+```YAML
+LocalTemperature:
+  type: rw
+  datatype: float
+  unit: Celsius
+  description: The vehicle occupant-local temperature setting.
+```

docs-gen/content/data_rule_set/vspec_extensions/_index.md

@@ -0,0 +1,11 @@
+---
+title: vspec extensions
+weight: 20
+chapter: true
+---
+
+## vspec extensions
+
+The vspec file format has he following feature extensions, see respective chapter for details.
+* Instances
+* Include

docs-gen/content/data_rule_set/vspec_extensions/include.md

@@ -0,0 +1,58 @@
+---
+title: "Include"
+date: 2019-08-04T12:59:44+02:00
+weight: 6
+---
+
+An include directive in a vspec file will read the file it refers to and the
+contents of that file will be inserted into the current buffer in place of the
+include directive.  The included file will, in its turn, be scanned for
+include directives to be replaced, effectively forming a tree of included
+files.
+
+See Fig 6 for an example of such a tree.
+
+![Include directive](/hierarchical_information_model/images/include_directives.png)<br>
+*Fig 6. Include directives*
+
+
+The include directive has the following format:
+
+    #include <filename> [prefix]
+
+The ```<filename>``` part specifies the path, relative to the file with the ```#include``` directive, to the vspec file to replace the directive with.
+
+The optional ```[prefix]``` specifies a branch name to be
+prepended to all signal entries in the included file. This allows a vspec file
+to be reused multiple times by different files, each file specifying their
+own branch to attach the included file to.
+
+An example of an include directive is:
+
+    #include doors.vpsec chassis.doors
+
+The ```door.vspec``` section specifies the file to include.
+
+The ```chassis.doors``` section specifies that all signal entries in ```door.vspec``` should have their names prefixed with ```chassis.doors```.
+
+If an included vspec file has branch or signal specifications that have
+already been defined prior to the included file, the new specifications in the
+included file will override the previous specifications.
+
+
+## REUSING SIGNAL TREES
+Complete subtrees of signals can be reused by including
+them multiple times, attaching them to different branches each time
+they are included.
+
+An example is given in Fig 7 where a generic door signal specification is
+included four times to describe all doors in the vehicle.
+
+![Include directive](/hierarchical_information_model/images/spec_file_reuse.png)<br>
+*Fig 7. Reusing signal trees*
+
+The ```door.vspec``` file is included four times by the master ```root.vspec``` file.
+The signals of ```door.vspec```, ```Locked```, ```WinPos```, and ```Open``` are attached
+on the front left and right doors of row 1 (front) and row 2 (back).
+
+If ```door.vspec``` is changed, the changes will be propagated to all four doors.