Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • As a starting point it is suggested that the Service could be realised as a basic building block combining VISS Data Server with highly functional VSS Data Store.
  • As well as the mentioned flexibility in implementation, flexibility in use is also intended:
    • With some supporting documentation it could help meet the ongoing request from newcomers to the VSS eco-system as to how VSS can be used.
    • The Data Architecture group for instance has various topics it wishes to investigate related to data-centric architectures.
    • The playground can be used to investigate internals of such a service. For example, connecting VISS to medium and high speed data, or adding a protocol.
    • External connections with other systems may also be a focus. For example, combining the Service with other components to implement a particular touchpoint such as mobile.
  • Further details can be found in the following sections.

The Service in context

To help understand its use lets quickly place the service in context.

Big picture: The logical architecture for the Data Expert Group places the scope of the work as Zonal ECUs and above as shown in the following diagram:

...

It is assumed that the service would likely be deployed on a Zone, Domain or Central controller, with corresponding h/w capabilities.

Across large ECU: In the Data Architecture group it is recognised that zone/domain specific data services will need to synchronise and cooperate between themselves and/or with a central vehicle computer, e.g. Inter-controller sync/cooperation:

In-vehicle southbound: The service will integrate southbound to lower parts of the vehicle and its native data, through data feeders and connectors. This will include making connections to other systems such as Autosar etc.

Northbound: connections will be made to clients, mobile, cloud and major in-vehicle domains such as IVI running Android/Apple etc.

Logical domains: Connections may also be made to other logical data domains. For example, there is knowledge layer proposal made in the Data Architecture Group that discusses the separation of concerns and interaction between knowledge, information and raw data layers. The Service described here could be used to provide the data layer services in its investigation.

...