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

This page collects detailed information about the IoT-event-analytics and Vehicle-Edge projects to explain the different components they are made up of so that, together with other components, we can build a full map for the desired CVII Technology Stack.

The projects implement a high-level vehicle data abstraction strategy as follows:

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:

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.

Vehicle-Edge 

Vehicle Edge sets up a complete software stack around IOT-event-analytics by adding services such as an MQTT broker, and other components.  Vehicle-edge uses containers to set up a network of communicating parts.

Analysis

The  docker compose file of vehicle edge shows the following dependencies (which order containers must be started)

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 – ...
• Kuksa.VAL provides the overall framework that implements abstractions over multiple data formats, and connections to different protocols/technolgies.  A kind of main "switchboard"
• Mosquitto-local and -remote are MQTT brokers
• VSS2IoTea – ...
• ConfigManager – ...

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:

A starting example of all configurations is provided.

Interfaces

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: