JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies. |
Workshop preparation
Shortlist of working items:
MQTT (and general design) discussion
Open areas for getting started on implementation
Action: Collect more information from more companies about preferred technologies/implementations.
US friendly time 17:00 CET
Agenda
Participants
Piotr, Michal, Dariuz, Adam, Stefan, (TietoEVRY)
Notes
project scoping
review of CVII Tech Stack, updated on line
upcoming CVII workshop
US friendly time 17:00 CET
Agenda
Participants
Piotr, Michal, Dariuz, Adam, Stefan, (TietoEVRY)
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
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