SDV Telemetry Project - On Hold
The author (Stephen Lawrence) intends for this proposal to facilitate the Data Architecture team in particular and the wider Data Expert Group to find a shared view on documenting Data Patterns and Data Architecture. Contribution is therefore encouraged by commenting inline, contacting the author or in the Data Architecture calls.
This page describes a proposal to move towards joint work on documenting Data Patterns and Architecture after the Spring 2023 AMM.
Following a summary of where we stand, a proposal is made for a possible way forward. The author does not intend the proposal to be a fully formed work plan, but a skeleton roadmap on which the Data Architecture group and the Data Expert Group can iterate on to form one. An important principal is open discussion on what issues need to be tackled down, what is needed to form common understanding and sense of purpose.
Covesa has a range of source material from which to use.
Contemporary work is occurring in the Covesa Data Expert Group including the Data Architecture pillar of the Group. For example the results from the first workshop included a high level scope to focus on zonal ECUs and above for the functional integration and data architecture. In addition high level deployment scenarios were sketched for in focus use cases including IVI, Smart device, Car2Cloud and Cloud2Cloud.
These sketches now need further work to build out the details. For example Smart Device will involve SmartDevice2Vehicle and SmartDevice2Cloud.
There are also various presentations from meetings and the All Member Meeting (AMM) conferences. For example this input on Data Centric Architectures.
Related work is also occurring in the various Covesa projects focused on specific areas such as EV Charging, AOSP and Commercial Vehicles.
There is historical work from projects such as Genivi Cloud & Connected Services (CCS) project which investigated the requirements of open data capture in-vehicle and its connection to back-end systems in the cloud and resulted in a high level architecture concept.
CCS was followed by the Common Vehicle Interface Initiative (CVII) Tech Stack project which investigated the software required to transfer and process the standard VSS data model. For that a mutual understanding of terms and common components were required. The latter resulted in the in-vehicle architecture diagram on the right, which is intended to show the likely in-vehicle components and how they interact, rather than specify a specific monolithic architecture. A set of related terminology was also defined.
As the number of adopters of Covesa technology, including VSS, has risen greatly we have seen increasing demand for descriptions of what it is intended for and how to use it. This helps both newcomers understand the technology and supports discussion within the community. At the same time the massive increase in the size of in-vehicle software and the introduction of technologies from outside of automotive has resulted in a need to quickly build understanding between people from a more diverse group of areas.
To be quickly productive this needs a shared vocabulary and understanding of common design components and patterns described in abstract terms. A solution is discussed in more detail in the proposal. To move forward on creating that within the community requires a shared view of the goals. This proposal is intended to help facilitate that.
Experience shows that to move the community forward it is helpful to discuss requirements and components in abstract logical terms. A shared vocabulary and reuse of common assets, such as patterns and diagrams, emphasis what is common, whilst avoiding the trap of focusing on what separates people in focusing on product comparisons (selecting "winners") and specific system architectures. There can also be collaboration, whilst retaining the flexibility individuals need in how components are arranged and their internal functionality. Such an approach ought to be a natural default for describing scenarios in Covesa. Repeating them socialises them within industry. PoCs could first describe the logical design before moving to specific (product) technologies if needed, e.g ‘A VISS Data Server was connected to a VSS Data Store. In our specific PoC X and Y were used.’
Patterns / building blocks:
Ultimately it is the content that is most important. The proposal below is one pragmatic approach to publishing using technology already known in Covesa, with a goal of publishing sooner, rather than later, whilst leaving room for evolution. The author is fully open to other approaches that reach that goal.
The VSS documentation website has been useful for a number of reasons. It brings the documentation together in one place, whilst supporting navigation and rich enough formatting. Being able to refer to a single URL within the site, from which other content can be found is useful for both business and technical discussions. It is therefore proposed we do the same for publishing the design documentation that is the topic of this proposal.
For ease of implementation it is suggested we use the same publishing technology used for the VSS documentation, namely Hugo with a similar format template. The requirements to build a static website to test documentation locally are straight forward and the automated build and deployment of Hugo websites is already supported within the Covesa CI. A useful attribute of Hugo is the split between content and publishing. The content can be defined in markdown for example and then consumed by the Hugo framework. This gives flexibility in both choosing tooling for the content creation step and possibly moving to a different website framework in the future if required, i.e. there is little Hugo lock-in.
Navigation should be a feature of the design. It is proposed that a hierarchical classification of topic types are listed in a panel on left hand side, e.g. Patterns, Architectures, Touchpoints, HowTo's etc. Selecting a document displays the content in the main window to the right. A lightweight document type classification would be useful to differentiate between generally agreed approaches and more experimental work. That would help avoid confusion from external consumers who are not involved in the upstream work.
If alternatives are proposed then it is suggested that work on the content starts whilst discussion of publishing technology takes place.
It is proposed that some guidelines for document creation would be useful. For example, diagrams should be in an open flexible format. To encourage collaboration it is important that others can extend and change diagrams. drawio is suggested as an option. It has good template support and free desktop and web editors are available, without restrictions, that support simultaneous editing.
It is helpful if draft text is developed in a format that encourages collaboration such as allowing inline comments and ease of editing. For example a document could be collectively created in Confluence before converting to .md markdown.