Introducing VSS 4.0

.github/workflows/kuksa_databroker-cli_build.yml

@@ -33,7 +33,7 @@ jobs:
 
     steps:
       - name: Installing JVM
-        run: sudo apt-get install -y default-jre
+        run: sudo apt update && sudo apt-get install -y default-jre
       - name: Install Protoc
         run: sudo apt-get install -y protobuf-compiler
       - uses: actions/checkout@v3

.github/workflows/kuksa_databroker_build.yml

@@ -33,7 +33,7 @@ jobs:
 
     steps:
       - name: Installing JVM
-        run: sudo apt-get install -y default-jre
+        run: sudo apt update && sudo apt-get install -y default-jre
       - name: Install Protoc
         run: sudo apt-get install -y protobuf-compiler
       - uses: actions/checkout@v3

data/vss-core/README.md

@@ -9,6 +9,7 @@ In addition older versions may be supported. This folder contains copies of all
 
 ## Supported VSS versions
 
+* [VSS 4.0](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v4.0)
 * [VSS 3.1.1](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v3.1.1)
 * [VSS 3.0](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v3.0)
 * [VSS 2.2](https://github.com/COVESA/vehicle_signal_specification/releases/tag/v2.2)
@@ -32,9 +33,22 @@ This is the process for introducing support for a new VSS version:
 * Check if examples needs to be updated due to changed signal names or syntax
 * Change build scripts and examples to use the new version as default
     * Search for the old version number and replace where needed
+    * Known suffixes to search for `vss_release_` include `*.md`, `*.sh`, `*.cpp`, `*.txt`, `*.ini`
+    * Also check all `Dockerfile`
+* Some files (`*.txt`) instead list all versions, there just add the new version
 * If needed, adapt or extend test cases to use the new version instead of previous version
 * Remember to also integrate new version in [KUKSA Feeder](https://github.com/eclipse/kuksa.val.feeders) repository
-    * Needed at least for dbc2val
+    * Needed for [dbc2val](https://github.com/eclipse/kuksa.val.feeders/blob/main/dbc2val/mapping/mapping.md)
+    * Needed for [dds2val](https://github.com/eclipse/kuksa.val.feeders/blob/main/dds2val/ddsproviderlib/idls/generate_py_dataclass.sh) 
+
+### Release Candidate Handling
+
+VSS-project has started to use release candidates. A possible approach to verify VSS release candidates is:
+
+Create Pull-Requests based on the release candidate. Copy the file "as official version" to kuksa.val/kuksa.val.feeders.
+I.e. even if version is `v4.0rc0` copy it as `v4.0`. Only where there is a formal reference to a VSS release/tag
+use the full name. When official release is created replace the copied *.json-file (if needed), regenerate derived files,
+(if any, currently only in kuksa.val.feeders), and update github links in this file.
 
 ## Tests after update
 
@@ -128,7 +142,7 @@ Test Client> getValue Vehicle.CurrentLocation.Latitude
 Build and run kuksa_databroker using the new VSS file according to [documentation](../../kuksa_databroker/README.md), e.g.
 
 ```sh
-$cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_3.1.1.json
+$cargo run --bin databroker -- --metadata ../data/vss-core/vss_release_4.0.json
 ```
 
 Use the client to verify that changes in VSS are reflected, by doing e.g. set/get on some new or renamed signals.

doc/KUKSA.val_server/usage.md

@@ -16,14 +16,14 @@ OPTIONS:
                                         easily (e.g. test and production 
                                         setup).Sample of configuration file 
                                         parameters looks like:
-                                        vss = vss_release_3.1.1.json
+                                        vss = vss_release_4.0.json
                                         cert-path = . 
                                         log-level = ALL
 
   --vss arg                             [mandatory] Path to VSS data file 
                                         describing VSS data tree structure 
                                         which `kuksa-val-server` shall handle. 
-                                        Latest VSS release ('vss_release_3.1.1.json')
+                                        Latest VSS release ('vss_release_4.0.json')
                                         file can be found in data/vss-core folder.
   --overlays arg                        Path to a directory cotaining additional
                                         VSS models. All json files will be 

kuksa-val-server/README.md

@@ -103,7 +103,7 @@ After you successfully built the kuksa.val server you can run it like this
 ```bash
 #assuming you are inside kuksa-val-server/build directory
 cd src
-./kuksa-val-server  --vss ./vss_release_3.1.1.json --log-level ALL
+./kuksa-val-server  --vss ./vss_release_4.0.json --log-level ALL
 
 ```
 Setting log level to `ALL` gives you some more information about what is going on.

kuksa-val-server/config.ini

@@ -1,4 +1,4 @@
-vss = vss_release_3.1.1.json
+vss = vss_release_4.0.json
 log-level = ALL
 cert-path = .
 

kuksa-val-server/docker/collect-deployment-artifacts.sh

@@ -20,5 +20,5 @@ mkdir /deploy/exampleconfig
 mkdir /deploy/exampleconfig/certs
 
 cp /kuksa.val/kuksa-val-server/build/src/config.ini  /deploy/exampleconfig/config.ini
-cp /kuksa.val/kuksa-val-server/build/src/vss_release_3.1.1.json  /deploy/exampleconfig/vss.json
+cp /kuksa.val/kuksa-val-server/build/src/vss_release_4.0.json  /deploy/exampleconfig/vss.json
 cp -r  /kuksa.val/kuksa_certificates/* /deploy/exampleconfig/certs/

kuksa-val-server/src/CMakeLists.txt

@@ -172,6 +172,7 @@ if(BUILD_EXE)
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_2.2.json ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_3.0.json ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_3.1.1.json ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_4.0.json ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../config.ini ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../config_grpc_client.ini ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)
 
@@ -187,6 +188,7 @@ if(BUILD_EXE)
   install( FILES ${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_2.2.json DESTINATION bin/${SERVER_EXE_NAME})
   install( FILES ${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_3.0.json DESTINATION bin/${SERVER_EXE_NAME})
   install( FILES ${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_3.1.1.json DESTINATION bin/${SERVER_EXE_NAME})
+  install( FILES ${CMAKE_CURRENT_SOURCE_DIR}/../../data/vss-core/vss_release_4.0.json DESTINATION bin/${SERVER_EXE_NAME})
 
 
   # CPack

kuksa-val-server/src/main.cpp

@@ -110,10 +110,10 @@ int main(int argc, const char *argv[]) {
       "Configuration file with `kuksa-val-server` input parameters."
       "Configuration file can replace command-line parameters and through different files multiple configurations can be handled more easily (e.g. test and production setup)."
       "Sample of configuration file parameters looks like:\n"
-      "vss = vss_release_3.1.1.json\n"
+      "vss = vss_release_4.0.json\n"
       "cert-path = . \n"
       "log-level = ALL\n")
-    ("vss", program_options::value<boost::filesystem::path>()->required(), "[mandatory] Path to VSS data file describing VSS data tree structure which `kuksa-val-server` shall handle. Sample 'vss_release_3.1.1.json' file can be found under [data](./data/vss-core/vss_release_3.1.1.json)")
+    ("vss", program_options::value<boost::filesystem::path>()->required(), "[mandatory] Path to VSS data file describing VSS data tree structure which `kuksa-val-server` shall handle. Sample 'vss_release_4.0.json' file can be found under [data](./data/vss-core/vss_release_4.0.json)")
     ("overlays", program_options::value<boost::filesystem::path>(), "Path to a directory cotaiing additional VSS models. All json files will be applied on top of the main vss file given by the -vss parameter in alphanumerical order")
     ("cert-path", program_options::value<boost::filesystem::path>()->required()->default_value(boost::filesystem::path(".")),
       "[mandatory] Directory path where 'Server.pem', 'Server.key' and 'jwt.key.pub' are located. ")

kuksa-val-server/test/unit-test/CMakeLists.txt

@@ -89,7 +89,7 @@ if(BUILD_UNIT_TEST)
 
 # Copy all files needed for tests, in general no problem to use older versions as long as KUKSA.val supports that version
 # Unless required for other reasons tests shall use "test_vss_release_latest.json" so that we always test against latest released version
-  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../../data/vss-core/vss_release_3.1.1.json ${CMAKE_CURRENT_BINARY_DIR}/test_vss_release_latest.json COPYONLY)
+  configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../../data/vss-core/vss_release_4.0.json ${CMAKE_CURRENT_BINARY_DIR}/test_vss_release_latest.json COPYONLY)
 # If older versions needs to be used in test then include them as "test_vss_release_X.Y.json"
 
   configure_file(${CMAKE_CURRENT_SOURCE_DIR}/../../../kuksa_certificates/jwt/jwt.key.pub ${CMAKE_CURRENT_BINARY_DIR} COPYONLY)

kuksa-val-server/test/unit-test/VssDatabaseTests.cpp

@@ -502,7 +502,7 @@ BOOST_AUTO_TEST_CASE(getDataTypeForAttribute) {
 
 BOOST_AUTO_TEST_CASE(getDataTypeForActuator) {
   db->initJsonTree(validFilename);
-  std::string path = "Vehicle/Cabin/Door/Row1/Right/IsLocked";
+  std::string path = "Vehicle/Cabin/Door/Row1/PassengerSide/IsLocked";
   std::string dt = db->getDatatypeForPath(VSSPath::fromVSS(path));
   BOOST_TEST(dt == "boolean");
 }

kuksa_databroker/Dockerfile

@@ -62,10 +62,11 @@ COPY --from=builder /home/rust/src/databroker /app/databroker
 COPY --from=builder /home/rust/src/kuksa_databroker/databroker/thirdparty /app/thirdparty
 
 ADD ./data/vss-core/vss_release_3.1.1.json vss_release_3.1.1.json
+ADD ./data/vss-core/vss_release_4.0.json vss_release_4.0.json
 
 ENV KUKSA_DATA_BROKER_ADDR=0.0.0.0
 ENV KUKSA_DATA_BROKER_PORT=55555
-ENV KUKSA_DATA_BROKER_METADATA_FILE=vss_release_3.1.1.json
+ENV KUKSA_DATA_BROKER_METADATA_FILE=vss_release_4.0.json
 
 EXPOSE $KUKSA_DATA_BROKER_PORT
 

kuksa_databroker/integration_test/run.sh

@@ -27,7 +27,7 @@ VSS_DATA_DIR="$SCRIPT_DIR/../../data"
 
 echo "Starting databroker container (\"${DATABROKER_IMAGE}\")"
 RUNNING_IMAGE=$(
-    docker run -d -v ${VSS_DATA_DIR}:/data -p 55555:55555 --rm ${DATABROKER_IMAGE} --metadata data/vss-core/vss_release_2.1.json
+    docker run -d -v ${VSS_DATA_DIR}:/data -p 55555:55555 --rm ${DATABROKER_IMAGE} --metadata data/vss-core/vss_release_4.0.json
 )
 
 python3 -m pytest -v "${SCRIPT_DIR}/test_databroker.py"

kuksa_databroker/integration_test/test_databroker.py

@@ -49,7 +49,7 @@ async def test_feeder_metadata_registered(setup_helper: Databroker) -> None:
     helper = await setup_helper
     feeder_names = [
         "Vehicle.OBD.Speed",
-        "Vehicle.Powertrain.Transmission.Gear",
+        "Vehicle.Powertrain.Transmission.CurrentGear",
         "Vehicle.Chassis.ParkingBrake.IsEngaged",
         "Vehicle.OBD.EngineLoad",
     ]

test/stresstest/broker.py

@@ -25,7 +25,7 @@ class Broker:
     def start(self):
         port = self.cfg.get("port")
         address = self.cfg.get("ip")
-        kuksa_val_databroker_cmd = ['cargo', 'run', '--release', '--bin', 'databroker', '--', '--metadata', '../../data/vss-core/vss_release_3.1.1.json', '--port', port, '--address', address]
+        kuksa_val_databroker_cmd = ['cargo', 'run', '--release', '--bin', 'databroker', '--', '--metadata', '../../data/vss-core/vss_release_4.0.json', '--port', port, '--address', address]
         self.process = subprocess.check_call(kuksa_val_databroker_cmd)
     def __init__(self, config):
         self.cfg = config