Dear all,
I fully support Aaron’s suggestion and I also like the suggested reference architecture picture of my former colleague Markus Oertel
a lot.
After the definition of such a “reference architecture” (which captures a jointly agreed view on a future Automotive software architecture),
the specific contributions from the SDV community could be mapped into this overall architecture.
Thus, providing important information about the usage context and possible integrations into existing commercial software architecture.
Furthermore, such a joint view could also serve to identify future fields of collaboration and become a starting point for joint roadmapping
activities.
In the course of such a discussion, I also believe that the SDV community should consider the provision of a proof-of-concept implementation
of (at least most important elements) of such a reference architecture, considering the full SW stack from the App level down to the BSP for a specific reference HW platform (which could also be virtualized based on QEMU etc.), well knowing that this requires
serious effort and discipline, but might strongly facilitate the pick-up of SDV contributions into a broad spectrum of future vehicles.
A nice way of supporting such activities could be to either stem from existing and running public funded research projects. At least
I do see a strong need for supporting sustainable integration and maintenance of currently started SDV activities and projects, but maybe this goes beyond the Eclipse SDV WG.
Kind regards,
Kim
From: sdv-wg <sdv-wg-bounces@xxxxxxxxxxx>
On Behalf Of ???
Sent: Friday, July 29, 2022 10:03 AM
To: Software Defined Vehicle Working Group <sdv-wg@xxxxxxxxxxx>
Subject: [sdv-wg] 回复: Heads-up and fyi about brainstorming session for SDV techcommunity
Hello Daniel&Tom,
Thank you for your meaningful work.
I am encouraged to see that we are trying to clearly define
“What we do”
and “How we do”
regarding SDV. I think this is the fundamental question that we should answer first.
I suggest the big players (ETAS, Microsoft, Caraid etc) lead the community to make a reference architecture first, or a metro map, whatever the format it is, to guide the community.
Otherwise people may feel lost.
Below is an example I collect from AOC-2022, hope it’s helpful
for us.
Source: Vector, Vehicle OS_ Boost or Threat for AUTOSAR, Markus Oertel
![cid:image001.png@01D8A5C5.953DB820](pngZCk5ckKTqf.png)
Best Regards,
Aaron
Hello SDV community,
Last week there was a brainstorming discussion between Tom Fleischmann (CARAID) and Daniel Krippner
(Bosch/ETAS), touching a range of SDV-related topics. We’d like to give a summary of the points we focused on:
Automotive grade development process for Eclipse SDV projects
- there is a general sense that prospective in-vehicle OSS software needs to be “automotive-grade”
- what that specifically means needs to be elucidated going forward in the community
- there exist very promising starting points for enabling projects to generate bespoke
artifacts, one of them is are engineered requirements and the according tracing as proof, A good starting point can be
OpenFastTrace:
itsallcode/openfasttrace:
Open source requirement tracing suite (github.com)
- we would propose to have a show&tell for
OpenFastTrace soon, for example in one of our tech alignment sessions and jointly reached out to the maintainers of the project.
Visualizing SDV-related communities
- originally initiated from a set of collaboration workshops in SOAFEE, we spoke about
the idea to create a x-initiative visualization of how SDV-related groups play together and how they align topically
- there is a small prep work team in SOAFEE right now, beginning to discuss ideas for
this – there might be a great opportunity to leverage Thomas’ subway
map of the softwaredefined car
Orchestration layer for diverse workloads
-
in the light of the existing and expected diversity of in-vehicle technology stacks (AUTOSAR classic and adaptive, containers both CRI/OCI/non-OCI
and more specialized implementations, package-managed systems, sandboxes like web assembly, etc) we discussed how as a community we might embrace this diversity.
-
We as well briefly discussed that CARAID is using northstar (https://github.com/esrlabs/northstar).
Northstar is written in RUST as is deemed a good fit for our future systems.
- specific automotive-fit implementation details are tbd, but aligning ourselves around
a orchestration layer (“control plane”) that we all can agree on and use to integrate runtime stacks might be a way forward that propels SDV towards becoming an actual ecosystem
- this also might be a fruitful topic for one of our next tech alignment sessions
Looking forward for open discussions on the SDV mailing list within our community.
Best regards.
Daniel & Tom