Commercial Vehicle Information Specifications

Overview

The HIM rule set for signals is used in this project, and since it is identical to the VSS rule set this framework inherits “patterns” from VSS

• The vspec file format.
• The usage of VSS-tools to transform from the vspec format to other exporter formats.
• The CVIS signal trees are defined in two directory structures -

objects directory structure: This is where the common “tree objects” are stored that may be shared between multiple trees. trees directory structure: Thisis where the unique trees for different domains are stored.

The directory structure for a single tree follows the VSS pattern with “#include” links in the vspec files that logically links to other files of the tree. However, to link to a file in the common objects structure the corresponding file in the trees structure is realized as a symbolic link file. This means that when the content of the file is accessed the underlying file system follows the symbolic link to the file in the objects structure for the actual content of the file. This is transparent to the entity accessing the file, so e. g. the exporter tools from VSS-tools will when used for a transformation of a specific tree access file content from the common objects files tranparently.

Tree development

The HIM rule set for resource data is used to define signals in a tree. This syntax can be directly used as input to any of the exporter tools provided by VSS-tools.

HIM extensions

The HIM syntax is in this project extended with two features. These can be preprocessed by the HIM configurator which transforms them into a HIM compliant format, thus making it possible to use the SS-tools for exporting to other formats. If these extensions are found to be useful it is likely that they will become included in the HIM standard rule set for resurce data.

Variability configuration

The tree in vspec format may contain multiple variations of objects that in a deployment typically are not included. An example are the Combustion engine and the Electric engine. in an ICE vehicle the former should be included, but not the latter. For an EV vehicle it is vice versa. To enable one or the other of these objects to be included the following syntax is used, example taken from the Engine.vspec.

VariationPoint: #EngineType
  - ICE #include CombustionEngine.yaml Engine
  - EV  #include ElectricEngine.vspec Engine

The keyword is VariationPoint, which on the same line must be followed by a hash sign (#) directly followe by a unique variation point tag (in this case EngineType. The value part of this key-value expression is an array of ‘variability object expressions’, where such an expression contains a ‘variability name’ followed by an ‘#include expression’. This expression must be compliant with the syntax rules for HIM #include expressions. The array size is not restricted.

The input to the HIM configurator for it to resolve which variations to select is found in two files.

• The Variability.json file,
• and the himConfiguration.json file.

The Variability.json file defines the available variations, and which include statements that should be selected for the variation. As can be seen in th PHEV variation example below it is possible to select multiple include statements.

    "EngineType": [
        {
            "PHEV": [
                "ICE",
                "EV"
            ]
        }

The himConfiguration.json file contains the variation that that should be included in the tree that is generated by the himConfigurator (using a VSS-tools exporter), expressed by the rows below in this example:

    "variants": {
        "EngineType": "PHEV"

Instantiation configuration

The HIM rule set supports the instantiation syntax inherited from VSS instantiation that can be used to request the VSS-tools to generate multiple instances of a branch/set of signals. This syntax has two options exemplified below

• instances: [“DriverSide”, “PassengerSide”]
• instances: Row[1,2] The examples above can be extended to two dimensions by using the array syntax, e.g.

instances: 
    - Row[1,2]
    - ["DriverSide", "PassengerSide"]

which will generate a structure with four branches - Row1:DriverSide, Row1:PassengerSide, Row2:DriverSide, Row2:PassengerSide. It is however not possible to use this syntax to express a configuration where for Row1 there are two child nodes, e.g. [“DriverSide”, “PassengerSide”], and for Row2 there are three child nodes, e. g. [“DriverSide”, “Middle”, “PassengerSide”].

This missing flexibility is however provided in the extended syntax supported by the HIM configurator. A two-dimensional instantiation is then expressed in the vspec file as:

instances0: x #instanceTag
instances1: x #instanceTag

where ‘instances0’ is used for the ‘first-order’ instantiation (Row[1,2] in the example above), and ‘instances1’ is used for the ‘second-order’ instantiation ([“DriverSide”, “PassengerSide”] in the example above).

‘x’ is a placeholder for the instance expression in the file himConfiguration.json that is the input to the HM configurator, and ‘instanceTag’ is a unique name logically linking the two expressions, which must be preceded by a hash character (#). The two instance expressions can, but must not be on two subsequent rows. If not, then the second expression must be defined in any of the nodes that is part of the subtree under the node containing the first expression. The instance configuration input to the HIM configurator has a syntax as exemplified below.

    "instances": {
        "Seat": [
            "Row[1,2]",
            [
                [
                    "DriverSide",
                    "PassengerSide"
                ],
                [
                    "DriverSide",
                    "Middle",
                    "PassengerSide"
                ]
            ]
        ]
        }

The ‘Seat’ shown above is the instanceTag name that the HIM configurator will try to match in the vspec file.

The ‘first-order’ instantiation, in this case “Row[1,2]”, is followed by two ‘second-order’ instantiation expressions.

The number of ‘second-order’ expressions must match the number of instantiaions that the ‘first-order’ expression will expand to.

The expressions can use any of the two syntax options mentioned above.

Currently this syntax can only be used for two-dimensional instantiations.

Datatypes tree

One of the information rule sets that HIM supports is the type definition rule set. A type definition tree is able to define strutcs and enums (allowed) that can be referenced from trees of other information types. Such a tree is defined in the spec/objects/Datatypes directory, currently containing the enums (allowed) that is used in the VSS tree. This tree has a structure that mirrors the structure from the VSS tree where the enums were originally used. This structure might later be changed to a more generic structuring to yield reference path names more decoupled from the VSS structure.

An external datatype reference to an enum (allowed) shall have a syntax as shown below.

  datatype: Datatype.x.y.zValues

where x, y, z may be names providing an understanding of the defined enum (allowed) that conform to the node HIM node name syntax. The name z must be postfixed with the tag Values.

If the HIM configurator is used to substitute external enum (Allowed) references it will create a Datatype.yaml file in the root directory of the signal tree that it is working on. The node type in a type definition tree shall be ‘property’ but due to that the VSS-tools will reject separate trees with that node type, the node type ‘sensor’ is used instead. This must therefore be manually edited to rename to ‘property’ until a moodified version of VSS-tools is created, or that the HIM configurator is updated to handle the node type renaming.

Trees under development

Currently two trees are being developed:

• Tractor tree
• Trailer tree

HIM configurator

The framework also contains a new tool, the HIM configurator. In its current version it provides support for two types of tree configuration:

• Variation point configuration: If the tree defined by the vspec files contains data structures that are not typically used together in a specific deployment of the tree, then these can be tagged as a variability point, and the HIM configurator can be used to pick the desired structure(s).
• Instance configuration: This is an extension of the existing VSS-tools instance support that provides the possibility for a two dimensional instantiation to have unique “column instantiation” for each “row instantiation”.

Check out the HIM configurator chapter for more details.

If this new tool is found to be useful it is planned to add support for “default configuration” later.

Alignment with other standards

The terminology used in these HIM based specifications should try to align with terminology and principles from other standards. The cases that has been identified are described below.

Axle and tire locations

The ISO xxxx(number and link missing) specification includes a centerline based approach for commercial vehicles, see diagram below.

The ISO naming conventions shown in the figure above can be realized by providing the configuration shown below as input to the HIM configurator, and inserting the “instances0/1” directives in the related vspec files.

    "instances": {
        "Axle": [
            "Row[1,4]",
            [
                ["Pos7","Pos9"],
                ["Pos7","Pos9"],
                ["Pos6","Pos7", "Pos9","Pos10"],
                ["Pos8"]
            ]
        ]
    }

Further references, e.g. TMC VMRS, Fleet location codes, etc…