JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
Page History
| Info | ||
|---|---|---|
| ||
This list was taken List directly lifted from the page CVII Tech Stack Terminology. We should review it too see if updates are requiredWhilst major changes are not expected it is worth noting the text is currently being reviewed and updated to reflect the current thinking. |
| Info | ||
|---|---|---|
| ||
Given its central role in abstracting vehicle signals into standardised data the Vehicle Signal Specification (VSS) is most often mentioned in the terminology below when discussing data models. In Data Centric Architectures it is seen as beneficial that the same technology stack be used for multiple data domains and that is the case here. Rather than make the text unnecessarily long by continuously spelling it out in the definitions it should be assumed that the majority of components will also process data using other data models. A central Data Store for example is likely to store data from VSS, native signals and other models such as personal and privacy data. |
...
A component storing values for various data models, including VSS signals, in the embedded in-vehicle space.
...
It could be a central component in a data/event architecture within one ECU (distributing data to processes / software components). In those cases it is typical to have a direct shared memory or other internal "IPC" connection, not usually needing a IP network.
Notification features
Some databases might have some sort of "notification" feature that is used by other components directly. Because if a Data-Server supports the subscription functionality towards its external clients, it would benefit from getting notifications from the StateStorage State Storage when a new value is received there, so that internal polling is not necessary.
However, if the component implements any more logic beyond simple subscription (notify me whenever a new value is written for this data item) then it should likely be named named Data Server, or Event framework component (see definitions).
Sync features
Some databases might have a data synchronization component to automate sync of data between instances.
Some implementation options:
Apache IoTDB, REDIS, (sqlite), in-memory-table, Realm
...
A component that provides VSS data on-demand or with other features (subscription to changes, or a streaming/data-flow functionality). A
The data may be in a variety of data models including VSS signals. A Data-Server primarily serves "remote" subsystems, for example a vehicle providing data server to a client in the cloud, or a data server running on one ECU providing data to another ECU.
...
A component that fetches data from a Data Server according to the chosen protocol. It typically interfaces with a database, OEM database or other, where it stores fetched data.
Data Synchronization Component
A component that automates the sync of data between instances. For example between Data Stores. This can include such sophisticated features as conflict resolution. Such features can be very useful when applying data centric architectures to zone and central compute electrical architectures in-vehicle. Different zones may have local zone specific State Storage that is selectively synchronized with State Storage in the central compute or TCU for further processing.
Event Framework Component
A component that implements logic to receive, process and redistribute events in an event-driven architecture fashion. It must implement some kind of logical operations beyond simple "subscribe to all updates of this signal", and "notify all subscribers that this data changed". If it has conditions like "Notify if this AND that event happened, and if signal value A < 3", then it is an event framework component.
In some cases the implementation of event frameworks have included some of the functionality of a data-server, data-client, etc. (see Variations)
VSS
...
Connector
A typically small component that is an implementation of a data source, and a binding/translator to/from non-VSS domains:
- It writes VSS signal data to a State Storage.
- It consumes data from non-VSS data sources and converts it to VSS-defined signals before writing into State Storage.
The VSS signals are defined by one/more VSS catalog(s) (=The shared VSS standard catalog and/or additional catalogs). The non-VSS format can be any data source and typically requires some kind of definition catalog as well. Finally, a conversion-mapping information between the non-VSS and VSS data definitions would be required. - A feeder connector may connect to specific technologies where non-VSS data is provided. Example: A CAN-bus VSS-feederconnector, ingests CAN signals, converts to appropriate VSS catalog signals, and write those into a State Storage.
- While it is less common, the same feeder connector component can of course handle "written" signals as well (data is read from state storage, written to the non-VSS domain).
Synonyms: the component may also be referred to as a Bridge or Feeder in some designs.
Data Connector
The generic form of the VSS Connector that manipulates any data model. Such as personal data.
OEM Database (a.k.a. Cloud database, a.k.a. Data Lake)
...
Overview
Content Tools