Advances in Automotive System Modeling: EAST-ADL (Part 1)
Today, the number of critical and advanced functions has grown significantly. Demands on efficiency and correctness in development, together with the heterogeneity of involved engineering disciplines and technologies, necessitate updating the modeling approaches. Models can address an automotive embedded system in different levels of abstraction typically ranging from consumer visible features, to functional architectures, hardware architectures, software components and finally to detailed implementation. Since multiple stakeholders are involved and have different concerns, models may also address various system aspects, such as requirements, timing and functional safety constraints, resource optimization schemes, etc. Moreover, as the development is normally distributed over several organizations, multiple engineers should also be able to work concurrently while linking with and sharing others designs. To enable concurrent development, faster feedback loop and collaboration, it does not make sense to keep a model like a single diagram editable only for one person at the time.
In regard to system development lifecycle, this means that models are not applied only at the bottom parts of the V-model but also for early level system planning and design phases. A well defined integration of these models allows developers to automate the information and work management and to conduct effective decision-making while avoiding costly faults and delays. In particular, a model-based approach constitutes an important basis for safety engineering, for which a variety of system assumptions and design solutions need to be taken into consideration, such as prescribed by the emerging standard for functional safety of road vehicles, ISO26262.
Figure 1. Applying modeling in V-Model
From modeling a single feature to modeling whole architecture
EAST-ADL is a domain-specific language for the specification and analysis of embedded systems. It aims to address the needs of model-based development of industrial scale automotive embedded systems, which are often time- and safety-critical. The language is domain-specific as the fundamental modeling concepts are based on domain concepts and on some key industrial standards for vehicular embedded systems. For example, the modelling infrastructure and general approach is aligned with AUTOSAR. Compared to other system description languages for embedded systems, EAST-ADL takes a more holistic view on the system development lifecycle and addresses explicitly some key engineering issues, while maintaining a fine-grained traceability across a variety of models for the purposes of information management. As demonstrated in this article, this promotes a more systematic approach to architecture design. For the analytical leverage, EAST-ADL models can be integrated with a wide range of existing modeling technologies and tools. For the final product realization, the system architecture specification made with EAST-ADL is typically realized by more detailed software and hardware solutions (like AUTOSAR, JasPar or in-house architectures).
Example: Starting with features and requirements
Let’s next inspect EAST-ADL and its application using a small example: a Regenerative Braking System with ABS. A typical starting point for the development is features of the vehicle – as illustrated in Figure 2. Here the feature model of EAST-ADL defines the braking system under development by capturing the feature configuration and in particular shows some of the key braking related vehicle functionalities and their dependencies: for instance the optional AdvancedBraking feature is specialized by ABSBraking and by optional ESPBraking, but if ESPBraking feature is chosen also ABSBraking feature is then required. While this example shows just a few vehicle features, feature models can specify and manage the content of each vehicle in relation to the entire product line by addressing the features and their relationships such as in terms of feature dependency and exclusion. For the purpose of customization, market aspects such as models and markets can be organized in a feature model and traced to more technical features (e.g. the choices of particular hardware platforms).
In parallel to the composition of vehicle features, we may start with the specification of vehicle level requirements. EAST-ADL supports capturing different kinds of requirements, including quality related extra-functional concerns, along with their bindings to various artefacts in the system development lifecycle. Requirements can also be imported from existing requirements management tools and aligned with EAST-ADL models. For example, in Figure 2 AdvancedBraking feature satisfies the Anti-LockBraking requirement. Such relation to features, or other kind of model elements, can be then later incorporated back to possibly used external requirements management tools.
Implementation independent architecture
The core part of the EAST-ADL, as its name suggests, focuses on the specifications of multi-levelled system design in terms of architectures. As the first step towards the realisation of expected vehicle features, the complete electric functionality of an automotive embedded system can be specified as an implementation independent functional analysis architecture. Such an architecture specification is characterized by the composition of some interacting abstract application functions. Each of these functions is specified by its input-output interfaces, execution patterns, as well as related behavioural and extra-functional constraints. Figure 3 shows a part of the ABS related functional architecture specification. Here ABS_1 function is connected with a brake force request to Brake_1, which is an abstract actuation device (FunctionalDevice). This brake actuation device then provides a physical energy flow representing the actual brake torque.
EAST-ADL follows a type-prototype pattern for component definition and instantiation. For example, the function types such as the ABS and BrakeActuator, can be instantiated multiple times for the different brake instances (in this electric vehicle there are actually four brake function prototypes – one for each of the four brakes).
Similarly to the feature models, the various requirements can be mapped to individual architectural elements, enabling tracing and analysis on how the system meets the various requirements. Here the ABS_1 function is satisfying a Brake force reduction requirement derived from the requirements already presented in the feature model (Figure 2). This is because as the ABS_1 function, together with other functions for wheel speed monitoring, ABS control, brake torque actuation on each of the four wheels, constitutes the control loop that realizes the ABSBraking feature. The ABSBraking feature specialises the AdvancedBraking feature and thereby inherits the requirements. Based on EAST-ADL, the tool support enables tracing to see for example which are all the features and functions that satisfy a particular requirement. The mapping and trace to requirements can be specified in functional architecture models as in Figure 3, or in separate views as in Figure 4, showing functions satisfying particular requirements.
Moving to design architectures
The concrete realization of the abstract functionality is first considered in a technical architecture specification, referred to as functional design architecture. It specifies the refinements of analysis architecture for the realizations on a particular software and hardware platform (e.g. through partitioning and allocations of the abstract application functions). An illustration of this is shown in Figure 5. Here BrakeRR design function receives three different kinds of data: requested torque, wheel speed and vehicle speed. This function is connected to a local device manager sending the signal to the hardware function. This hardware function then provides the physical energy to BrakeTorque_RR.
In parallel with functions, EAST-ADL allows designing hardware architecture, consisting of sensors, actuators, power supplies and ECUs. Figure 6 shows a part of the hardware architecture where BrakeRR function from functional design in mapped to HW architecture. Sensor Encoder_RR provides Revolutions Per Minute via IOConnection to ECU_RR node which then sends the requests to the brake located in rear right. All the hardware components have an in port for power. ECU node component is also connected to the network via the communication ports.
Figure 7 shows the allocation of functions to nodes.
Part two will cover Behaviour description and analysis, Dependability modelling, and Mapping to existing software architecture.
About the authors
DeJiu Chen received his PhD degree in Mechanical Engineering with a research on embedded computer control systems from KTH. His research interests are on systems and software architecture, model-based engineering, dependability and self-adaptive embedded systems. He has been actively involved in several research projects, including NFCCPP, ATESST, DySCAS, ATESST2, and MAENAD. From 2007 to 2009, Dr. DeJiu Chen also worked for Enea Data AB, Sweden, as a senior technical instructor. He is currently an associate professor at KTH.
Lei Feng is currently an assistant professor at the Department of Machine Design, KTH Royal Institute of Technology, Sweden. He received his Ph.D. degree from the Department of Electrical and Computer Engineering, University of Toronto, Canada, and Master’s and Bachelor’s degrees from the Department of Mechatronics, Xi’an Jiaotong University, China. His research interests include formal verification using model checking, supervisory control theory, discrete-event systems, and advanced control applications in automotive engineering. From 2009 to 2011, he was a research engineer at Volvo Technology AB in Gothenburg, Sweden.
Henrik Lönn has a PhD in Computer Engineering from Chalmers University of Technology, Sweden, with a research focus on safety-critical real-time systems. Currently at Volvo Group, Advanced Technology and Research, he has worked with prototypes, architecture modelling and communication aspects on vehicle electronic systems. He is also participating in national and international research collaborations on embedded systems development. Previous project involvement includes X-by-Wire, FIT, EAST-EEA, ATESST and TIMMO. He is currently coordinating the FP7 MAENAD project.
Juha-Pekka Tolvanen is the CEO of MetaCase. He has been involved in model-driven approaches, metamodeling, and domain-specific modelling languages and tools since 1991. He has acted as a consultant worldwide on modelling language and code generator development. Juha-Pekka has co-authored a book on Domain-Specific Modelling (Wiley 2008) and written over sixty articles for software development magazines and conferences. He holds a Ph.D. in computer science and he is an adjunct professor at the University of Jyväskylä, Finland.