Merge pull request #2 from COVESA/master

Bring latest COVESA master into my fork

.github/workflows/buildcheck.yml

@@ -38,7 +38,7 @@ jobs:
       - name: Test mandatory targets
         run: |
           pipenv install
-          pipenv run make travis_targets
+          pipenv run make mandatory_targets
         env:
           PIPENV_PIPFILE: ./vss-tools/Pipfile
           PIPENV_VENV_IN_PROJECT: 1
@@ -54,7 +54,7 @@ jobs:
       - name: Test optional targets. NOTE - always succeeds
         run: |
           pipenv install
-          pipenv run make -k travis_optional || true
+          pipenv run make -k optional_targets || true
         env:
           PIPENV_PIPFILE: ./vss-tools/Pipfile
           PIPENV_VENV_IN_PROJECT: 1
@@ -73,7 +73,7 @@ jobs:
       - name: Deploy docs
         # Only deploy docs if this was a push to master
         if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/master' }}
-        uses: JamesIves/github-pages-deploy-action@4.1.4
+        uses: JamesIves/github-pages-deploy-action@v4
         with:
           branch: gh-pages # The branch the action should deploy to.
           folder: docs # The folder the action should deploy.

CHANGELOG.md

@@ -177,7 +177,10 @@ have been removed from the [VSS syntax](docs-gen/content/rule_set/data_entry/sen
 
 ## Planned Changes VSS 4.1
 
--
+
+### Deprecated or Deleted signals
+
+* `Vehicle.Cabin.Seat.*.*.Heating` deprecated from 4.1. New signal `Vehicle.Cabin.Seat.*.*.HeatingCooling` added.
 
 ## Planned Changes VSS 5.0
 

Makefile

@@ -2,24 +2,22 @@
 # Makefile to generate specifications
 #
 
-.PHONY: clean all travis_targets json franca yaml csv ddsidl tests binary protobuf ttl graphql ocf c install overlays
+.PHONY: clean all mandatory_targets json franca yaml csv ddsidl tests binary protobuf ttl graphql ocf c overlays
 
 all: clean json franca yaml csv ddsidl binary tests protobuf graphql overlays ttl
 
 # All mandatory targets that shall be built and pass on each pull request for
 # vehicle-signal-specification or vss-tools
-travis_targets: clean json franca yaml binary csv graphql ddsidl overlays tests tar
-
+mandatory_targets: clean json franca yaml binary csv graphql ddsidl overlays tests
 
 # Additional targets that shall be built by travis, but where it is not mandatory
 # that the builds shall pass.
 # This is typically intended for less maintainted tools that are allowed to break
 # from time to time
-# Can be run from e.g. travis with "make -k travis_optional || true" to continue
+# Can be run from e.g. travis with "make -k optional_targets || true" to continue
 # even if errors occur and not do not halt travis build if errors occur
-travis_optional: clean protobuf ttl
+optional_targets: clean protobuf ttl
 
-DESTDIR?=/usr/local
 TOOLSDIR?=./vss-tools
 
 json:
@@ -58,20 +56,6 @@ graphql:
 ttl:
 	${TOOLSDIR}/contrib/vspec2ttl/vspec2ttl.py -I ./spec -u ./spec/units.yaml ./spec/VehicleSignalSpecification.vspec vss_rel_$$(cat VERSION).ttl
 
-# Include all offically supported outputs (i.e. those created by travis_targets).
-# Exception is binary as it might be target specific and library anyway needs to be rebuilt.
-# As of today all artifacts generated for release shall include UUID if supported.
-# Note: From VSS 3.1 individual files are uploaded instead of tar file, but this command kept for now anyway
-tar:
-	tar -czvf vss_rel_$$(cat VERSION).tar.gz vss_rel_$$(cat VERSION).json vss_rel_$$(cat VERSION).fidl vss_rel_$$(cat VERSION).yaml \
-	vss_rel_$$(cat VERSION).csv vss_rel_$$(cat VERSION).graphql.ts vss_rel_$$(cat VERSION).idl
-
 clean:
+	rm -f ${TOOLSDIR}/binary/binarytool.so
 	rm -f vss_rel_*
-
-install:
-	git submodule init
-	git submodule update
-	(cd ${TOOLSDIR}/; python3 setup.py install --install-scripts=${DESTDIR}/bin)
-	install -d ${DESTDIR}/share/vss
-	(cd spec; cp -r * ${DESTDIR}/share/vss)

VERSION

@@ -1 +1 @@
-4.1-dev
+5.0-dev

docs-gen/content/rule_set/instances.md

@@ -10,11 +10,15 @@ quite often there is a need to repeat branches and data entries
 branches and data entries in the specification an instance-concept is supported.
 Instances remove the need of repeating definitions, by defining at the node itself how often it occurs in
 the resulting tree. They are meant as a short-cut in the specification and
-interpreted by the tools.
+interpreted by the tools. As an example is shown below for doors:
 
-![Example tree](/vehicle_signal_specification/images/instances.png?width=60pc)
+<!-- Image source in docs-gen/image_source/instance_tree.puml -->
+![Example tree](/vehicle_signal_specification/images/instance_tree.png)
 
+When expanded this corresponds to:
 
+<!-- Image source in docs-gen/image_source/instance_tree_expand.puml -->
+![Example tree](/vehicle_signal_specification/images/instance_tree_expand.png?width=60pc)
 
 ## Definition
 
@@ -25,26 +29,23 @@ interpreted by the tools.
 3. Instances are defined with the key-word `instances`, followed by its
    definition, which can be either:
    * a list of strings, where each element defines a single instance, e.g.
-     `['Left','Right']` results into two instances of every following
-     data entry in the path, named `Left` and `Right`
+     `['DriverSide','PassengerSide']` results into two instances of every following
+     data entry in the path, named `DriverSide` and `PassengerSide`
    * a string, followed by a range defined through `[n,m]`, with `n,m` as integer and `n <= m`,
      which defines the number of instances.
      `Position[1,4]` results into 4 instances of every following
      data entry in the path, named `Position1`, `Position2`, `Position3`
      and `Position4`. It is in VSS recommended to use `1` as start index for the first row/axle/position/...
 4. If multiple instances occur in one node or on the path to a data entry,
    the instances get combined, by the order of occurrence. Following the example above,
-   four position instances will be created for each of the 'Left' and 'Right' instances,
+   four position instances will be created for each of the 'DriverSide' and 'PasengerSide' instances,
    resulting into a total number of 8 instances.
 
 ### How can I exclude child-nodes from instantiation?
 
 Often it makes sense to instantiate all child-nodes of a branch.
-But there are cases, when nodes are linked more the general concept of
-a branch, but not to the single instance. This could be the `DoorCount`,
-which would rather be `Door.Count`, `WheelDiameter`, which is rather linked
-to an axle rather than the wheel itself or `Brake.FluidLevel` which is not
-measured for a single break, but rather a system indication.
+But there could be cases, when nodes are linked more the general concept of
+a branch, but not to the single instance.
 
 To exclude a child-node from the instantiation of the *direct* parent node, set the
 keyword `instantiate` to `false` (`true` by default). Please check the following
@@ -59,17 +60,16 @@ The example from above in the specification:
 Door:
   type: branch
   instances:
-    - Row[1,4]
-    - ["Left","Right"]
+    - Row[1,2]
+    - ["DriverSide","PassengerSide"]
   description: All doors, including windows and switches
 #include SingleDoor.vspec Door
 
-Door.Count:
+Door.SomeSignal:
   datatype: uint8
   type: attribute
-  default: 4
   instantiate: false
-  description: Number of doors in vehicle.
+  description: A door signal that should not be instantiated.
 ```
 
 
@@ -85,49 +85,32 @@ IsOpen:
   description: Is door open or closed
 ```
 
-Results in the following dot-notated output:
+Results in the following signals:
 
 ```
-Vehicle.Cabin.Door
-Vehicle.Cabin.Door.Count
-Vehicle.Cabin.Door.Row1
-Vehicle.Cabin.Door.Row1.Left
-Vehicle.Cabin.Door.Row1.Left.IsOpen
-Vehicle.Cabin.Door.Row1.Right
-Vehicle.Cabin.Door.Row1.Right.IsOpen
-Vehicle.Cabin.Door.Row2
-Vehicle.Cabin.Door.Row2.Left
-Vehicle.Cabin.Door.Row2.Left.IsOpen
-Vehicle.Cabin.Door.Row2.Right
-Vehicle.Cabin.Door.Row2.Right.IsOpen
-Vehicle.Cabin.Door.Row3
-Vehicle.Cabin.Door.Row3.Left
-Vehicle.Cabin.Door.Row3.Left.IsOpen
-Vehicle.Cabin.Door.Row3.Right
-Vehicle.Cabin.Door.Row3.Right.IsOpen
-Vehicle.Cabin.Door.Row4
-Vehicle.Cabin.Door.Row4.Left
-Vehicle.Cabin.Door.Row4.Left.IsOpen
-Vehicle.Cabin.Door.Row4.Right
-Vehicle.Cabin.Door.Row4.Right.IsOpen
+Vehicle.Cabin.Door.SomeSignal
+Vehicle.Cabin.Door.Row1.DriverSide.IsOpen
+Vehicle.Cabin.Door.Row1.PassengerSide.IsOpen
+Vehicle.Cabin.Door.Row2.DriverSide.IsOpen
+Vehicle.Cabin.Door.Row2.PassengerSide.IsOpen
 ```
 
 ## Redefinition
 
 It is possible to override the default instantiation provided by VSS by redefining the branch with
 different instantiation information. If multiple definitions of a branch exist with different
 instance definitions, then the last found definition will be used.
-As an example, if only two rows of doors are needed, then the default VSS instance definition
+As an example, if three row of doors are needed, then the default VSS instance definition
 can be overridden by redefining the Door branch as shown in the example below.
 
 ```YAML
-#Redefinition changing number of rows from 4 to 2
+#Redefinition changing number of rows from 2 to 3
 #The redefinition must appear "after" the original definition
 Vehicle.Cabin.Door:
   type: branch
   instances:
-    - Row[1,2]
-    - ["Left","Right"]
+    - Row[1,3]
+    - ["DriverSide","PassengerSide"]
   description: All doors, including windows and switches
 ```
 

docs-gen/image_sources/.gitignore

@@ -0,0 +1 @@
+*.png

docs-gen/image_sources/instance_tree.puml

@@ -0,0 +1,15 @@
+@startuml
+card "instances: \n  - Row[1,2] \n  - ["DriverSide","PassengerSide"]" as C111
+usecase Vehicle as N1
+usecase Cabin as N11
+usecase Door as N111
+usecase IsOpen as N1112
+usecase Window as N1111
+usecase IsOpen as N11111
+N1--> N11
+N11--> N111
+N111--> N1111
+N111--> N1112
+N1111--> N11111
+N111 - C111
+@enduml

docs-gen/image_sources/instance_tree_expand.puml

@@ -0,0 +1,53 @@
+@startuml
+
+usecase Vehicle as N1
+usecase Cabin as N11
+N1--> N11
+usecase Door as N111
+N11--> N111
+
+usecase Row1 as N111a
+N111-->N111a
+usecase Row2 as N111b
+N111-->N111b
+
+usecase DriverSide as N111aa
+usecase PassengerSide as N111ab
+N111a-->N111aa
+N111a-->N111ab
+
+usecase DriverSide as N111ba
+usecase PassengerSide as N111bb
+N111b-->N111ba
+N111b-->N111bb
+
+usecase IsOpen as N111aa2
+usecase Window as N111aa1
+usecase IsOpen as N111aa11
+N111aa-->N111aa1
+N111aa1-->N111aa11
+N111aa-->N111aa2
+
+usecase IsOpen as N111ab2
+usecase Window as N111ab1
+usecase IsOpen as N111ab11
+N111ab-->N111ab1
+N111ab1-->N111ab11
+N111ab-->N111ab2
+
+
+usecase IsOpen as N111ba2
+usecase Window as N111ba1
+usecase IsOpen as N111ba11
+N111ba-->N111ba1
+N111ba1-->N111ba11
+N111ba-->N111ba2
+
+usecase IsOpen as N111bb2
+usecase Window as N111bb1
+usecase IsOpen as N111bb11
+N111bb-->N111bb1
+N111bb1-->N111bb11
+N111bb-->N111bb2
+
+@enduml

spec/Body/Body.vspec

@@ -29,37 +29,25 @@ RefuelPosition:
 #
 Hood:
   type: branch
-  description: Hood status.
+  description: Hood status. Start position for Hood is Closed.
   comment: The hood is the hinged cover over the engine compartment of a motor vehicles.
            Depending on vehicle, it can be either in the front or back of the vehicle.
            Luggage compartments are in VSS called trunks, even if they are located at the front of the vehicle.
 
-Hood.IsOpen:
-  datatype: boolean
-  type: actuator
-  description: Hood open or closed. True = Open. False = Closed.
-
+#include ../include/MovableItem.vspec Hood
 
 #
 # Trunk description
 #
 Trunk:
   type: branch
   instances: ["Front", "Rear"]
-  description: Trunk status.
+  description: Trunk status. Start position for Trunk is Closed.
   comment: A trunk is a luggage compartment in a vehicle.
            Depending on vehicle, it can be either in the front or back of the vehicle.
            Some vehicles may have trunks both at the front and at the rear of the vehicle.
 
-Trunk.IsOpen:
-  datatype: boolean
-  type: actuator
-  description: Trunk open or closed. True = Open. False = Closed.
-
-Trunk.IsLocked:
-  datatype: boolean
-  type: actuator
-  description: Is trunk locked or unlocked. True = Locked. False = Unlocked.
+#include ../include/LockableMovableItem.vspec Trunk
 
 Trunk.IsLightOn:
   datatype: boolean

spec/Cabin/Cabin.vspec

@@ -16,10 +16,11 @@
 ##
 RearShade:
   type: branch
-  description: Rear window shade.
+  description: Rear window shade. Open = Retracted, Closed = Deployed.
+               Start position for RearShade is Open/Retracted.
 
 # Include the same shade spec used for sunroof and side windows.
-#include SingleShade.vspec RearShade
+#include ../include/MovableItem.vspec RearShade
 
 ##
 # HVAC signals
@@ -65,10 +66,11 @@ Sunroof.Switch:
 
 Sunroof.Shade:
   type: branch
-  description: Sun roof shade status.
+  description: Sun roof shade status. Open = Retracted, Closed = Deployed.
+               Start position for Sunroof.Shade is Open/Retracted.
 
 # Include shade specification also used by side and rear window.
-#include SingleShade.vspec Sunroof.Shade
+#include ../include/MovableItem.vspec Sunroof.Shade
 
 #
 # Rear-view mirror signals