Towards Harmonizing Multiple Architecture Description Languages for Real-Time Embedded Systems

Tahir Naseer Qureshi, Martin Törngren, Magnus Persson, De-Jiu Chen, Carl-Johan Sjöstedt Division of Mechatronics, Department of Machine Design KTH-The Royal Institute of Technology Stockholm, Sweden {tnqu, martin, magnper, chen, carlj}@md.kth.se

Abstract— The increasing complexity of real-time embedded solutions in model-based development. It exists in different systems requires appropriate methods and techniques to support forms depending on the applied industrial or application the development including the specification and analysis of domain. According to IEEE 1471 standard [3], an architecture different architectural aspects. A large number of architectural is defined as: description languages (ADL) have been proposed with varying focus and application domains. There is a need for “The fundamental organization of a system embodied in its harmonization of these ADLs. This can be from develoloping and components, their relationships to each other, and to the understanding of how they differ or could be synergistically environment and the principles guiding its design and combined for increasing the overall development efficiency and evolution” fulfilling the ever increasing functional and non-functional requirements on a system. This paper addresses this issue and While an architectural description is the specification of an focuses on four different ADLs: EAST-ADL, AUTOSAR, AADL architecture, an ADL provides the syntax, either textual or and Rubus. In this work we compare these ADLs, identify graphical, for an architecture description. The need for possible usage scenarios involving more than one ADL and expressing and describing architectures of real-time embedded discuss some of the underlying challenges. A representative systems has been expressed for several decades. This need has industrial case study of a brake-by-wire system is used to support been especially motivated for system integrators, which have to the work. build a system out of a large number of functions and (software and hardware) components. An example of an early ADL is Keywords-Architecture description language (ADL); AADL, MetaH, which later evolved into the AADL (now standardized EAST-ADL, AUTOSAR; Rubus; Complexity management; by the SAE), [9]. embedded systems; model transformation. Modeling languages like UML [4] or SysML [5] provides some generic solutions for architectural descriptions. However, I. INTRODUCTION specific solutions e.g. MARTE [6] targeting specific aspects of The complexity of embedded systems and their a real-time system is emerging in the form of new UML development process has increased considerably during the last profiles. In addition there also exist proprietary ADLs e.g. few decades. A few of the contributing factors are increasing Rubus [7] 1, and domain specific ADLs, for example as part of number of software components distributed over a network, AUTOSAR [11] and the AADL [9]. their interaction, changing technology, increased non- functional requirements such as safety, comfort, reliability, Associated with the ADLs are tools for performing changing and emerging roles of different stakeholders. different development activities including the specification of an architecture using these ADLs, analysis of functional and Different solutions and methods have been proposed to non-functional properties, synthesis etc. On one hand, some of handle different aspects of the existing complexity. Model- the activities are possible using the same tools used for based development (MBD) [1] in particular has gained the specifying architecture. For example, with OSATE [8], it is attention from industry as well as researchers in the field of possible to specify an architecture using AADL, as well as embedded systems. Depending on context, there exist different perform some non-functional analysis. In contrast, additional interpretations of model-based development. For example, analysis is carried out by other external tools. For example, from control systems engineering point of view, the use of Simulink for behavioral analysis of a system specified using Matlab/Simulink [2] models for design and analysis followed EAST-ADL [12]. In this case the required information is by generation of an executable code for implementation is transferred either manually or automatically from the considered as model-based development. In another context, architecture description to the analysis tool and vice versa. MBD can be the use of UML based graphical model for design and use of some other language for implementation. 1 With Rubus, we refer to the architecture description language that is An Architectural Description Language (ADL) is one of the used for high-level design (not the corresponding real-time operating system). II. COMPARISON FRAMEWORK The comparison presented in this paper is a modification of the framework defined in [16] to align with our objectives. This modified version uses the same naming but different usage for many of the attributes. According to the framework, an ADL can be evaluated from two different aspects; the modeling features and the tool support. The former aspect is Figure 1. Hypothetical relation between EAST-ADL (EA), AADL, further categorized into components, connectors and AUTOSAR and Rubus. architectural configuration. With the above-mentioned facts, the need for A few important aspects compared in the framework are as harmonization (e.g. language combination, tools sharing, model transformation for analysis etc.) is evident. For example, follows: automotive systems are today increasingly being developed  Industrial application for which an ADL was originally using ADLs, and those include at least AUTOSAR-ADL2 [11], developed and applied. Rubus [7] and EAST-ADL [10]. For the same system, these  Characteristics of the constituting components and ADLs can be used with different focuses aspects and levels of connectors such as independence from the platform on abstraction; it is therefore important to understand their which the components will be deployed and the type of relations and how they potentially could be combined. inter-component communications. Moreover, since the ADLs often are developed in close  Support for behavioral modeling and analysis, i.e. to cooperation with research, they also come along for example know the extent on the reliance on external tools as well with advanced analysis capabilities. If ADL models could be as built-in analysis within a specification tool. transformed into other representations with the relevant  Similarly to the last point, the support for the specification properties maintained, it might be possible to reuse new and analysis of non-functional properties is also analysis features. compared. The presented work contributes towards the envisioned  From the overall architectural view, support for scalability harmonization. The relation between the four ADLs; EAST- (i.e. if it is possible to scale the architecture for larger or ADL, AADL, AUTOSAR-ADL and Rubus shown in Figure 1 smaller platform or resources) and traceability between is investigated. The different EAST-ADL (EA) levels different artifacts and requirements are considered. correspond to different abstractions. In particular a comparison  The tools associated with ADLs are compared for their framework is used for a conceptual mapping of the four ADLs specification and analysis support and maturity. and with the help of a case study, additional tool and analysis Further clarification is provided in the table presented in the relations are identified. The case study is a representative results section in the form of questions associated for each industrial brake-by-wire system. This case study has also been evaluated feature. used in the ATESST [12], MAENAD [14] and TIMMO [13] projects. Due to space limitation, the details are not included in the paper. However, we would like to mention that this case III. MOTIVATION AND SELECTION RATIONALE study covers all the levels of abstractions shown in Figure 1, ADLs provide multiple views/aspects of the system to comprises of a large variety of constraints as well as a model enable advanced analysis. They have been lagging in industrial for the environment. While different parts of the case study adoption compared to behavioral modeling approaches. The were specified, modeled and simulated using a few of the tools reason are the challenges in deploying ADLs, including related to the considered ADLs, some of the results were maturing of tools and anchoring with respect to embedded obtained from other relevant information such as language systems platforms (i.e. corresponding abstractions should be specifications. SystemDesk and TargetLink from dSpace [15], possible to map to platform concepts in a sound way – and Matlab/Simulink, OSATE and Rubus Designer are the major tools that support this are required). tools used in the work. For real-time systems, several ADLs can be considered. A The paper is organized as follows: A brief overview of the brief motivation for the selection and exclusion of different comparison framework is presented in the next section ADLs for the presented work are as follows: followed by the presentation of selection rationale in section III. A description of the four ADLs is presented in sections IV -  EAST-ADL and AADL cover a large number of artifacts VII. The comparison results are presented in section VIII. A related to embedded systems, but remain at different levels brief overview of the related work is presented in section IX. of abstraction. Finally, the paper is concluded in section X.  AADL has a long development history, stemming from MetaH, and has further evolved including harmonization efforts with respect to UML/MARTE [6]. Both EAST- 2 Note that AUTOSAR is an automotive software architecture ADL and AADL are very interesting since the have been initiative and that we here refer to the architecture description closely aligned to a number of analysis methods and means that are part of this initiative (and for the sake of brevity, theories, such as different types of safety and timing will use the term AUTOSAR- ADL). analysis. EAST-ADL has incorporated concepts from SysML and has also partly been aligned with MARTE.  AUTOSAR-ADL and Rubus lie on the implementation Performed Hazard Origin and Propagation Studies) [20]. The level. The latter can be seen as a light-weight alternative to latter is illustrated in [21]. the former, with additional focus on specification and handling of real-time requirements [7]. V. AADL  HDLs – Hardware description languages, such as VHDL, AADL (Architecture Analysis and Design Language) [9] Verilog and SystemC, are evolving towards higher-level was originally developed for avionics systems development, abstractions (i.e. transaction level), including both and based on its predecessor MetaH. The focus of AADL lies behavioral and structural abstractions. The main emphasis on the detailed architecture specification and verification. The so far has been on simulation-based analysis. Research language can either be adopted as part of a top-down efforts mainly focus on the functional/behavioral development approach, supporting detailed architecture design evaluation and not primarily on architecture. and integration analysis, or for reverse engineering efforts in modeling and analyzing (changes to) legacy systems. The  MARTE [6] is a UML profile dedicated to embedded real- language specifications [9] do not explicitly specify more than time systems. The MARTE profile is highly relevant but a single level of abstraction (the entire system) or an implied indeed already (at least partially) aligned to both AADL development approach. Similarly to EAST-ADL, it also has and EAST-ADL, and therefore not covered here. core language constructs and the extensions namely error  SysML – the OMG Systems Modeling Language [5] is a modeling for dependability aspects of reliability, availability UML profile specification of embedded systems and its etc., meta-model for XMI/XML annex for supporting additional environment. It supports the specification of requirements, tools, graphical notation for graphical modeling, behavior system dynamics in terms of differential equations etc. modeling, ARINC 653 to support the standard for aircraft SysML is a generic approach, not dedicated to embedded industry, UML2.0 profile to support the use of UML systems and also similar to EAST-ADL. The most common tool used for modeling with AADL is OSATE (An Extensible Open Source AADL Tool IV. EAST-ADL Environment) [8]. It is possible to perform resource and end-to- EAST-ADL [10] evolved from the EAST-EEA and ATESST end latency flow analyses, semantic analysis of modal system projects and been extended and refined in the ATESST2 [12] as well as security level checking directly within the tool project. The EAST-ADL language has also been either adopted environment. This is exemplified by the AADL consortium or being considered in several other research projects including with different case studies. In addition, tools such as Simulink TIMMO [13], EDONA [17] and CESAR [18]. It is partly can be used for analyzing AADL models. One such example is included as an annex in the recent MARTE standard [6]. The [23]. AADL has also been incorporated in the latest MARTE purpose of EAST-ADL is to specify automotive embedded standard [6]. The current evolution includes update of the systems at different levels of abstractions from different views, behavior, data modeling and ARINC annexures. AADL has its providing a domain specific approach for separation of own drawbacks, such as complex component compositions and concerns and information management between different property ambiguity [24]. engineering disciplines. The four abstraction levels in EAST- ADL are Vehicle level related to features and product VI. AUTOSAR-ADL variations, Analysis level specifying higher level AUTOSAR (AUTomotive Open System ARchitecture) functionalities, Design level related to the detailed design, [11] is a standard for dealing with the ever-growing complexity component allocation. This is further divided into Functional of automotive embedded systems. It provides a basis for Design Architecture and Hardware Design Architecture modular software architecture with standardized interfaces and specifying application and hardware architectures respectively, specifications of a run-time environment. Configuration and Implementation level which is the lowest level of the management, e.g. relocation of functionality from one architecture related to the final development phases and computation node to another at development time is also standards such as AUTOSAR [11]. supported by the AUTOSAR standard. The standard also The language has separate packages enabling modular allows the use of commercial-off-the-shelf SW-components. system modeling. Extensions for modeling environment, The result of the AUTOSAR effort is a framework and behavior, dependability, and timing etc. are also provided. methodology [25] for standardized automotive software and These extensions are allowed at different levels of abstraction hardware. A six-layered software architecture is a part of the and enables the separation of the description of design function AUTOSAR framework. The layers are Application, Run Time behaviors and the specification of related constraints for such Environment (RTE) providing middleware functionality, behaviors like timing and safety. Service, ECU (Electronic Control Unit) Abstraction, Complex EAST-ADL can be used with several tools. However, the Drivers, and Micro-controller Abstraction [26]. While the ECU most commonly used tool for modeling using EAST-ADL is abstraction is the lowest layer, the Application is the highest PapyrusUML [19]. External tools are used for different kinds one. The AUTOSAR atomic software components are of analysis such as simulation and safety analysis. Examples of categorized into application and infrastructure. While the external tool usage scenarios include model checking using former is related to providing software functionalities such as SPIN [21] and error analysis using HIP-HOPS (Hierarchically control algorithm etc. the latter is used for different services related to an ECU. In addition a concept of virtual functional bus (VFB) is also introduced to resolve control-related relatively simple methodology, starting with functionality integration problems. Furthermore, AUTOSAR supports two design followed by the separation of data and control flows, possible communication types between its components: client- choice of an execution model i.e. time or event-triggering. server and sender-receiver. From analysis and tooling view, Rubus is supported by For the description of architecture and its components dedicated tools namely Rubus Designer, Rubus Analyzer, and standard templates are provided such as [37] for software Rubus Inspector for simulation and analysis provided by components. These templates correspond to the ADL part of Arcticus System AB [7]. A few of the examples of analysis are AUTOSAR providing a means to specify and relate different end-to-end response time, overall stack size, effect of different architectural entities. priority assignments etc. Furthermore, the tools are also integrated with other higher-level analysis tool such as Several types of tools are required and being adapted to Simulink and LabView. Due to this integration, it is possible to configure AUTOSAR-based embedded systems. A few perform co-simulation as well as utilization of automated code examples of the tools include, TargetLink and SystemDesk by generation features of the tools for a final platform-specific dSpace[15] for application modeling, code generation, and implementation. system design. Similar tools are also provided by Vector [27]. Configuration of ECUs is carried out using tools such as PICEA SUITE from Mecel AB [28]. VIII. COMPARISON RESULTS AUTOSAR and its ADL are evolving with time. The latest A comparison based on the framework discussed in section release, i.e. version 4.0, provides additional support for II is shown in Table 1. A central commonality is that all ADLs dynamic scheduling and introduction of multi-core are based on the concepts of components with ports that architectural concepts. The current evolution includes interact over connections. Components, ports and connectors extensions to address non-functional aspects such as safety are provided with properties that together allow a structural (partial alignment to the forthcoming ISO/DIS 26262 safety system description based on which certain analysis is possible. standard) and timing (findings from the TIMMO project – For all ADLs, a basic emphasis is on the system structure with TADL). essentially black boxes (components), where the contained behavior would be expected to be expressed using different formalisms (e.g. C code, a Simulink model, etc.). The ADLs VII. RUBUS mainly capture so called execution behavior, which is related to Rubus [7] is an ADL for the specification of safety-critical components execution timing and the method for sharing embedded system architectures. It originated from resources. However, different types of components are BASEMENT [29] and has been used in many industries related supported and with somewhat different assumptions on the to both the automotive and avionics domain. Rubus has been underlying models of computation and properties of interest. used as a real-time operating system for many years but now it It is only EAST-ADL which explicitly supports the has an ADL layer on top of it. The main artifact of Rubus ADL specifications of requirements, product features and variability. is its component model (CM). While the latest version i.e Although AUTOSAR-ADL only covers a single level of RubusCMv3 is presented in [36], RubusCMv4 is under abstraction, it is the most complex and detailed. This is due to development. A few of the objectives of Rubus are the support its large variety of components including platform specific for an overall system view and reasoning about different ones. Tool support in general is not so mature for most of the aspects at a higher level of abstraction, separation of views considered ADLs. From the architecture specifications such as functional and temporal enabling the specification of perspective, only OSATE is found to be mature. The both real-time requirements and properties, early analysis due specification tools for other ADLs need further refinements to a formal syntax providing estimates of implementation especially for stability. Because of Simulink’s dominating aspects such as memory consumption. position, most of the ADLs try to take a position with respect to Similar to an atomic software component in AUTOSAR- it, for example by developing mappings between ADLs and ADL, the basic artifact is a software circuit (SWC)3. A SWC Simulink. Therefore, it can serve to be a part of envisioned can have one or more associated behaviors, interfaces and harmonization. For example, using is as the common tool for internal state data. The execution method followed by a SWC simulating behavior and code. is run-to-completion. It also uses the concept of composite (as In addition to the above, it is also observed that the in AUTOSAR-ADL), which is a collection of SWCs where the combined coverage of the four ADLs considered is enormous SWCs can be distributed into different computing nodes. In including multiple engineering disciplines and concerns related contrast, a collection of SWCs called an assembly can only be to the development of embedded systems. Therefore, it is non- allocated to one single node. The concept of an overall mode of trivial to cover all the harmonization possibilities in this paper. a system can also be specified. Additional artifacts of Based on the comparison table and the experience from the RubusCMv3 include items such as clock, interrupt or events, case study, a subset of different scenarios for language and tool down-sampling and precedence. In terms of timing usage illustrated in Figure 2 are identified. One major requirements deadline, offset and periodic jitter can be assumption for this scenario is that the development follows a specified. In contrast to AUTOSAR-ADL, Rubus provides a top-down EAST-ADL development methodology [30]. The methodological choice is due to the higher abstraction levels 3 Although the short form of an AUTOSAR software component and supported by EAST-ADL lacking in other ADLs. The a Rubus Software circuit is same, the concept is not the same.

Figure 2. Language and tool usage scenarios.

Table 1: Comparison of Architecture Description Languages for Automotive Embedded Systems Category Features Related Questions AADL EAST-ADL AUTOSAR-ADL Rubus

applicability

Scope and Generic. Initially Developed specifically Is it generic or specific developed for avionics Generic and applicable for automotive systems Automotive specific for an application system but now to different application but applicable in other software architecture domain? applicable to domains. domains automotive as well. Characteristi The components are The components are Depending on the usage The components are platform independent platform independent the components can be platform independent cs Are components but it is also possible to but it is also possible to both platform but require platform platform independent? specify platform related specify platform related independent and platform specific attributes for components. components. specific. analysis. Interfac What is the point of e interface for a Ports and port groups. Ports and port groups. Ports and port groups. Port component? Analysis function type Software (data. and prototype, design Subprograms, function type (Basic subprogram calls,

Types software function type, Application Software, What are the different threads, thread groups, local device manager, Service, ECU abstraction, kinds of instanstiable processes, pre-declared Software circuit hardware function type). Complex device driver, components? runtime services) and The hardware function Sensor Actuator. Execution (Processors, Support for modeling components components for modeling Support has sub-types of node, Memory, buses, power supply and devices). logical data bus) The fundamental Basic behavior such as The behavior of a SWC Basic behavior such as behavior entity of modes is part of the core is specified by its modes is part of the AUTOSAR is a runnable language. For additional source code. The code core language. For (smallest code fragment

Behavior How is the behavior behavior description the is obtained by external additional behavior provided by a specified? Is it possible EAST-ADL behavior tools. Similar to description, AADL component). The code is to use external tools / extension can be used. It AUTOSAR it is also behavior annex can be obtained by external languages to define is also possible to possible to define used. External tools can tools. In addition it is also behavior? associate external modes of a system be used for generating possible to define modes models e.g. Simulink which in turn can be code an AADL of a system which in turn file to EAST-ADL used for different component. can be used for different components. configurations. configurations. Constraints are defined Constraints are specified It is possible to specify as the properties of How are different kinds either by requirements execution constraints as a

Constraints Constraints different components. of constraints applied or specific constructs part of the behavior Currently Rubus The examples period to the components and provided by the definition. For example a supports timing for execution, priority behavior? Is it possible extensions (e.g. timing constraint can correspond constraints i.e. deadline, or security level etc. via ports? Do or safety). Additional to an RTE event for offset and periodic Additional constructs additional constructs constructs can be triggering a runnable or jitter. can be provided by exist? provided by developing an inter-runnable variable developing additional extensions. for data sharing. libraries. Evolution Is it possible to use EAST-ADL explicitly The library of the Sub-typing and Sub-typing and instances sub-typing mechanisms supports component components allows sub- instances are possible are possible for components and its prototyping mechanism. typing and instantiation Category Features Related Questions AADL EAST-ADL AUTOSAR-ADL Rubus features for systematic to some extent. evolution of the architecture? properties properties functional Security levels, priority,

Non- Which additional non- timing and Functional safety and functional properties computational Timing. Timing timing. can be specified? resources e.g. memory and bandwidth. Characteristics Characteristics The connectors in an Does the language AADL differentiates EAST-ADL have AUTOSAR architecture provide any difference Rubus differentiates between functional, different connectors for can be considered as between logical, between data and logical and parametric logical, functional, virtual as dependencies functional and physical triggering. connections physical connections. between different ports is connectors? handled by the RTE. Interfac Sender-receiver, client

e Which kind of Sender-receiver, client Event and data. server and Data and trigger. interfaces is supported? server and mode-switch. communication channel. Connectors Connectors

Semantics Semantics Yes. The AADL The EAST-ADL Do the connectors specifications specify specifications specify The semantics are The semantics are follow any specific semantics for its semantics for its inherited form the inherited form the semantics? connections e.g. connections e.g. one associated ports. associated ports. immediate or delayed. size overwrite buffer.

Types Functional, Port connections, There exists no There exists no What are the different communication, parameter connections, categorization of categorization of kinds of connectors? hardware and clamp access connection connectors. connectors. connectors. properties functional Is it possible to specify It is possible to use the Non- non-functional Yes by defining the extensions to specify Not explicitly. Not explicitly. properties such as end- end-to-end flows. non-functional to-end time etc.? properties. specifications Understanda Depending on the tool With the graphical

ble used, the specifications support of the available Are the specifications Yes. Specifically with Yes. Specifically with are understandable for tool, the architectural easily understandable? the graphical support. the graphical support. overall system specifications are easily configuration. understandable. abstractio Levels of How many and which All levels of abstraction The design level and to Implementation level ns abstraction levels are but with weak support Implementation level and some extent the and partially design supported by the for the implementation partially design level. implementation level. level. language? level. sitionali Compo Is it possible to specify Component typing and The concept of ty ty It is possible. This is A composite SWC can hierarchical prototyping is used for composition is provided also described in [24] be defined. composition? this purpose. for this purpose. Does the language Architectural Configurations Architectural

Refinements and and Refinements provide any explicit

Traceability traceability support No support for No explicit support for between requirements No explicit support for requirements requirements and different artifacts? This is one of the main requirements traceability traceability and traceability and Does the language features of EAST-ADL. and architectural architectural architectural provide any constructs refinements. refinements. refinements. relating architectures at different levels of abstractions?

Scalability Scalability is dependent Similar to AUTOSAR , Are the architectural Using the biding on the selected Scalability is one of the Rubus components can configurations mechanism, scalability implementation main features of also be scaled for scalable? is obtained. platform e.g. AUTOSAR. different hardware AUTOSAR platforms

Variability EAST-ADL supports Does the language To limited extent. It is product line variations. support handling of possible to specify Although not explicit, No explicit support for No explicit support for variations and versions different configurations but the same support variations. variations. of architecture and later use the can be used for function configurations? binding mechanism. variations. properties properties functional Non- Is it possible to Depending on how a It is possible by utilizing Non-functional property explicitly specify non- system is perceived. the same extensions specifications are not Rubus does not support functional properties For example a used for specifying non- explicit. However, some specification of non- for overall architectural component can functional properties of timing aspects are part of functional properties. configurations? correspond to a system components and a component behavior. Category Features Related Questions AADL EAST-ADL AUTOSAR-ADL Rubus of its own. connectors. Example

Tool What are the examples A few examples Prototype tools like

s DaVinci developer, Rubus Designer is the of the tools for system include, OSATE, PapyrusUML and one SystemDesk. only tool available. specification? STOOD and ASSERT. by MentorGraphics. Multiple views Multiple views In addition to graphical It is possible to use both Do the tools support It is possible to specify and textual description graphical and textual Only graphical multiple views of an an architecture using support, EAST-ADL description. AUTOSAR representation is architecture i.e. text, graphical and textual also supports different also provides separation supported. No special graphical etc.? format. views such as safety, of hardware and software view is supported. hardware and software. architecture. Analysis support Analysis support

Tool support Some simulation is With OSATE, it is EAST-ADL relies Is it possible to perform possible using the tools. It is possible to perform possible to perform entirely on external analysis using the However, due to the some timing analysis. analysis such as tools i.e. no support specification tools or inherent AUTOSAR For behavior, Simulink security, flow etc. provided by the additional tools are complexity, analysis is models can be linked to Additional tools can architecture required? also complex requiring Rubus SWC. also be used. specification tool. external tools. EAST-ADL relies on external tools for The tool support is

Maturity Maturity The tool support for analysis. However, the limited but mature The tool support is quite AADL is quite mature transformation of enough to support the How mature is the tool mature for executing for analysis, information between objectives of Rubus support? AUTOSAR specification as well as specification and based architectural methodology. implementation. analysis tools is at specification, analysis prototype level and and implementation. therefore, not so mature.

IX. RELATED WORK identified scenarios are as follows: Architectural description languages have been surveyed and  AADL support for EAST-ADL methodology in two ways. compared by a number of researchers each with different Firstly, the AADL behavior annex can be used to specify perspective and focus. In [16] a framework for classification behavior of EAST-ADL components. On the other hand, and comparison of different ADLs is presented. The EAST-ADL models at design level can be transformed framework is divided into four main categories of components, into AADL for the analysis already supported by AADL connectors, architecture configurations and the available tool tools. Although, the two ADLs do not share the same support. Each category has its own attributes such as abstraction levels, the commonality mentioned at the start “Refinement and Traceability” for the category of architecture of this section can be exploited for the transformation and configuration. A taxonomic survey of ADLs is also presented analysis. in [31] where the classification is made on the classes of the supported systems, inherent properties of the language and the  For additional functional and non-functional analysis, tools technology support provided. These two surveys provide a such as Matlab/Simulink or HIP-HOPS can be used with good overview of different characteristic and comparison of the help of model transformations between the tools and then existing ADLs. ADLs similar to [21]. In another effort [32], the authors surveyed different ADLs  AUTOSAR-ADL, Rubus and AADL an be considered as developed for the design and implementation of micro- three alternate implementation platforms It may be architectures of processors from a model-based development required to transform Rubus models to AUTOSAR-ADL point of view. if compliance to standards is required. On the other hand AUTOSAR models can be transformed to Rubus models if A survey on different methods for modeling embedded a simple or highly safety critical implementation is computer systems is presented in [33]. The main focus is on the required. The transformation will only be possible with a languages for embedded system design. The authors also restricted subset of AUTOSAR-ADL. The transformation followed a model-based development approach for designing to Rubus can also lead to the use of analysis support by embedded systems. The framework used in this work had five dedicated Rubus tools for safety critical systems. categories of Contents, Design Context, Analysis Context, Language, and Tools. Just like [16], the categories have their A few of the challenges to achieve the above mentioned own attributes covering aspects such as abstractions, details, usage scenarios are the lack of concrete mapping between and the relations between these attributes. The survey resulted different artifacts of ADLs, closed source code of the tools and in a comparison of 12 different ADLs. their meta-models, which restrict the model transformation for analysis, lack of standard ways to represent results of different With the passage of time, the different ADLs surveyed in analysis obtained from different tools. the above-mentioned work have either further evolved or became obsolete. Moreover, the introduction of graphical languages such as SysML [5], UML [4], tools such as Matlab/Simulink [2] and the increasing number of disciplines http://www.timmo.org/ and views of embedded systems, different domain-specific [14] MAENAD Consortium (2011, May), MAENAD Website, [Online], solutions have been proposed. http://www.maenad.edu/ [15] dSPACE. (2009) dSPACE website. [Online]. X. DISCUSSION AND CONCLUSION http://www.dspaceinc.com/ww/en/inc/home.cfm [16] N. Medvidovic and R. Taylor, "A Classification and Comparison In this paper, we have provided a comparison of four Framework for Software Architecture Description Languages," IEEE architecture description languages related to real-time Transactions On Software Engineering, vol. 26, no. 1, pp. 70-93, Jan. 2000. embedded systems. In addition, we have also identified usage [17] EDONA Consortium. (2010, Jul.) EDONA:Environnements de scenarios and associated challenges possible while using the Développement Ouverts aux Normes de l'Automobile. [Online]. considered ADLs. This work can be considered as a step http://www.edona.fr/home/index.htm. towards increasing the overall efficiency of the embedded [18] CESAR Consortium. (2010, Jul.) CESAR Project Website. [Online]. systems development process by utilizing the existing http://www.cesarproject.eu/ formalisms and tools. A more fine grained mapping between [19] CEA LIST. (2010) PapyrusUML. [Online]. http://www.papyrusuml.org/ different ADLs, including aspects such extent of modularity [20] Y. Papadopoulos, J. A. McDermid, R. Sasse, and G. Heiner, "Analysis and and scalability, support for different models of computations, Synthesis of The behaviour Of Complex Programmable Electronic Systems In variability support, safety and security analysis can be Conditions of Failure," Reliability Engineering and System Safety, vol. 71, no. 3, pp. 229-247, Mar. 2001 considered as the possible future extensions of the presented [21] M. Biehl, C. DeJiu, and M. Törngren, "Integrating Safety Analysis into the work. These results are also the basis for our work in the Model-based Development Toolchain of Automotive Embedded Systems," in MAENAD [14] project targeting future solutions of full In Proceedings of the Conference on Languages, Compilers, and Tools for electric vehicles. We are currently refining the EAST-ADL Embedded Systems LCTES'10, Stockholm, 2010, pp. 125-131 behavior annex, developing tool specific extensions of the [22] L. Feng, DJ. Chen, H. Lönn and M. Törngren, “Verfiying System behavior annex for a native representation of different tools, Behaviors in EAST-ADL2 with the SPIN Model Checker”, IEEE International mapping scheme between different ADLsand improvement of Conference on Mechatronics and Automation. Xi’an, China, August 4-7, 2010. current plug-ins for Simulink and HiP-HOPS [21]. The [23] P. Feiler, "AADL and Simulink," Software Engineering Institute, Carnegie additional analysis tools which are currently being addressed in Mellon, 2006. MAENAD are Modelica, UPPAAL, SPIN model checker, [24] S. Gérard, et al., "UML&AADL '2007 Grand Challenges," ACM SIGBED SCADE [34], and MAST (Modeling and Analysis Suite for Review, vol. 4, no. 4, pp. 1-17, Oct. 2007. Real-Time Applications) [35]. [25] The AUTOSAR Consortium, \AUTOSAR Methodology," Tech. Rep. V1.2.1, R3.0, Rev 001, http://www.autosar.org/download/AUTOSAR_Methodology.pdf, 2008 REFERENCES [26] The AUTOSAR Consortium, Layred Software Architecture," Tech. Rep. V2.2.1, R3.0, Rev 001, 2008. [1] M. Törngren, D. Chen, D. Malvius, and J. Axelsson, "Model-Based Development of Automotive Embedded Systems," in Automotive Embedded [27] Vector. (2010, Jul.) Vector [AUTOSAR-A Decision for the Future]. Systems Handbook, N. Navet and F. Simonot-Lion, Eds. CRC Press, 2009, ch. [Online]. http://www.vector.com/vi_autosar_solutions_en.html 10, pp. 1-52. [28] Mecel AB. (2010, Jul.) Mecel Website. [Online]. http://www.mecel.se/ [2] Mathworks. (2010, May) Matlab Website. [Online]. [29] H. Hansson, H. Lawson, M. Strömberg and S. Larsson, "BASEMENT a http://www.mathworks.com/ Distributed Real-Time Architecture for Vehicle Applications," Real-Time [3] IEEE, "IEEE Recommended Practice for Architectural Description of Systems, vol. 11, no. 3, pp. 223-244, Nov. 1996. Software-Intensive Systems -Description," IEEE Std 1471-2000. [30] The ATESST2 Consortium, \Methodology Guidelines When Using [4] Object Management Group. (2010, May) Unified Modeling Language. EASTADL2," Project Deliverable 5.1.1, [Online]. http://www.uml.org/ http://www.atesst.org/home/liblocal/docs/ATESST2_Deliverable_D5.1.1_V1.1 .pdf, June 2010. [5] SySML. Systems Modeling Language. [Online]. http://www.sysml.org/ [31] P. C. Clements, "A Survey of Architecture Description Languages," in [6] Object Management Group, "UML Profile for MARTE: Modeling and Eighth International Workshop on Software Specification and Design, 1996. Analysis of Real-Time Embedded Systems: Version 1.0," formal/2009-11-02, 2009. [32] W. Qin and S. Malik, "A Study of Architecture Description Languages from a Model-based Perspective," in Proceedings of the Sixth International [7] Articus Systems AB. (2010, Jul.) Articus Systems - The Choice for Workshop on Microprocessor Test and Verification, 2005, pp. 3-11. Dependable Real-Time Systems. [Online]. http://www.arcticus-systems.com/ [33] J. El-Khoury, D. Chen, and M. Törngren, "A Survey of Modelling [8] The SEI AADL Team, "An Extensible Open Source AADL Tool Approaches for Embedded Computer Control Systems," Mechatronics Lab, Environment (OSATE)," The Software Engineering Institute, Carnegie Mellon Department of Machine Design. Royal Institute of Technology., Stockholm, University, 2006. Technical Report TRITA - MMK 2003:36, ISSN 1400 -1179, ISRN [9] SAE, "SAE Architecture Analysis and Design Language (AADL)," SAE KTH/MMK/R-03/11-SE, 2003. International Standard AS5506, 2004. [34] Esterel Technologies, SCADE website, [Online], http://www.esterel- technologies.com/products/scade-suite/ , May 2011. [10] ATESST Consortium, "EAST-ADL2 Domain Model Specifications," Project Deliverable D4.1.1 [35] MAST website, [Online] http://mast.unican.es/, May 2011. http://www.atesst.fr/home/liblocal/docs/ATESST2_D4.1.1_EAST-ADL2- [36] K. Hänningen, J. Maäki Turja, M. Nolin, M. Lindberg, J. Lundbäck and Specification_2010-05-03.pdf, 2010 KL, Lundbäck, “Supporting Engineering Requirements in the Rubus [11] AUTOSAR. (2010) AUTomotive Open System ARchitecture. [Online]. Component Model”, MRTC report ISSN 1404-3041 ISRN MDH-MRTC- http://www.autosar.org. 223/2008-1-SE, Mälardalen Real-Time Research Centre, Mälardalen University, February, 2008. [12] Advancing Traffic Efficiency and Safety through Software Technology. (2009) [Online]. http://www.atesst.org. [37] The AUTOSAR Consortium, “Software Component Templatee," Tech. Rep. V3.3.0, R3.0, Rev 001. [13] TIMMO Consortium. (2010, May) TIMMO Websiite. [Online].