The Eclipse Chariott project provides:
Middleware: Centralized middleware layer to connect to different providers in the vehicle, as well as host the vehicle twin store, Access Control List (ACL), and other middleware services. Abstracts the vehicle specific providers implementation through a common and agnostic set of vehicle interfaces between providers and the applications that need to consume the data.
Application: The business logic component talking through the client/provider library to receive events and execute lower-level functions. Applications are envisioned as providing a specific set of Quality Management (QM) level functionality in the vehicle, for example, seat adjustment or interior climate control. Applications describe their ACLs and their capabilities that other applications can consume.
Providers: The vehicle has different lower-level protocols it uses to communicate with the different Electronic Control Units (ECUs) in the vehicle (e.g. SOME/IP, DDS, UDS, etc.). These providers connect the exposed services and state from the ECUs to the middleware and eventually the application. Providers are intended to be created by the suppliers, except for a reference provider that is generated for the purpose of testing and development.
The Eclipse Chariott project aims to develop a metadata-driven middleware/abstraction layer that allows modern programming models to target in-vehicle functions, providing a common way to access the vehicle hardware and sensors, while enhancing the developer journey.
The Eclipse Chariott project aims to develop a metadata-driven middleware/abstraction layer that allows modern programming models to target in-vehicle functions, providing a common way to access the vehicle hardware and sensors, while enhancing the developer journey.
Automotive original equipment manufacturers (OEMs), partners and software providers require a consistent and well-architected experience that allows them to continuously develop and deploy new software capabilities, new features, new services and new applications to vehicles without having to re-architect and reducing or eliminating system integration effort. The metadata-driven middleware/abstraction model is thus a key building block to provide a common way to access the vehicle hardware and sensors that eventually will be adopted by automotive customers and partners to enhanced developer journey. At core, the programming model should provide a service interface that 3rd party software providers can rely upon to access services and features of the vehicle.
The plan for the initial contribution, here described as Community Technical Preview (CTP), is to deliver a working proof of concept of the middleware/abstraction layer, written in Rust, that can send instructions to and receive state from a reference implementation that simulates a vehicle resource provider.
• Client/Provider Library to communicate with the middleware through an abstract interface
• Middleware to route function calls and provide an event system over registered provider
• Provider service API to extend/add vehicle provided services and data
• In memory vehicle store with point reads on the keys.
- Log in to post comments