Page History

Announcement about this significant open source project creation initiated by Bosch can be found in this blog post

...

The framework's main purpose is to allow vehicle applications to communicate with each other, and with vehicle platforms, using a common data model, here implemented with the VSS.

The abstraction layers of app to platform in more detail:

The platform is useful for processing data before it is transferred to cloud infrastructure, thus being part of an edge-processing strategy.  The vehicle is then considered an edge device.

IoT-event-analytics

IoT-event-analytics (a.k.a. IOTea) implements an event processing and agent network platform.  It orchestrates the flow of events between communicating agents (Talents) where the business logic of that interaction can be programmed using several different languages.

...

Purpose of components (containers)

• Hal-interface - this typically collects signals from a low level vehicle-specific signal source such as CAN bus.  For each technology, a different hal interface can be provided.
• Hal-interface-adapter – this implements the necessary translation from the specific signal interface to the standard one used in this framework (VSS).   
  • (In CCS terms these have been referred to as "vss-feeder" components, something that feeds the system with VSS formatted data, from some source, that might not be VSS formatted, i.e. a translation occurs)
• test-talent – shows an example of a "talent" i.e. a cooperating agent in the system
• pipeline – ... main component of IOT-event-analytics? - details TBD  
• ConfigManager – ... setting up the system together with pipelines? - details TBD
• Kuksa.VAL provides the overall framework that implements abstractions over multiple data formats, and connections to different protocols/technolgies.  A kind of main "switchboard" – keeps the current value store and sits between VSS2IOtea and the hardware-specific parts.  Kuksa.VAL exposes data using the VISS protocol (v1, websocket) , but also provides other protocols like MQTT.
• Mosquitto-local and -remote are MQTT brokers
• VSS2IoTea – ...ConfigManager – ..only an adapter between VISS and IoTea.

File/storage mappings

For convenience, each container maps a config file or directory to a location in the host file system, so that the configuration can be conveniently edited.
With few exceptions, each container only sees its own config location and do not share any storage:

...

From the fact that these components are executing in different container namespaces and do not share storage, we can derive(?) that interaction between the parts are all using network protocols.

More analysis is required on what APIs are provided by each and how communication occurs:

Kuksa.VAL exposes the VISS protocol and this is the main "API" for others to interact with Kuksa.VAL

TODO:  Determine the (network?) protocols.  Specifically, what functionality does each component provide and consume?
             And which component communicates with which other one?