You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
Wednesday 2021-02-24
- AUTOSAR - Tieto/EVRY still interested but other priorities came up so the time plan not clear at this point.
- Signal2Service - check if spec released and if applicable
- Look at defining the representation of data in AUTOSAR-XML (to prepare VSS to ARXML conversion)
- FARACON tool would be one approach. Create a Franca IDL file with some observable data ("Attributes" in FIDL) and run the conversion, study the result. There is a comprehensive mapping between Franca ↔ ARXML that should be correct.
- MQTT
- VISS over MQTT (Ulf) has been described in W3C Automotive working group.
- It is embedding VISS in MQTT with a small control protocol defined (over MQTT).
- Access control strategy is identical to standard VISS.
- Topic needs to be "protected" somehow or anyone could listen/inject to traffic.
- Give some time to let this idea mature before it becomes part of any official specifications. New ideas and improvements may come up.
- A more direct VSS-to-MQTT topic mapping is a different and complementary alternative
- Sebastian: Publishing to MQTT is easy. For writing more work required (because access control details not done yet).
- Steps: Define the payload message format
- Steps: Describe the access control strategy (clients have access to a subset of topics)
- Steps: Deciding implementation language and reuse libraries
- Protobuf – think about how to represent messages - this page
Wednesday 2021-02-17
Workshop preparation
Shortlist of working items:
- General efficient message format (JSON and Binary). For use in many contexts, e.g. MQTT, and SOME/IP and other.
- For JSON, consider VISS spec
- VISS spec also has a "compressed" format (unique to VISS)
- Discussion about having a more "standard" format for binary/efficient encoding. MsgPack is somewhere in between (like compressed/binary JSON) whereas describing a schema in Protobuf or AVRO or similar will generate an efficient encoding from the schema.
- Define mapping to AUTOSAR technologies, ARA:COM (AUTOSAR XML) and/or SOME/IP or DDS specifically. In other words how is a signal definition converted to a 'Service'? Or should it simply be observable properties (Fields in SOME/IP).
- The AUTOSAR spec Signal2Service seems still unclear to many. Perhaps further investigation required.
- Can we define the actual purpose of the specification? If so, there is opportunity for any one here to propose potential solutions or to 'unstuck' this activity somehow.
Wednesday 2021-02-10
MQTT (and general design) discussion
- SSL/TLS setup between MQTT server and MQTT client could have bi-directional authentication (checking also client certificate)
- Authentication method for the initial CONNECT can be any one that client+server both support.
- One approach is to allow any client to get any MQTT topic, but the data itself is encrypted and then only those who can decrypt have access to the data in practice.
- Another (VISS and other) consider applying filters on the signals (MQTT:topics) that you can actually request. E.g. Vehicle/Cabin/Temperature. E.g. Mosquitto plugins can be used for this.
- VSS Layer (<link) a possibility to define permissions groups (for any of the technology choices or approaches above).
- Bosch proposes the use of the SSI approach: https://en.wikipedia.org/wiki/Self-sovereign_identity
- ... but SSL/TLS is also required in some environments e.g. across internet
Open areas for getting started on implementation
- Mapping VSS to popular cloud/infrastructure technologies Apache Kafka/Spark/NiFi etc.
- What about VSSo?
- Which existing technologies do VSSo fit into?
- VSSo maps well to GraphQL (or SPARQL of course). Web-of-things ← is there an obvious implementation/framework to use in implementing?
- For GraphQL there is Apollo, Neo4j, maybe others.
- Protege / Webprotege ← development/analysis of ontology/data?
Action: Collect more information from more companies about preferred technologies/implementations.
Wednesday 2021-02-03
US friendly time 17:00 CET
Agenda
- project scoping
- upcoming CVII workshop
Participants
- Christian H, Christian K, Dirk, Sebastian (Bosch)
- Niclas (Volvo Cars)
- Kevin (High Mobility), Ulf (Geotab), Iyyaz (Cobrasphere) (GENIVI CCS project participants)
Piotr, Michal, Dariuz, Adam, Stefan, (TietoEVRY)
- Ted (W3C), Gunnar, Stephen, Philippe (GENIVI)
Notes
project scoping
upcoming CVII workshop
Wednesday 2021-01-27
US friendly time 17:00 CET
Agenda
Participants
- Sebastian, Christian K, Dirk, Gerald (Bosch)
- Niclas (Volvo Cars)
- Kevin (High Mobility), Ulf (Geotab), Iyyaz (Cobrasphere) (GENIVI CCS project participants)
- Rex (Saferide)
Piotr, Michal, Dariuz, Adam, Stefan, (TietoEVRY)
- Ted (W3C), Gunnar, Stephen, Philippe (GENIVI)
Notes
Project scoping
discussion starts with MQT, discussion is based on the content of CVII Tech Stack
Sebastian: this is a preferred techno, but what should be the reference implementation for the mapping of VSS to MQTT ?
discussion on code vs specs
Christian K: code does not lie
Ted: but it can have bugs (as can specs)
Ted: a server in cloud could return VSS JSON or VSSo RDF (or other formats) through content negotiation from the same end points based on client preferences
Christian K: I am convinced there will other standards than CVII in the air, Sensoris for instance, we have already vehicles in development that use Sensoris and I would like to give an opportunity to sync with CVII in the future
TODO Christian K to contact Sensoris and make the liaison happen with them
- discussion on the interface to AUTOSAR
Sebastian: we do not need to dig deeply into Adaptive Autosar, our interface point is rather someip for instance
Dirk: I would assume both data & service mapping with Autosar
Rex: signal-to-service mapping
Ted: back to SENSORiS, a mapping may be sufficient for this activity and translators can be created by those who need them. likely would be welcome in GENIVI repo if created, HERE previously showed me some mappings they maintain
Christian K: TSN, ARA::COM are deeply embedded when we go so deep, we will lose the opportunity to do any abstraction
TODO all to define what are the high level objectives of constructing an AUTOSAR connection
Christian K: AUTOSAR is so much in the safety world that it will be difficult to build cool things with them
Sebastian: we want the data from below, i.e. from the safety world, do we want to write safety critical applications on top of VSC ?
Gunnar: IMHO VSC can describe a safety critical application but will not implement it
Dirk: what is the targeted runtime environment ? is the vehicle computer or a deeply embedded ECU ?
short discussion between Christian K, Dirk and Gunnar
Gunnar: IMHO the model could apply to any system whatever it safe or not
Christian: we will take this offline
Michal: VSS to MQTT , what is the preferred language to implement the translation ?
Dariuz: I have some experience with MQTT and I am interesting in this translator but not familiar with C++ for instance
SebastianLet's all use RUST :)
Gunnar: we could start with python first and see where it goes, but if Tieto says we use Rust, please do it, you know the industry better
Michal and Dariuz: volunteer for the translator
Adam: we can bring some feedback on AUTOSAR for the next call