Vorto / Meta Information Model / Discussion/ Packages

Issue: Describing an vehicular interface using Vorto

Problem scenario

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.

Figure 1 Exemplary E/E Architecture showing the hierarchical structure with domains and ECUs

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.

Figure 2 Multi Function Block approach

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.

Figure 3 Multi Information Model approach

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.

Figure 4 Information Model hierarchy

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.

Figure 5 Using Packages as a means to structure Function Blocks

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.