In the context of the automotive industry, an OEM offers a range of vehicles marketed in different classes which provide different extents of functionalities related to safety, comfort, or similar criteria. Caused by marketing tendencies and proceedings in technology, vehicles are being enriched by new functionalities either newly invented or taken over from higher class vehicles. This use case also applies when new platform generations are being developed. In that case new functionalities are integrated step-wise during the development phase.
Usually, new functionalities will not be introduced independent of the existing system’s functionalities but will be integrated into the existing system’s ECU(s) and communication topology.
Changing a system’s architecture necessarily changes its behavior with respect to timing.
This use case addresses the challenges which arise during the process of integration.
The integration may cover a single ECU, or even several ECUs including their communication paths. In this use case, only one ECU will be taken into account, and the focus will be on the Design phase. In phase 2 of the TIMMO-2-USE project, this use case will be elaborated describing the integration of a more sophisticated functionality finally spanning more than one ECU.
Prior to the detailed integration process, an ECU (or several alternative ECU candidates) has to be chosen which the design function in question will be integrated on. There might be several aspects to be considered when choosing an ECU, like the functional domain which it belongs to (e.g. body controller), physical location (e.g. near front wheels), availability of input signals (e.g. sensor signals, buses), or availability of processor capacity (idle time). However, the ECU selection process is not part of this methodology.
The investigations on the use case “Integrate Re-usable Component” assume that the software system executed on the target ECU, which the design function is to be integrated into, was developed according to the Generic Methodology Pattern (see Section 4). Therefore, we assume that it is described in an EAST-ADL model on design level including timing information. This means, that the model contains all components necessary for fulfilling the system’s functionality, and all timing properties of the components are known and described, e.g. WCET and activation periods of functions.
The use case considers two integration scenarios:
A) adding a legacy design function
B) developing and adding a new design function
In scenario A, it is assumed that also for the legacy design function an EAST-ADL model exists which contains TADL2 compliant timing information.
For scenario B, there are two approaches how to start integration:
1) Developing the new design function stand-alone without taking into account interactions with the target system. In this case a separate EAST-ADL model is created for the new design function including timing information. In a second step this new model is merged into the existing one as in scenario A.
2) Developing the new design function directly into the existing model explicitly taking into account interactions with the target system.
The approach B1 starts identically to developing a new functionality from scratch, that is, include treatment of timing information according to the generic methodology resulting in a stand-alone solution. This stand-alone solution would then have to be integrated into the existing solution which is identical to scenario A, i.e. integrating a legacy design function.
In this use case the scenarios A and B1 will be taken into account, so this use case will deal with integration of one EAST-ADL model into another, both models already containing timing information.
The further considerations basically reflect the Design phase. In the Vehicle and Analysis phases, models consist of pure functional components where end-to-end delays are composed by chaining budget segments of the components, and resources are considered to be infinite. Thus models can be investigated stand-alone. In contrast to this, in the Design phase components are declared as to be realized in hardware or software which results in a Hardware Design Architecture (HDA) and a Functional Design Architecture (FDA). On this level, and on the lower Implementation level, the integration aspect can be investigated, i.e. the interference of components due to competition for common resources.
|