Architecture description languages (ADLs) allow specifying system information in architecture models. These are generally used for capturing early design decisions concerning system or software development. Therefore, ADLs can be utilized for an early and iterative validation of the modelled system. With EAST-ADL an automotivespecific ADL is defined which allows describing an automotive system at different layers of abstraction targeting AUTOSAR systems. SystemC is an executable system modelling and simulation language which permits Hardware/Software-Co-Design. With the Transaction-Level Modeling (TLM) methodology the description of different layers of abstraction in SystemC is enabled. This work addresses the early validation of automobile electronic systems by providing a transformation of EAST-ADL models to SystemC at different layers of abstraction. This allows specific analysis with Hardware/Software Co-Simulation iteratively in the development process. The proposed approach is realized in a tool-chain and demonstrated by a typical automotive use case. Hence, we show the potential of an early validation of system and software designs based on architecture models.
Model-driven design has been successfully introduced into diverse application
areas for abstracting from complex systems. With Architecture Description
Languages (ADLs) a solution is provided to capture design information on a high
level of abstraction [
The automotive domain poses an area with complex interconnected
embedded systems. Domain-specific modelling languages have been introduced to
realize distinct functional behaviour. As this alleviates the development of
single applications, with the more interacting functionality a more course-grained
view on the overall system is needed. EAST-ADL [
Since the application of SystemC for a simulation-based validation of automotive electronic systems is a promising approach for design exploration and hardware sizing, its integration within the architecture design has to be pursued. Therefore, we introduce in this work an adoption of SystemC in the development process with architecture descriptions based on EAST-ADL. An automatic transformation on the different layers of abstraction of EAST-ADL to SystemC is presented in this paper which enables a simulation-based validation. Thereby, architecture models can be iteratively refined and improved in the development process.
This paper is structured as follows. In the next section related work to our approach is described. Afterwards, in Section 3 and 4 the concepts and main language elements of EAST-ADL and SystemC are presented. In Section 5 we introduce at first a mapping of the layers of abstraction of both languages. Subsequently, we detail the transformation of language artefacts of EAST-ADL to SystemC. A case study within the automotive domain shows the applicability of our approach in Section 6. This paper is concluded and an outlook on our future work is given in the last section. 2
In this section we briefly describe related work to our approach with the focus on
architecture descriptions and validation by simulation. The Architecture
Analysis and Design Language (AADL) [
EAST-ADL (cp. Section 3) is a specific ADL for the automotive domain.
It features defined layers of abstraction of the system and an orthogonal single
environment model. The realization of the implementation layer of EAST-ADL
is provided by AUTOSAR. As EAST-ADL was chosen as automotive ADL for
3
this work it is more comprehensively described below. AUTOSAR (Automotive
Open System Architecture) [
The Component Language (COLA) [
An approach to integrate virtual prototyping in the development process of
vehicles is presented in [
EAST-ADL (Electronics Architecture and Software Technology - Architecture
Description Language) [
The upper modelling layers provide an architecture independent system description which can be mapped to the AUTOSAR architecture description on the implementation layer. Orthogonal to the horizontal layers is the Environment Model as it exhibits no abstraction layers. It encapsulates plant models, i.e. models of the behaviour of the vehicle and its non-electronic systems. Functions in the Environment Model are connected with components representing hardware in the Analysis or Design Level by ClampConnectors.
Components communicate with each other through specializations of
FunctionPorts. FunctionFlowPorts are inspired by SysML FlowPorts [
At the most abstract layer, the Vehicle Feature Level, only features of the vehicle are modelled allowing the integration of product variability. Variability at all lower levels can be modelled through VariationPoints. Features can also be grouped and are realized by FunctionTypes. Diverse dependencies between features can be modelled as VariabilityDependencyKind. The focus of the Analysis Level lies on the modelling of the system in a way which is suitable for analysis. The architecture model at this level is called Functional Analysis Architecture. Components can be defined by AnalysisFunctionTypes and FunctionalDevices (the latter represent actuators and sensors on the Analysis Level). AnalysisFunctionPrototypes denote instances of these two. Software components are interconnected by FunctionConnectors.
At Design Architecture Level the software and hardware is represented in distinct models, the Functional Design Architecture and the Hardware Design Architecture. Software components are represented by DesignFunctionTypes or LocalDeviceManagers (the latter represent software interfaces to sensors and actuators). Hardware components are modelled by Nodes (ECUs), Sensors, Ac5 tuators and LogicalBusses. They are interconnected with HardwareConnectors. A LogicalBus represents the allocation target for FunctionConnectors, i.e. exchanged data in the Functional Design Architecture. Nodes are the allocation targets for DesignFunctionTypes and LocalDeviceManagers. HardwareComponentPrototypes are properties typed with the above mentioned hardware types representing instances.
On the transition from the Design Level to the Implementation Level a
mapping to the AUTOSAR meta-model is foreseen. Therefore, modelling artefacts
on this level are compliant to the AUTOSAR specification in version 3 [
SystemC is a standardized system modelling and simulation language which
supports Hardware/Software-Co-Design and Co-Simulation. It is standardised
and promoted by the Open SystemC Initiative (OSCI) [
A SystemC model usually consists of several modules (sc module) which may be organized hierarchically. Computation in SystemC is modelled by so-called processes which are enclosed in modules. Processes are inherently concurrent. Communication from inside a module to the outside - mostly other modules - is realized via ports (sc port ). These are connected to channels (sc channel ) by SystemC interfaces (sc interface). This enables the modelling of complex communication structures (e.g. FIFO or network bus) in SystemC.
With SystemC new models can be connected easily to existing hardware or functional models - either in platform-specific programming languages like C/C++ or domain-specific modelling tools, e.g. Matlab/Simulink within the automotive domain. Furthermore, it is possible to include any existing C or C++ library in the own system model. Thus, suppliers, for example within the automotive domain, can interchange pre-compiled hardware or software modules with other suppliers or car manufacturers and do not need to disclose their intellectual property.
To integrate Hardware/Software Co-Simulation effectively in the
development process of networked embedded systems, a stepwise refinement of the
models is necessary. This can be realized by using SystemC because it implements a
top-down design process according to the Transaction-Level Modeling (TLM) [
The OSCI Transaction Level Working Group has defined different levels of
abstraction for TLM [
Architecture models capture information of the system development and allow a simulation-based validation. As described in Section 3 EAST-ADL enables the modelling of a system on different layers of abstraction. With TLM different levels for abstracting the modelled system are introduced in SystemC (cp. the previous Section 4). A combination of this ADL with the SystemC allows for an iterative design with early feedback on the models through Hardware/SoftwareCo-Simulation. For combining the advantages of an ADL and of simulations, the levels of abstraction have to be aligned. Thus, in the following we motivate a mapping of the levels of abstraction of EAST-ADL to the SystemC TLM levels as depicted in Figure 2. The most abstract functional levels in EAST-ADL and TLM are the Analysis Level and the CP. As the Vehicle Level only includes features it is not considered in this mapping for a simulation of the system behaviour. The TLM level Communicating Processes (CP) represents parallel processes which communicate via point-to-point connections. On the Analysis Level the inter-dependencies between the modelled functionalities and their externally visible behaviour are described. The functions of the Analysis Level represent abstract, communicating components. Thus, they can be transformed to parallel communicating processes and a mapping of the Analysis Level to the CP is possible. A specific transformation of the EAST-ADL component of this level is shown in the following section. As CPT adds timing annotation to the CP it corresponds to the Analysis Level with consideration of timing in the model.
On the next more detailed level are the EAST-ADL Design Level and the TLM PV. The Programmer’s View (PV), additionally to the CP, incorporates bus architectures and arbitration of the communication infrastructure. Also, the Design Level introduces hardware models and bus infrastructure in EAST-ADL and refines the more abstract layer. Thus, the Design Level of EAST-ADL with its modelled software and hardware distributed on several ECUs may be mapped to the PV in SystemC. The software functions (DesignFunctionTypes) represent the processes and the hardware with interconnecting buses can be modelled as hardware architecture and corresponding communication infrastructure. Because the Programmers View with Time (PVT) includes more precise timing information than at CPT level, it is consistent with a model at the EAST-ADL Design Level with timing.
The most detailed functional abstraction layer in EAST-ADL is the Implementation Level. It is represented by AUTOSAR models and includes the most detailed and accurate system information. As this level is platform specific, represents a specific implementation and provides the necessary detailed information for a cycle-accurate simulation, it can be transformed to the TLM Cycle Callable Level (CC). The latter is cycle accurate with respect to individual clock cycles and thus well suited for simulating time-accurate AUTOSAR models. The aligned levels of abstraction as shown in Figure 2 include specific artefacts of the modelling languages which need to be transformed for a mapping. These are in the focus of the next subsection. 5.1
Mapping of EAST-ADL Artefacts to SystemC TLM
In the previous section we pointed out the general commonalities of the
different levels of abstraction of EAST-ADL and SystemC. For an integration of a
validation in SystemC the single artefacts of EAST-ADL have to be mapped
to SystemC language elements. In the following we address such a mapping for
the structural parts of the upper two functional levels of EAST-ADL the
Analysis Level and the Design Level. As the Implementation Level is realized with
AUTOSAR models, a mapping does not relate to EAST-ADL but to the
AUTOSAR meta-model. Thus, a simulation with SystemC TLM can be realized by
an approach based on AUTOSAR software components as presented in [
The following mapping focuses on the structural parts of the languages as
the behaviour is not modelled explicitly in EAST-ADL (s. Section 3). Timing
definitions have been integrated as non-funtional properties in the last version of
EAST-ADL. As this relates to the non-functional property timing, it does not
define the functional behaviour. An integration of the EAST-ADL timing semantics
(Timing Augmented Description Language [
The orthogonal Environment Model can be represented by a single sc module which includes the environment behaviour as sub modules, e.g. as code generated from a Matlab/Simulink model. ClampConnectors are specific elements for interfacing environment components with the horitontal Functional Analysis Architecture and the Functional Design Architecture. This connections can be realized with sc channels and sc interfaces in SystemC.
In the previous section the general relation of the Analysis Level of EASTADL and the CP level of TLM has been explained. For a specific mapping of these levels rules for transforming the EAST-ADL artefacts to SystemC elements have to be defined. As shown in Figure 3 EAST-ADL components can generally be represented by sc modules. The EAST-ADL ports and connectors can be transformed to sc ports, sc channels and sc interfaces.
At Analysis Level sensors and actuators are represented by FunctionalDevices. AnalysisFunctionTypes are used to model functions. These components can directly be transformed to sc modules. FunctionFlowPorts are ports for a data flows between AnalysisFunctionTypes. FunctionClientServerPorts can be utilized for function calls through a defined interface. Ports are interconnected by FunctionConnectors. The ports and connectors are transformed to simple sc signals or sc channels and sc interfaces at CP level. At Design Level the simulation of software functions distributed over hardware platforms (ECUs) is addressed. Therefore, we introduce a SystemC-based framework which allows the modelling of automotive-specific elements in SystemC PV, like ECUs or software functions. As shown in Figure 4 the system is simulated in our approach at PV with software functions scheduled on ECUs communicating via interconnecting buses. The respective components in SystemC are specialized sc modules. For example, a DesignFunctionType is mapped to a software function (SWF) defined in the framework which is derived from a sc module.
A general mapping of the EAST-ADL elements at Design Level to SystemC is depicted in Figure 4. The Design Level consists of software and hardware models. DesignFunctionTypes represent software functions. Software interacting with hardware sensors and actuators are modelled as LocalDeviceManagers. The hardware components at this level are Sensors, Actuators and LocalBuses. These components can be transformed to sc modules at PV level as mentioned above. HardwarePorts and HardwareConnectors are transformed to sc channels and sc interfaces level. An extract of the main EAST-ADL elements and their corresponding SystemC elements is given in Table 1. In the next section these transformation rules are applied in an automobile case study emphasizing their applicability for enabling an iterative validation within the development process based on an architecture model. 6
The use of architecture models for a validation by simulation is evaluated in a case study for the previously described transformation of EAST-ADL to SystemC. Thereby, the focus of this work lies more on the structural mapping and generation of simulations than on the validation or analysis itself.
The afore introduced transformation of EAST-ADL models to executable
SystemC models has been realized in a prototypical tool-chain. For evaluation
purposes an automotive case study [
The exterior light feature allows controlling the front and rear lights of the vehicle. The lights can be switched on/off manually or automatically through darkness or rain detected by the rain/light sensor. These inputs are interpreted by the function exterior light control which controls the light units (front and rear). For the direction indication a direction indication switch can be used to signal the turning direction. With the hazard light switch, risky driving situations can be signalled to other road users. Therefore, the direction indication master control informs the direction indication front and rear controls about the designated status of the direction indication lights. These turn the direction indication lights on or off in the front and rear light units. Central door locking allows locking and unlocking all doors simultaneously by using the key in the lock or by radio transmission. A radio receiver signals the information to the central door locking control. This function flashes the direction indication lights for a feedback to the driver and controls the four door locks of the car. An additional feature to the un-/locking of an automobile is the keyless entry. A driver can approach his car with the key in his pocket and the doors will unlock automatically. It can be locked by simply pressing a button on the door handle. Antenna components detect the key in the surrounding and inform the central door locking function which in turn unlocks the doors. With respect to the interaction with exterior light (which gives feedback via the direction indication lights), it does not make any difference whether the doors have been unlocked in a standard way or via the keyless entry. In the following a realization of these features at Analysis Level and Design Level of EAST-ADL is described with its corresponding SystemC implementation.
At Analysis Level this use case is modelled in EAST-ADL by the FunctionalDevices KeylessEntryController, CentralDoorLockingController, DirectionIndicationMasterController, DirectionIndicationFrontController, DirectionIndicationRearController and ExteriorLightController as can be derived from Figure 5. The behaviour of these functionalities is described as opaque behaviour of the components (C++ source code). Additionally, behaviour can be modelled with straight-forward UML Statecharts providing a UML based behaviour specification. Communication is designed as data flow represented by FunctionFlowPorts and FunctionConnectors.
A SystemC simulation generated from this level includes modules interconnected for each of the above mentioned FunctionalDevices. They implement the respective behaviour of these modelled components in a thread of the module. With this transformation a simulation based on the Analysis Level in EASTADL of the use case was realized. Thus, the interaction of the abstract modelled functionalities can be validated with a simulation-based analysis.
At Design Level the use case is modelled in a Functional Design Architecture (FDA) representing the software parts and a Hardware Design Architecture (HDA) representing the hardware parts of the use case realization. The FDA includes DesignFunctionTypes for the software functionalities of the use case and LocalDeviceManagers representing the software access to the modelled sensors and actuators. The latter are designed in the HDA together with the hardware platforms (Nodes) and the interconnecting LocalBus. Components in the FDA are interconnected with FunctionConnectors and in the HDA with HardwareConnectors. An overview of the elements modelled at Design Level for the use case is shown in Figure 6. Additionally, LocalDeviceManagers exist for each depicted Sensor and Actuator in the Functional Design Architecture which are not explicitly displayed in this figure. The generated SystemC implementation of the use case at Design Level is depicted in Figure 7. It includes the use of a framework for automotive-specific modules. For example, ECUs and software functions can be included out of a library as specific sc module implementations (cp. Section 5.1). As can be derived from Figure 7 the EAST-ADL Design Level components are generated as sc modules representing software functions. These modules are included in another SystemC module which realizes a hardware platform with attached sensors and actuators in form of sc modules. These hardware platforms are interconnected by a module implementation of the defined LocalBus. SystemC interfaces and channels realize the concrete interconnections of the modules. For example, a specialized type of sc interface (EcuSw If ) realizes the communication between software functions and ECU modules.
The introduced transformation is realized in a prototypical toolchain which integrates into the Eclipse environment as a plug-in. By this, it can easily be used with EAST-ADL models based on UML in Eclipse (e.g. with the Papyrus UML modelling tool which supports EAST-ADL). The transformations itself are implemented as templates of the Xpand model-to-text transformation language. They use EAST-ADL models as input and generate the particular SystemC files with respect to the previously introduced mapping of the languages. Currently, simulations can be generated from the Analysis Level or Design Level. Simple checks allow to check the conformity for a simulation. Because a generation of incomplete models in early design stages should be possible, the checks are only as strict as needed for generating correct SystemC simulations. This supports the iterative simulation of ADL models in the design process. For the simulation at Design Level we utilize a self-developed framework (cp. Section 5.1) called DynaSim which allows the modelling of an automotive in-vehicle network in SystemC. The generated files refer to SystemC models in the DynaSim library (e.g. ECUs or software functions). By this, a simulation can be performed considering the automotive-specific system environment. Future work will be the automatic feedback to the model as well as the integration and analysis of timing definition semantics. 7
Architecture Description Languages capture design information in architecture models. A simulation of these models in the development process allows an early validation. In this work we have briefly described the automotive-specific EASTADL and system modelling language SystemC. We showed that simulations from EAST-ADL can be generated automatically by a transformation to SystemC. Therefore, the EAST-ADL layers of abstraction were compared and mapped to corresponding layers of SystemC TLM. Also, transformation rules for the modelling artefacts of EAST-ADL with their concrete target elements in SystemC were presented. The approach was evaluated with an automobile case study with respect to the generation of simulations from EAST-ADL models on two different layers of abstraction. For this purpose a prototypical toolchain was built which allows the automatic generation of SystemC simulations from EAST-ADL models. By this, we showed that our approach allows the iterative simulation-based validation of automobile functions at different layers of abstraction.
In future work we plan to refine this approach by focusing on the simulation and preservation of non-functional requirements (e.g. timing) and integrating externally defined models. Additionally, more detailed automotive-specific SystemC models will be integrated in the simulation for a more precise analysis. A special emphasis will be taken on the design and simulation-based validation of adaptive embedded systems.