Domain-Agnostic Information Model for Vehicle Data Transformation
The push towards a domain-agnostic information model from a vehicle-centric data approach is explored due to emerging industry requirements. COVESA projects like AUTOSAR Vehicle API and EV charging necessitate a shift. The proposal introduces the Hierarchical Information Model (HIM) to organize data structures into a forest of tree representations rather than a single tree. Each tree segment represents domains and subdomains with specific information types defined by metadata primitives. The HIM configuration utilizes YAML-based files for structured tree management, offering versatility and scalability for various domains.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
December 2022 PUBLIC Transforming from a vehicle centric data model to a domain agnostic information model Ulf Bjorkengren Advanced Platforms & Simulation
Why would we change from the current passenger car centric data model to a domain agnostic information model? Because requirements in this direction have started to pop up: COVESA-AUTOSAR Vehicle API project COVESA EV charging project COVESA VSS struct definition discussions . The alternative to include everything into the VSS taxonomy becomes less attractive for every new requirement in this direction, as eventually it will lead to a bloated tree structure
COVESA-AUTOSAR Vehicle API project Puts requirement on multiple domain support passenger cars, commercial vehicles, 2- wheelers,..
COVESA-Ford EV charging project Puts requirement on multiple domain support passenger cars, road infrastructure / charging
What is proposed? The VSS rule set is moved to a new COVESA specification project It is given a name that is domain agnostic A possible candidate: Hierarchical Information Model (HIM) The VSS project will keep the responsibility of the catalog(s) of the Vehicle domain Passenger cars, trucks(?), motorcycles(?), A taxonomy instance is no longer represented by a single tree, but by a forest of trees The forest is declared in a YAML-based configuration file (xxx.him) A tree is associated with a domain name, consisting of dot delimited segments First segment is top domain , e. g. Automotive, RoadInfrastructure, Aviation, Following segments, except last, are sub-domains, e.g. Car, Truck, Trailer, ChargingStation, Last segment is information type , where currently the following are proposed: Data // signals as defined in the current VSS rule set DataDefinition //Struct definitions, etc Service //Function/procedure definitions Each Information type has a Rule set defining its set of metadata primitives E. g. the Data rule set defines the node types: branch, sensor, actuator, attribute The DataDefinition rule set defines the node types: branch, struct, item, The Service rule set may define node types such as: branch, service, input, output
HIM configuration file YAML based tree structure Each tree-based taxonomy is defined by a node in this tree Node name == root node name in taxonomy tree Enables multiple trees of same taxonomy Type: branch, taxonomy (direct access to tree), proxy (knows how to route to server managing the tree) Domain: See previous slide Version: X.Y.Z version of tree Local: reference for local access of tree Public: Reference to public (cloud) access of tree Description: Short description of the taxonomy Him: type: branch description: Contains the set of trees that are supported. VehicleData: type: taxonomy domain: Vehicle.Car.Data version: X.Y.Z local: file://<full-path-name> public: https://himrepo.oem.com?taxonomy=Vehicle.Car.Data.X.Y.Z description: . VehicleDataDefinition: type: taxonomy domain: Vehicle.Car.DataDefinition version: X.Y.Z local: file://<full-path-name> public: https://himrepo.oem.com?taxonomy=Vehicle.Car.DataDefinition.X.Y.Z description: . ChargingData: type: proxy domain:ChargingStation.Vehicle.Data version: X.Y.Z public: https://himrepo.energyco.com?taxonomy=ChargingStation.Vehicle.Data.X.Y.Z description: .
HIM deployment VINXXX.him file Defines the set of trees that the server currently supports The trees are loaded into memory, and used by the server to verify requests. Existence in tree Access control Client taxonomy discovery Etc. EV charging example
Multiple tree access EV charging example Client HTTP get to vehicle tree GET /Vehicle/Powertrain/Battery/StateOfHealth Client HTTP get to charging station tree GET /RoadInfrastructure/Charging/ChargingStation/Power
So, what does this provide? A domain agnostic taxonomy model for multiple, but separate, information types. It opens the door for other communities to apply this model to their domains. Taxonomy forests can then be declared to provide a unified address space to the superset of these domains. The same model can be used for taxonomies that are data centered, service centered, or any other information type that may be defined. Discussed at: https://github.com/COVESA/vehicle_signal_specification/issues/516
