Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Vorto / Meta Information Model / Discussion/ Packages
Issue: Describing a vehicular interface using Vorto
The open source Device Description framework eclipse Vorto shall be used to describe the accessible data and functionality of a vehicle.
In contrast to the manageable complexity of devices (like sensors) from the home automation sector, the E/E architecture of a modern vehicle, as shown in Figure 1, hosts up to 80 ECUs as well as hundreds of functionalities and data sets which are structured in functional domains to simplify their development.
Discussion of possible solutions
The following discussion introduces four approaches how to describe the complexity of modern E/E architectures using Vorto.
Multi Function Block approach
A first approach describes the whole car using a single Information Model. Each in car functionality is in return represented by one Function Block.
Since a car comprises hundreds of functionalities this approach would lead to a quite unstructured model with a vast number of elements in a single layer structure.
Multi Information Model approach
A second approach to introduce structure and handle the complexity is to use several Information Models to describe one car (e.g. one Information Model per domain). Each Information Model holds the different functions in form of Function Blocks.
The disadvantage of this approach is the lack of a single access point to the car which would hinder accessibility. Since easy access to the car is a major goal a third approach is introduced.
Information Model hierarchy
A third approach would extend the Information Model entity by making it hierarchical. A car would then have a single “Master Information Model” for the whole car which acts as a bracket over several Information Models that could represent the different domains. It thereby regains the capability of easy access, as the “Master Information Model” would provide an entry point.
The introduction of a new type (Master Information Model) or the modification of the capabilities of the Information Model would make using the Information Model concept more complex and could be a potential hurdle for new Vorto users.
Introduction of Packages
A fourth approach would introduce an additional structure: packages. A package is an element that is able to hold several other packages (hierarchy) or Function Blocks. A vehicle abstraction using this approach could look like following (see also Figure 5): A single Information Model representing the whole vehicle and thereby providing a single point of access. Several packages under this Information Model represent the domains. Under each domain package might be several other packages representing the ECUs. The ECU packages would then hold Function Blocks representing a single application.
The introduction of packages as additional structure elements has some key benefits: From the automotive view point this approach provides a single entry point to access the vehicle, while the provided functionality of the car could be described in a very structured way. Furthermore the mapping of a Function Block to an application corresponds with the AUTOSAR concept of having self-contained, movable Software Components (SWCs). Looking from the Vorto perspective the easy usability is preserved due to the fact that the concept of a package is widely used (e.g. in Java, UML ...) and should therefore be easy to understand for the user, while the information model is kept lean and simple.