You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 37
Next »
Wednesday 2021-07-21
Minutes/Agenda
- Project updates, see above
- AMM, discuss candidates for sessions / presentations
- Follow-up and further planning on 3 prioritized development topics
- Vacation/attendance planning for upcoming weeks
Wednesday 2021-07-14
Minutes:
- Project updates according to above.
- Thomas: How/where to host the "ready-to-go" RaspberryPi images mentioned previously? Let's discuss how to make it more visible.
- Gunnar: Reiterating that out-of-the box experience is good, but we also need to "break apart" frameworks into reusable components, to promote and help a collaborative tech-stack development.
- Thomas: Daniel K has some ideas for APIs for cloud-to-device.
- Went through the currently three highlighted development projects at the top of CVII Tech Stack
- VISS server (C++)
- Artem / AOS likely to plan resources
- VSC-based proof of concept
- Bosch interest - Thomas to set up initial chat with Daniel Krippner.
- Binary serialization specification
- Overall, these three seemed to still be high on interest/priority list.
Wednesday 2021-07-07
Project | Person reporting | Updates | Comments |
---|
| Thomas Spreckley | Still working on "ready-to-go" Raspberry images (with Ubuntu and Apertis) |
|
| Sebastian | GRPC interface: Work ongoing Eclipse SAAM sldies and talk, also pitching vss available at: https://www.eclipse.org/kuksa/blog/2021/06/24/2021-06-24-eclipsesaam-scr-anti-tampering/ for all SAAM talks check https://events.eclipse.org/2021/saam-mobility/ |
|
- VISS server implementation in Go
| Ulf |
|
|
| Gunnar Sebastian Daniel W | Discussion around units (kph, m, kg,...) and datatypes (int16, string, float,.... : How to "add" new ones, should this really be encouraged, or rather discouraged. Discussion ongoing Fixed a small datatype bug in Wheel specification Small bugfixes in tooling |
|
| Daniel W | No updates. Meeting with MS upcoming (how to map to MS ecosystem) |
|
| Gunnar | Has been discussed during CVII workshop July 1st CVII Workshop July 1, 2021 |
|
| Ulf |
|
|
| Ulf |
|
|
| Artem | Has been presented during CVII workshop July 1st CVII Workshop July 1, 2021 |
|
Minutes:
Wednesday 2021-06-30
Minutes:
- Introduction (for Marc mostly) on various topics, organization etc.
- Artem: There are fundamental topics I would like to have workshop on. How to identify services. Authorization....
- Blackberry+AWS IVY project was mentioned. Bosch working on setting up a first discussion / onboarding.
Wednesday 2021-06-23
Fixed Agenda:
Project updates (<= 2-4 min each)
Project | Person reporting | Updates | Comments |
---|
| Thomas Spreckley | Improved unit-tests (especially on protocol gateway) Vehicle Edge repo improvements, hardware support (RPi4) |
|
| Sebastian | Perfect. |
|
- VISS server implementation in Go
| |
|
|
| Gunnar Daniel W | GitHub actions VSS catalog now not using list-format, better consistency UUID no longer using an input file. Improved package dependency handling |
|
| Daniel W | Short meeting → Plan deep-dive this week on format of TTL file (Turtle - Terse RDF Triple Language), and checking if conversion tools work, etc. |
|
| Gunnar |
|
|
| |
|
|
| | Future: possibly split up parts into repos, prepare for proper "microservices" usage. |
|
| Artem → Stephen | Ongoing discussion about existing code becoming open-source, and identify new collaboration areas. |
|
Project planning, other topics
Participants
- Christian K
- Philippe R
- Dirk
- Stephen
- Thomas
- Piotr
- Ted
- Gunnar
Minutes
Subprojects / tracks updates
- Development projects, in table above
Bosch Framework
General
- Is the (old but actively developed) JOYNR project of interest in CVII context?
- Eclipse Foundation project Tractus-X – worth starting an alignment discussion
AUTOSAR
- CVII was presented / discussed with AUTOSAR steering committee today. (Good Q&A and discussions but further details not shared here)
- We want to discuss the ability to use AUTOSAR based systems as signal sources
- Connecting AUTOSAR and "non-AUTOSAR worlds"
- Can there be a gateway doing (any) necessary translation (if needed), and/or mapping between protocols
Wednesday 2021-06-16
Fixed Agenda:
Project updates (<= 2-4 min each)
Project | Person reporting | Updates | Comments |
---|
| Thomas Spreckley | Technology transport abstraction (protocol gateway) C++ support Integration test framework + test suites Rust experiments starting (not visible yet) |
|
| Sebastian | Paper describing working with Kuksa (gather data from exhaust system and analyze the values) |
|
- VISS server implementation in Go
| Ulf | Support for Curve Logging. Implementation better verified now (connected and compared to Geotab Go-device implementation) |
|
| Gunnar Daniel W | Travis broken... Discussion on attributes (constants), how often and if they can change (for example between driving cycles) |
|
| Daniel W | vss2vsso → ready to merge. |
|
| Gunnar | PR open tweaks some concepts, nested namespaces, clarifies properties. Properties = VSS signals. Similar setup. Discussion on whether it can be done only "in VSS" instead. NOTE: Planning in parallel a "fundamental" discussion on the creation of the common services/interface language likely on July 1 workshop. |
|
| Ulf | VISS version 2, process started to send it out as First Public Working Draft (first working group approves to go to this state). Discussion on if some features should be optional. Candidates for optionality are in the areas of filtering and access control. |
|
| Ulf | Some smaller fixes after testing in new environment. Planning to have a tool to transform from Geotab collected data into VSS. The first step was implemented (to interpolate curve logging formatted data). |
|
| Artem | Awaiting big-picture plan first (see below) |
|
Project planning, other topics
Participants
Minutes
- Quick updates done
- AOS:
- Artem: We are working on publishing the appropriate open-source parts. Protocols, authentication, ...
- Authorization service. Defining access rights.
- Gunnar: Definition of access control rights, permissions, etc. are worthwhile to make standard. Different environment have different needs (e.g. VISS spec, Android Automotive permissions model, etc.) but there are opportunities to design this together.
- AUTOSAR connection
- Piotr: TietoEvry has talked with AR community to propose some concepts. VehicleGateway (Cloud-to-vehicle connection), conceptual phase started. Piotr tracking but not part of main design team. Adam can tell us more.
- Fill out survey (and ask colleagues who are not as connected to CVII already)
- July 1 Workshop planning
- Ted: Best Practices for automotive applications, is progressing well (recent discussions on accessibility aspects).
Wednesday 2021-06-09
Project planning, other topics
- Student development project (security) – brainstorm implementation topics
- CVII Workshop planning
- AOS presentation by Artem
Participants
- 16 participants
- Florian, Jeff, Johan, Ulf, Stephen, Gunnar, Philippe, Ted, Daniel W, Artem, Christian K, Dirk, Christian H, Ravi
- Apologies: Iyyaz
Minutes
- Development project updates were skipped (missed). Postponed until next week.
- Round-table due to new mix of participants
- Discussed student dev project ideas, link above
- Discussed CVII workshop plan, link above
- Artem presented AOS overview
- Discussions around future plans (overlay architectures from AOS, Bosch-IoTea/Vehicle Edge, CCS and other. Identify work areas).
Wednesday 2021-06-02
Fixed Agenda:
Project updates (<= 5 min each)
Updates on liaisons, alignment track, etc.
Project planning, other topics
- Starting conversations with/about AOS today
- CVII Workshop date set for 1 July (1600 CEST, 3h duration)
Minutes
- Introductions (Artem's first meeting)
- Brief discussion on AOS (principles, not the technology). Embedded parts are planned to be open-source. Process ongoing (outlook - a few months).
- Artem to give AOS architecture/tech overview next week
- Artem mentioned Android HAL using a VISS-protocol external server was implemented and shown by EPAM a few years ago.
- Gunnar: So this was before AASIG was started... It is good input, although current work has considered GraphQL as the protocol for the internal VSS-data server.
- => Artem to provide a link to the published code.
- New table-based tracking of wanted/expected/missing tech stack components was added to the CVII Tech Stack overview page Feedback/changes welcome!
- This could drive priority discussions also
- Sub-topics moved to separate pages for deeper analysis, e.g. protobuf (already existed), mqtt (new), etc.
- Eclipse: short discussion on the liaison with Eclipse, to be followed up with the Bosch team
Wednesday 2021-05-25
Project updates (<= 5 min each)
Project | Person reporting | Updates | Comments |
---|
| Lars-Erich?, Jochen? |
|
|
| Sebastian | VISS server - PR 190 - now apply default values if given in input catalog. |
|
- VISS server implementation in Go
| Ulf | Full implementation of Curve Logging (see Tech Brief page) included now. |
|
| Gunnar Daniel | vss-tools: Array size support (caused warnings before) Bug in instantiation code fixed. |
|
| Daniel |
|
|
| Gunnar |
|
|
| Ulf |
|
|
| Ulf |
|
|
AOS? |
|
|
|
Updates on liaisons, alignment track, etc.
- Main topic right now is liaison with ISO group W6 for Extended Vehicle to discuss (potentially) introduction of data model definition in ExVe work.
- Plan for a small-scale meeting with some engineers involved in the activity.
- A deeper technical alignment work is required for SENSORiS. It could be done by a volunteer or a small working group meeting (doing the work, not talking about what could be done).
Project planning, other topics
- Upcoming - overlay architectures and plans from VehicleEdge, CCS, AOS, plus the VSS-tools, VSC-tools and various plans discussed in this meeting. The purpose is to combine these into a view of the full tech stack.
- Gunnar reached out to EPAM for participation
Minutes
- Many vacations in Germany this week affects today's attendance.
- Gunnar: Some things might need to be repeated next week, but let's run a dress-rehearsal of the fixed agenda today. Starting with updates.
- Sebastian: Note the upcoming Eclipse Conference. There will be a presentation on KUKSA.VAL, but also other interesting things.
- Gunnar: (Tip from Stephen). Note also this Embedded virtual conference starting June 3rd (several strong embedded Linux talks in the agenda).
- AOS, first look for related code:
Wednesday 2021-05-19
- Sebastian suggests every meeting should start with a project-update from each component development project, including IOT-event-analytics, and others.
- Gunnar notes that we should have clearer indication of who is attending/not every week. Better structure and discipline for attendance, (and for agenda of course). Time-boxing can be used if people only want to be on part of the meeting.
- Not much progress on VS* to AUTOSAR tooling this week. Piotr had to leave meeting.
- Basic VSC generation framework now on GENIVI github → vsc-tools
- More VSS-to-bindings tools might come out open-source licensed, from another OEM's development
- A look at aoscloud.io - Renesas and EPAM. Some open-source components. Renesas has used VSS and VISSv1 in previous demos. We are hopeful for setting up collaborative work on overlapping areas.
- Collecting up some more related SW project (some older, some newer):
Wednesday 2021-04-21
Agenda
- Development related to integrating with AUTOSAR
- "Plan B" on VSC tooling development - discuss options
- Bosch I-O-Tea and Vehicle Edge evaluation
Notes
- Integrations to AUTOSAR
- Tieto platform running, ready to use for investigations
- Gunnar: For "Any"2Autosar tooling, first step is usually a definition of the mapping (spread-sheet showing language features that map to each other, where is it simple, where are challenges, etc.)
- VSS2ara would be basically solving the "autosar side" of the system, similar to how Franca → AUTOSAR XML converter was used with AUTOSAR.
- Alternative is to first focus on the "non-AUTOSAR" side of systems, e.g. generate a SOME/IP binding directly, or DDS, or other. (VSS/VSC to SOME/IP binding directly).
- ASAM service oriented diagnostics seems interesting.
- "Plan B"
- The VSC-related tooling is taking even longer time to go through company legal reviews and final approvals for releasing it with an open source license, although there is a clear desire to get it done.
- A discussion started on how to develop a first set of tools in parallel with waiting for the other.
Wednesday 2021-04-14
Notes
- Tieto: AUTOSAR analysis ongoing. Need tooling soon.
- VSC tooling seems held up by something. End of this week consider if we should launch plan B. Talk to Magnus about it.
VSC: - Piotr: Has ASN.1 been considered as a definition language? (it could be an alternative to protobuf?)
- ... the compilers are often able to generate a compact binary format
- ... likely less availability of open-source tools. There should be some however.
- Gunnar: For VSS I think it's "overkill" since VSS has very simple datatypes but for VSC and arbitrarily complex data definitions, maybe
- Gunnar: FYI: OpenAPI and AsyncAPI have however come up as potential reuse or inspiration for VSC definition. Franca IDL is still a strong basis however.
OpenAPI is only REST-focused and AsyncAPI seems to describe primarily a pub/sub direction.
VSS - Stephen: I was recently reading about GraphQL Federation that allows seperation of concerns and for domain teams to create parts of the data graph that are then federated into a whole. The seperation of concerns resonated with in-vehicle engineering where you have for example services with very different safety and security requirements. Could this help us?
Cloud
- Iyyaz: Regarding demo (AMM). Docker-based stack and Terraform is being developed.
Wednesday 2021-04-07
Notes
- Tieto setting up internal meetings to figure out what to do next with the plans on AUTOSAR interoperability.
... planning to build on VSC tooling
... Gunnar: Plan translation mapping and templates can start early
- Iyyaz has prepared some notes . E.g. what is "the edge" by definition?
Wednesday 2021-03-31
Notes
Wednesday 2021-03-24
- pipeline and configmanager come from IoT-event-analytics repository = Northbound
- kuksa val, hal interface+adapter, vss2iotea part of vehicle-edge = Southbound
- Dirk: There should be some useful UML diagrams.
- Christian to find the presentations/pictures that are useful here and attach to CVII Tech Stack page.
- Tieto still working on setting up AUTOSAR environment and planning.
- Discussed the need to coordinate development plans (e.g. bindings to DDS, SOME/IP, and-or code generators) to avoid overlap.
- Gunnar create a home page for Vehicle-Edge stack analysis and information.
Wednesday 2021-03-17
Notes
- Update on protobuf tool (merged)
- Bosch code released for IOT-event-analytics framework, and the vehicle-edge project to bring together all parts of the stack.
- Discussion on AUTOSAR tooling
- TietoEVRY to continue to seek out relevant people, bring into a design discussion meeting.
- Franca / FARACON vs VSC development
- VSC code generation framework coming soon. Discussing what to expect.
- Planning the CVII related sessions at GENIVI AMM, May 4-7.
Wednesday 2021-03-10
Agenda
- Updates on topics below
- Protobuf continued.
- Bosch
Notes
- Bosch: Code related to the demo on the CVII workshop will be on an open repository within 1-2 weeks.
- Discussion about organization of the different parts of CVII. → TODO link for "org.chart" and Common Vehicle Interface Initiative - Activity Matrix.
- confirming Signal2Service not a likely input to our work (no demonstrator, no plans at the moment)
- ZOOM KEEPS KICKING ME OUT...
- Waiting....
- Can someone take over leadership?
Wednesday 2021-03-03
- Adam K / Piotr: AUTOSAR - Signal2Service is not really implemented yet.
- Some VSS to AUTOSAR tooling seems to make sense therefore
- Tieto want to start working on this. First steps is getting runtime platform setup working. Then the design of VSS↔AUTOSAR can start (and be discussed).
- Quick look at CVII Tech Stack technologies - Protobuf again.
- Need for full software architecture focus in this project.
- Separation of safety-critical technologies and info/entertainment/other. What is being targeted exactly?
- Where in a typical architecture are we working?
- VSS itself is orthogonal to safety/other question. However, the chosen technologies and implementations may need to be classified from safety perspective.
- Clarify where different proposals belong. E.g. "MQTT is unlikely in safety domain, right?"
- Agreement on which technology to use where.
- Images to show architecture.
- Big software release announcement next week...
- Virtualization important aspect to consider.
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