Date: Fri, 29 Mar 2024 05:38:40 +0000 (UTC) Message-ID: <313392506.206.1711690720799@ip-172-31-8-223.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_205_2110609913.1711690720796" ------=_Part_205_2110609913.1711690720796 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
A component storing values for VSS signals in the embedded in-vehicle sp= ace.
This component may provide values to a Data Server.
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.
Some databases might have some sort of "notification" feature that is used =
by other components directly. Because if a Data-Server supports the s=
ubscription functionality towards its external clients, it would benefit fr=
om getting notifications from the StateStorage when a new value is received=
there, so that internal polling is not necessary.
However, if the component implements any more logic beyond simple subscr= iption (notify me whenever a new value is written for this data item) then = it should likely be named Data Server, or Ev= ent framework component (see definitions).
Some implementation options:
Apache IoTDB, REDIS, (sqlite), in-memory-table
A component that provides VSS data on-demand or with other features (sub=
scription to changes, or a streaming/data-flow functionality). A
Data-Server primarily serves "remote" subsystems, for example a vehicle pro=
viding data server to a client in the cloud, or a data server running on on=
e ECU providing data to another ECU.
It could however be used in a in-vehicle system, for example between ECU= s. The most common connection between these subsystems that wou= ld be an IP-network or similar.
A Data-Server differentiates from the State Sto= rage
1) A Data Server does not need to have its own persiste=
nt or semi-persistent data storage, which is a mandatory function of the St=
ate Storage, of course.
2) If State Storage has the ability for s=
imple data interaction (e.g. get, set, and in some cases distribute data up=
date notifications), then the Data Server has a more featureful data protoc=
ol. Examples of such protocols are VISS, GraphQL, MQTT, and various d=
ata-streaming frameworks.
3) A Data Server is often tailored towards talking to "remote" systems wher=
eas the StateStorage more often is in a more local context (e.g. its client=
s execute as processes on the same operating system kernel, SoC or one ECU.=
A component that fetches data from a Data Server accord= ing to the chosen protocol. It typically interfaces with a database, OEM da= tabase or other, where it stores fetched data.
A component that implements logic to receive, process and redistribute e=
vents 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 happen=
ed, 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)
A typically small component that is an implementation of a data source, = and a binding/translator to/from non-VSS domains:
A cloud-oriented database oriented towards storing large amounts of data= typically from many sources (many vehicles) in order to provide views into= the the whole set to OEM data clients.
It is operated/controlled by OEM.
Implementation: Full-scale databases, either SQL, No-SQL, or Time-Ser=
ies oriented. Depending on scale, it may of course involve also=
massively parallel and distributed database technologies.
Operated/controlled by a Neutral Server Company a.k.a. Data Broker. =
;
Technology-wise we expect similar options as for the OEM database descripti=
on.
subtypes:
3rd party cloud application
Some individually developed program that uses the vehicle data. Typically s=
uch an application is connected to OEM cloud or Neutral Server cloud.
3rd party in-vehicle application
May be connected directly to a Data Server, for example in the case of t=
he vehicle's system allowing 3rd party applications. Those might be e=
xecuting in-vehicle on an embedded Android Automotive based IVI system or s=
imilar.
It also includes applications running on a personal/mobile device that has =
been connected to the vehicle.
Whereas some of the components mentioned here can be mixed-and-matched w=
ith some technology variation,
3rd party applications are in particular need of a single (ideally) API<=
/u> that is consistent across all implementations.
Potential Todos. Define:
Access-control related =
components.
Software component repositories (for SOTA) and software deployment controll=
ers.
Abstract protocol names
...
These component names are to facilitate discussion and description of SW= architecture, but do not strictly put limits on the design. In other= words, a system is not required to be strictly partitioned into all of the= se named parts.
There are many variations to the design depending on the computing envir= onment constraints, preferences, and the chosen implementations. Exam= ple: Some implementations of component type A might already have some= of the features of component type B included, and they may as well be leve= raged. The functionalities that are named above might be deliberately= combined into a single software component or project, when this is warrant= ed.
Examples:
Despite these variations, a shared name and understanding of what each f= unctionality is about, will simplify describing the responsibility of each = component in any particular chosen setup.