(proposed)

StateStorage (a.k.a. DataStore, a.k.a. Embedded Database)

A component storing values for VSS signals in the embedded in-vehicle space.

This component may serve the Data Server with values, and/or it could be a central component in a data/event architecture within one ECU.

Some databases might have some sort of "notification" feature that is used by other components directly.  In many cases, if a Data-Server supports the
subscription functionality towards its external clients, it would benefit from getting notifications from the data-store when a new value is received there, so that internal polling is not necessary.

Some implementation options:
IOTdb, REDIS, (sqlite), in-memory-table

Data Server

A component that provides VSS data on-demand or with other features (subscription to changes, or a streaming/data-flow functionality). A
Data-Server primarily serves other 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.

It could also be used in the in-vehicle subsystem, to provide data to ECUs,

A Data-Server differentiates from the State Storage primarily by that it is to speak a particular data protocol for example VISS, and that it is designed to talk to other (sub)systems whereas the StateStorage serves primarily in a more local context (e.g. one operating system kernel, one SoC or one ECU).
The data protocol that the Data Server uses is also more capable than the simple get/set (and possibly subscribe) provided by the StateStorage. 

Data client

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.

Event framework component

A component that implements logic to receive/process and redistribute events in an event-driven architecture fashion.

In some cases the implemented frameworks have included some of the functionality of a data-server, data-client, etc. (see Variations)

VSS-Feeder

Implementation of a data source, and a small binding component to non-VSS domains:

1. It writes VSS signal data to a State Storage.
2. It consumes data in a non-VSS format and converts it to VSS-defined signals before writing into State Storage.
   The VSS signals are defined by a VSS catalog (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.
3. A feeder may connect to specific technologies where non-VSS data is consumed.  Example: A CAN-bus VSS-feeder.
4. While it is less common, the same feeder component can of course handle "written" signals as well (read from state storage, write to the non-VSS
   domain).

OEM Database (a.k.a. Cloud database, a.k.a. Data Lake)

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. Operated/controlled by OEM.  Depending on scale, it may of course use load-balancing / distributed database technologies.

Neutral server Database (a.k.a. Cloud database, a.k.a. Data Lake)

Operated/controlled by a neutral server a.k.a. data broker company.  We expect the technology to be identical or similar to OEM database description.

3rd party application

Some individually developed program that uses the vehicle data. Typically such an application is connected to OEM cloud or Neutral Server cloud.
Sometimes it may also be connected directly to a Data Server, for example in the case of the vehicle's system allowing 3rd party applications (such as in
either an embedded Android Automotive based IVI system, or a mobile device that has been connected to the vehicle.)

Whereas some of the components mentioned here can be mixed-and-matched with some technology variation, 3rd party applications are in particular need of a single (ideally) API that is consistent across all implementations.

Note on Variations

These component names are to facilitate discussion and description of SW
architecture, but do not strictly put limits on the design.

There are many variations to the design depending on the computing environment
constraints, preferences, and the chosen technologies (that may have some of
the named features already built in). The named components above may be
combined into a single software component or project.

For example, the VSS feeder might be a "plugin" to some framework, e.g. the
State Storage database, instead of being a separate process.

Another example: If only the latest-and-greatest value for each signal
is remembered, then the StateStorage might not need to be a full "database"
component but simply an in-memory table, which could be integrated into the
data server code.

Etc.