The SAE Analysis & Language (AADL) A Standard for Performance Critical Systems Bruce Lewis

To cite this version:

Bruce Lewis. The SAE Architecture Analysis & Design Language (AADL) A Standard for Engineering Performance Critical Systems. Conference ERTS’06, Jan 2006, Toulouse, France. ￿hal-02270351￿

HAL Id: hal-02270351 https://hal.archives-ouvertes.fr/hal-02270351 Submitted on 24 Aug 2019

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The SAE Architecture Analysis & Design Language (AADL) A Standard for Engineering Performance Critical Systems

Bruce Lewis US Army Aviation and Missile Research, Development & Engineering Command, Huntsville Al., USA 35898

Abstract: The Society of Automotive Engineers system engineering approach for these computer (SAE) Architecture Analysis & Design Language, systems, preferring instead to test and simulate, or AS5506, provides a means for the formal to over specify resources. But the end result has specification of the hardware and software been that system integration for complex embedded architecture of embedded computer systems and or performance critical computer systems is one of system of systems. It was designed to support a full the highest areas of program risk. It’s also a major Model Based Development lifecycle including cost driver on programs that do succeed and system specification, analysis, system tuning, integration issues have a major impact on the cost of integration, and upgrade over the lifecycle. It was upgrading. designed to support the integration of multiple forms of analyses and to be extensible in a standard way A model based approach, where the models we use for additional analysis approaches. A system can to analyse the system are the models that will drive be automatically integrated from AADL models when its execution and communication provides a much fully specified and when source code is provided for more predictable and powerful approach. In such an the software components. Analysis of large complex approach engineer rather than populate systems has been demonstrated in the avionics with rough estimates and testing. As Dr. Eric domain. Conquet of the European Agency and Director of ASSERT stated in a presentation [1], Keywords: Architecture, Computer Architecture, “Software crisis: origin is in fact a lack in system Model Based Development, Architecture Design engineering “ and “Use of formal techniques at the Language, Computer System Engineering, software without any formal approach at Computer Modelling, AADL, Architecture Analysis & system level is a nonsense”. Design Language. The Virtual Panel for this conference also 1. Introduction recognizes the importance of modelling in embedded As computer based systems have become more systems as stated by Jean-Claude Aloconque, “The complex and as we continue to exploit the benefits of most significant developments are definitely the code generation for components, the problem has increase of processor performance followed by the become the integration of components. It’s not drop in the chip’s cost, followed by the evolution in enough to have correct code for the software standalone systems toward distributed and components or subsystems, they must be properly interconnected systems and finally the use of integrated and correctly executed to have a fully modelling”. functional system that meets its performance critical requirements. The problem is multi-dimensional As an industry, to meet this need to precisely because the system performance qualities that must specify and model embedded performance critical be achieved are highly cross coupled. For example, systems, we must have a common standard the change to a software component or the language with strong semantics that can capture substitution of another hardware component can both the structure and dynamics of embedded affect system latency, safety, fault tolerance, bus systems. It must support the capture of properties of utilization, processor utilization, etc. And failure to these systems and the analysis approaches to meet the performance critical qualities required evaluate the critical qualities. It must be incremental results in failure of the system just as surely as a to support all lifecycle phases from early abstraction functional component’s failure to provide the right to final implementation. Since our analysis output or an algorithm’s failure to control adequately. approaches will differ and grow, we need a language Yet, we as an industry had not developed a sufficient that is also extensible in a controlled to

ERTS 2006 – 25-27 January 2006 – Toulouse Page 1/9 preserve the benefits of a standard, but also provide HOOD/STOOD were also leveraged to validate flexibility. concepts, provide an industrial strength solution and The AADL was developed for just such a purpose. It ease integration within the industry. Coordination was developed from significant experimentation and began with the Object Management Group over 3 research over 15 years. It provides a language that years ago to develop a standard AADL Unified is useful across domains where real-time, Modeling Language (UML) profile to provide the embedded, fault tolerant, secure, safety critical, benefits of AADL to the UML community. The software intensive systems are developed. Its standardization of this profile is being done in natural fields of application include avionics, partnership with the UML community. automotive, autonomous systems, industrial, medical, etc. From Research to Standard 2. Standard Development Research ADLs DARPA Funded •MetaH Research since 1990 – Real-time, modal, system 2.1 History family B as – Analysis & generation is Extensible – RMA based scheduling The AADL language has been formed from three Extension Real-time major areas. The proof of concept and base for its • Rapide, Wright, .. Dependable – Behavioral validation nce development was the MetaH language. Metah was Influe • ADL Interchange developed by Honeywell Labs, with Dr. Steve Vestal –ACME UML Profile ent gnm as principle investigator, over 12 years and three Industrial Strength Ali nt eme DARPA programs [2]. It was used in over 40 • UML 2.0, UML-RT anc Enh experimental projects, many of them DARPA •HOOD/STOOD •SDL programs, internal Honeywell investigations, Army TNI, Airbus & ESA experiments and/or SEI experiments. From these www.aadl.info 5 experiments in multiple domains of application, but primarily avionics and flight control, over 30 Figure 1 : Building from a foundation improvements were defined for the next generation language. 2.2 Committee Several of these projects were performed in our lab, The third major area of input was the SAE committee one being the development of a reference (see figure 2) which developed the requirements architecture for missile systems and re-engineering a document, the core standard AS5506, and the missile system to that architecture, building it and the annexes to the standard. Many language features 6DOF real-time simulation it flew in, software-in-the- were formed from the expressed needs of industy loop, with MetaH and the MetaH toolset, including representatives from many of the major aviation and specification, analysis and automated system real time systems companies in the US and Europe. integration [3,4]. Significant cost savings were Many of the participants are leading engineers in obtained and system and component changes were their companies developing the next generation rapid and efficient including hardware upgrades, approaches for computer system development. system partitioning, component partitioning and These engineers recognized early the need for a upgrades, rate changes etc. Several involved rapid common standard ADL to support computer system development of components via Matlab/Simulink engineering in performance critical systems. with Beacon code generation and rapid integration, Boeing, Raytheon, and Smith Industries are currently to a MetaH specified system architecture, onto the not voting members but were major contributers embedded hardware using the MetaH toolset. during the development of the standard. Note the These experiments and the proprietary nature of number of European participants in the standard. MetaH convinced the author that an open Automotive participants are new to the committee Architecture Description Language standard but because of their interest and others in the supporting model based development of embedded industry who do not attend, the AADL will become a systems was needed and was worth pursuing. joint standard of the SAE’s Aviation and Automotive The second major area of input to the language was divisions. the other ADL languages developed by DARPA and Coordination with research programs and other within industry. See figure 1. Experience with these standardization bodies are welcome, as well as new languages and MetaH, especially at the SEI by Dr. member companies. The SAE standard is being Peter Feiler, were also leveraged in the design of the coordinated with North Atlantic Treaty Organization AADL which broadened the domain of application (NATO). NATO is also applying the AADL along and helped form the core AADL from which with the US Air Force and another SAE committee, extensions would be later developed. Expertise on AS1, to develop approaches for rapid weapon the standardization committee with UML and

ERTS 2006 – 25-27 January 2006 – Toulouse Page 2/9 system integration [5,6,7]. The AADL will be part of • Programming Language Annex (April 2005) the OMG UML MARTE profile and the AADL – Mapping to Ada, C/C++ committee has members on the MARTE committee. Research projects in Europe have sigificantly • Error Modeling Annex (Oct 2005) contributed to the standard, and are expected to Reliability and fault modeling continue to do so. COTRE [8,9] and TOPCASED – [10] are two Airbus led programs that have worked • UML Profile for AADL (Mar 2006) closely with the committee. The ASSERT [1] program, European Union funded and European – Transition path for UML practitioner Space Agency led, is also working closely with the community committee. These programs are applying the • Behavior Annex (July 2006) language, extending the language through annexes and developing tools. – Detailed component behavior modeling

Annexes provide a way of extending the language incrementally so that tools can support or use those Industry Drives AADL Standard aspects important for their domain of application. The core textual language, meta-model and XML • Bruce Lewis (US Army AMRDEC): Chair • Peter Feiler (SEI): technical lead, std author & editor schema and AADL graphics are being supported • Steve Vestal (Honeywell): std co-author, Error Annex now in AADL tools. Graphical tools are just • Ed Colbert (USC): AADL UML Profile Annex becoming available. Specific tools will be discussed • Joyce Tokar (Pyrrhus Software): Ada & C Annex • Mamoun Filali, P. Dissaux, P. Gaufillet (Airbus): Behavior Annex later in the paper. Version 2 of the standard will Other Voting Members / Contributors include new core capabilities. • Boeing, Raytheon, Smith Industries -- Rockwell, Honeywell, Lockheed Martin, General Dynamics, Airbus, Axlog, European Space Agency, TNI Europe, Dassault, EADS, High Integrity 2.4 AADL Language Systems, Ford, Toyota, Eaton, UPenn, Draper Labs, ENST Coordination with The AADL provides components with precise • Open Systems Joint Task Force (OSJTF), NATO Aviation semantics to describe computer system architecture. Systems, French COTRE, EU ASSERT, SAE & NATO & AF Weapons Plug and Play, OMG UML, MARTE Components have a type and one or more implementations. Software components include 6 www.aadl.info data, subprogram, thread, thread group and process. The hardware components include processor, memory, bus and device. The system component is Figure 2 : AADL Committee used to describe hierarchical grouping of components, encapsulating software components, hardware components and lower level system components within their implementations. 2.3 Current State Interfaces to components and component interactions are completely defined. The AADL The core AADL standard [11], version 1.0 was supports data and event flow, synchronous published in Nov. of 2004. We expect to put out a call/return and shared access. In addition it supports new version with errata changes and the balloted end-to-end flow specifications that can be used to annexes in the spring of 2005. This will be the trace data or control flow through components. version that will be a joint standard between the SAE The AADL supports real-time task scheduling using Aviation and Automotive Divisions. Below are listed different scheduling protocols. Properties to support the current approved annexes [12] and two of the General Rate Monotonic Analysis and Earliest annexes under current development with projected Deadline First are provided in the core standard. formal ballot dates. The core also provides a property extension • Core AADL language standard (Nov 2004) language to define properties needed for additional forms of analysis. Execution semantics are defined – Textual language, semantics for each category of component and specified in the • Graphical AADL Notation Annex (April 2005) standard with a hybrid automata notation. – Enables graphical AADL Modal and configurable systems are supported by programming the AADL. Modes specify runtime transitions between statically known states and configurations • AADL Meta-model/XML Annex (April 2005) of components, their connections and properties. – Model interchange & tool Modes can be used for fault tolerant system interoperability

ERTS 2006 – 25-27 January 2006 – Toulouse Page 3/9 reconfigurations affecting both hardware and Multiple architecture analysis methods, such as software as well as software operational modes. schedulability, latency, safety, are selected and run on the system model as it is incrementally The AADL supports component evolution through developed. Models can be high level, low fidelity inheritance, allowing more specific components to be abstractions for some analyses, or early in refined from more abstract component. Large scale development. The specification is refined during development is supported with packages which development or as risks are discovered. Large provide a name space and a library mechanism for models may be generated from system databases. components, as well as public and private sections. Packages support independent development and Analysis methods provide the cross checking integration across contractors. needed to understand the effects of system change on scheduability, latency, safety, utilization, fault AADL language extensibility is supported through a tolerance etc. The analyses themselves can be property sublanguage for specifying or modifying incrementally added as new analysis tools become AADL properties. The AADL also supports available by adding the appropriate properties extensibility through an annex extension mechanism throughout the system lifecycle. System of systems that can be used to specify sub-languages that will integrators can collect AADL specifications of lower be processed within an AADL specification. An level systems and analyze the higher level integrated example is the Error Modeling Annex which allows system. Analysis methods and analysis tools will specification of error models to be associated with have to be selected consistant with the system core components. architecture approach used. System developers will A number of other papers are referenced for a more develop some special analysis for their own system detailed description of the language [13,14,38]. implementation style and as a system engineering competitive advantage.

Software component source code is supplied by the user and can be generated from component generators (such as from Matlab/Simulink or 3. Model Based Development and Process Beacon), hand coded, or reused/re-engineered. Integration Given the AADL specification, source code for the application and the execution environment 3.1 Model Based Process (processors, buses. memory, devices plus operating The Model Based Development process we have system, compilers etc), tools can automate the used in our laboratory in the past with MetaH process of system configuration, composition and includes the concepts of architectural specification, runtime system generation. These system architectural analysis, and automated integration integration/generation tools need to be consistent with generation of communication, glue code and the with the analysis methods and AADL semantics– system executive to construct the final system. The generated according to the AADL specification. AADL supports all the MBD concepts of MetaH and However, with generation, prototypes can be rapidly adds significant additional capability and flexibility in developed to experiment with the system effects due a public standard. See figure 3 for the discussion to architecture changes or component changes that below. affect system performance. Architecture analysis is rerun each time the specfication is updated, to provide model checking of the architecture as the architecture itself is refined Model-Based System Engineering (early trade-off analysis of architectural styles and System Analysis System Integration hardware/communication effects or changes during • Schedulability •Runtime System Generation Software the development or lifecycle) and as software • Performance • Application Composition • Reliability System • System Configuration components are developed and refined. Properties • Fault Tolerance Engineer • Dynamic Configurability reflect the attributes of hardware and software Predictive Architecture System components, connections, and ports and along with Modeling Engineering language semantics are used in analyses. Abstract, but Reduced AutomaticPrecise Development & Properties can capture estimates, requirements, or Target Operational Cost component options. Estimates may proceed to final Recognition Application Execution Guidance Software Platform values based on measurement as development & Control Supply Chain MechanizedComposable GPS DB HTTPS Ada Runtime proceeds. The integration of property values Components ...... Sensor Information Fusion (estimates to measured) can be compared to higher Ambulatory & Signal Devices Memory Bus Processor Processing level requirements. 9 www.aadl.info

ERTS 2006 – 25-27 January 2006 – Toulouse Page 4/9 Figure 3 : Model Based System Engineering metamodel standardized for the AADL. It provides the standardized XML definitions for use by Eclipse 3.2 Process Integration with UML, Simulink AADL plug-in analyses or interfacing with external The AADL UML profile will provide a means to toolsets. Its available at http://www.aadl.info. integrate UML and AADL application development The Eclipse tool framework and the AADL tools processes. The AADL profile will provide precise, developed within it provide significant power for the component based semantics for capturing the development or integration of analysis tools. computer hardware and software runtime Analysis plug-ins are much easier to write and architecture and to support its formal analysis. The customize than stand-alone toolsets, they focus on figure below from Rockwell [39] provides an example the extraction of data and its analysis with methods of the mapping between UML and the AADL and provided within OSATE for traversing the XML illustrates their desire to use the AADL UML Profile. models. Existing toolsets can be integrated into The resulting model can then be analyzed by any Eclipse or interfaces to tools developed in Eclipse. AADL-based tool through the XML interchange Stand-alone tools can also be generated from format, or by tools that interface directly to the AADL Eclipse plug-ins. See figure 4 below. profile in UML. UML tools could also support textual There were multiple reasons for an open source AADL output as a means of bridging to other tools. toolset strategy. One was to accelerate availability The TNI Europe toolset, STOOD [15], already of commercial tools by providing an open source tool provides a number of capabilities for integrated use that fully incorporates the language and provides of UML and AADL. semantic as well as syntactic checking. OSATE also Stong interest has also been expressed for has the benefit of making the full language available integration with Simulink from a number of AADL from the begining, and validating the language users. AADL components and semantics could be standard itself through implementing the language. used as a bridge to Simulink or another component It also furnishes a low entry cost vehicle for getting generator technology to guide component started with the language and provides a vehicle for generation to the architectural specification. The in-house prototyping for the development of analysis AADL Programming Language annex [16] provides approaches or annex extensions. It has accelerated guidance for building/integrating AADL compliant use by early adopters of the language, prior to systems in C and Ada. Several emerging AADL commercial tools. It decreases the likelihood of tools that have already demonstrated code incompatible toolsets implementing their own flavor integration/generation capability are listed under the of the standard. tools section. Since the AADL provides several standard extension mechanisms, industry domains, companies, and Exploit UML by building an AADL Profile vendors can provide extensions through these forms without corrupting the standard. These extensions process Application cd Use Case Model features «AADL_Process» then can be submitted to the AADL standardization Out : out data port Sensor_Data; Application IN : in data port Position_Data; - Thread1: AADL Component Implementation = Work end Application ; - Thread2: AADL Component Implementation = IO committee for consideration as part of the standard.

process implementation Application «AADL_Thread» subcomponents IO An example of this is the Airbus developed Behavior t1 : thread Work.simple; IN OutputData t2 : thread IO.simple; Raw_PV Filtered_PV connections IN Out Annex [18] which is now being reviewed by the data port t2.OutputData -> Out; data port IN -> t2.IN; SAE Standard UML Profile committee. (but this is not necessarily a compliant example) data port t2.Raw_PV -> t1.AADL_PV_data; AADL_PV_Data AADL_Vel AADL_Pos data port t1.AADL_Vel -> t2.Filter_PV; data port t1.AADL_Pos -> t2.Filter_PV; end Application; Commercial tools are highly valued by industry for «AADL_Thread» AADL Work - Period: float = 1 their development process support and on call - Dead_Line: float = 0 thread Work features PV_in : in data port AADL_PV_Data; maintenance. The UML profile as well is being V_out : out data port AADL_Speed; P_out : out data port AADL_Pos; developed to make it easy for UML tool vendors to «interface» properties This represents only the «interface» «interface» functional architecture, AADL_PV_Data AADL_Vel AADL_Pos Period => 1 Ms; mapping/binding to physical Dispatch_Protocol => Periodic; architecture model comes later... support the AADL. Compute_Execution_Time => .2 Ms .. .4 Ms; end Work ;

© Copyright 2005 Rockwell Collins Inc. All Rights Reserved AADL Opportunities at Rockwell Collins 25 Commercial analysis tools may be integrated into commercial or open source AADL tools and AADL analysis tools themselves present an opportunity for commercialization. Current commercial design tools 4. Tool Strategy and Progress can also be modifed and extended to support the AADL. For instance, TNI Europe is extending their 4.1 Open Source to Commercial STOOD Hood/UML development environment to import, capture via AADL graphics, process and The SEI, via Dr. Peter Feiler, the principle author of export AADL. the AADL standard, developed the Open Source AADL Tool Environment (OSATE) [17]. It was The AADL meta-model annex [19] includes the developed in the Eclipse framework using the AADL Declarative Model and the AADL Instance

ERTS 2006 – 25-27 January 2006 – Toulouse Page 5/9 model (see figure 4). The XML expression of the – ENST AADL toolset with graphics, declarative model can be converted back into a middleware generation and textual specification or graphical specification of a integration to AADL specification of system. The Instance model is used to simplify application on network distributed analysis by providing the system instance as it will processors. Creates formal model be bound to the processors. The meta-model of executive in AADL and Petri nets. provides a specification of the language that can be • MONTANA [22] used in meta-modeling frameworks to rapidly build AADL compliant toolsets, such as in TOPCASED or – AADL to ACRS [23] (process GME [20]. algebra), formal analysis of concurrent resource utilization, Another important aspect of the standardized meta- scheduling model and XML schema is that it provides a database for analysis tool interaction that is – AADL to Charon [24], generation of standard. Tools can not only read from the XML control components and integration models but also post back into it. For instance, a of hybrid control systems to AADL scheduling and binding toolset would be used to specification using Charon annex. optimize processor and bus utilization given the GME [20] constraints on binding captured in the AADL and the • properties of threads and communication overheads. – Vanderbilt Univ, DARPA sponsored Given that binding, follow-on reliability, latency or meta-modeling framework, AADL safety analysis could be performed. Finally, from architecture specification and the system instance, the system could be system security analysis being automatically integrated with generation of glue added. code. • CHEDDAR [25]

– ENST, advanced scheduling analysis toolset XML-Based Tool Integration Strategy

AADL Front-end 5. Error Modelling Annex Concepts Textual Semantic Graphical AADL AADL Checking In fault tolerant, safety critical systems error modeling is an important aspect of architectural Declarative AADL Model Graphical Layout design and should be integrated into the architecture AADL Instance Model Model specification so it can be cross checked against Scheduling AADL Runtime changes. The MetaH language originally supported Analysis Generator reliability modeling and this has been sigificantly Reliability Safety Analysis Commercial Tool Analysis extended in the AADL to support multiple forms of Project-Specific safety and dependability analysis through error Research prototype In-House www.aadl.info 13 models that are attached to architectural components [26]. Some of the supported analysis Figure 4 : Standardized and Simplified Tool approaches include hazard analysis, failure modes Integration Supported and effects analysis (FMEA), fault trees, and Markov processes. Honeywell has demonstrated error 4.3 Additional Open Source Tools modeling (hazard and FMEA) using annex capabilities on a large aircraft system [27]. ASSERT There are a number of AADL open source toolsets has modelled a dual redundant fault tolerant either just becoming available or in the process of computer system using the annex [28,29]. development. Here’s a list. • TOPCASED [10] – Airbus led, 22 partners participating, developing a meta- modeling framework, includes AADL toolset and Graphics, AADL XML, model transformation • OCARINA [21]

ERTS 2006 – 25-27 January 2006 – Toulouse Page 6/9 AADL Integrated Safety, FMEA, Reliability AADL In Use System Capture hazards

Subsystem Capture risk mitigation architecture

Component Capture FMEA model

Error Model features permit checking for consistency and completeness between these various declarations.

17 18 www.aadl.info www.aadl.info

Figure 5: Component and System Error Modeling Figure 6: Demonstrations of AADL Capability

6. AADL in Use Evaluations Some of the early adopter presentations on the Evaluations of various methods and tools have been carried out over AADL are highlighted in the slide in Figure 6. These the past few years using one or more of the following workloads. presentations and many others are available on the Air transport aircraft IMA (simplified production workload) AADL website www.aadl.info. They include Globally time-triggered 6 processors, 1 multi-drop bus experimentation using the AADL to capture a 105 threads, 51 message sources reference architecture for military aircraft (EADS Military helicopter MMS (first release, partial) Globally time-triggered [30]), the development of a system engineering 14 dual processors, 14 bus bridges, 2 multi-drop buses 306 threads, 979 [source, destination] connections process using the AADL for validation of correctness Air transport aircraft IMA (preliminary, partial) and integration of the dynamic and structural aspects Globally asynchronous processors, precedence-constrained switched network 26 processors, 12 switches of the aircraft computer system (Airbus [8]), a 1402 threads, 2644 [source, destination] connections Regional aircraft IMA (production workload) presentation on an integrated UML and AADL Globally time-triggered 49 processors, 2 multi-drop busses process for the development of weapon system Plug 244 processes (TBD threads), 3179 [source, destination] connections & Play (PnP) (General Dynamics [7]). Also included is a presentation on the modelling of a 19 AADL Workshop Oct 2005 large modern aircraft system with architectural trade- Figure 7: Honeywell MetaH/AADL Aircraft Modelling off analysis, scheduling and safety analysis (Honeywell [27]) and a modelling and analysis of a modern helicopter architecture for system workload, 7. AADL Transition Support partitioning and tuning of the switched network (Rockwell [31]). Also pictured is a presentation on The Software Engineering Institute is providing the development of a system engineering approach transition support for the AADL in the US and using the AADL and a formal methods oriented Europe as part of their newly formed Predictable development process (ESA, ASSERT [1]). These System Engineering Research group. They are the presentations demonstrate a variety of uses, developers of the OSATE toolset and a training integration into system engineering processes and course and Guide document on the development of application to significant modern, complex, large, OSATE analysis plug-in development. They have performance critical systems for the AADL. developed a public two day AADL course on Model Based System Engineering with the SAE AADL and Figure 7 provides a list of Aircraft that Honeywell has have published AADL research reports modelled using MetaH/AADL [40]. This presentation [32,33,34,35]. They have also developed (and are also provides Honeywell’s tool development strategy near publication) a Practitioner’s Guide [36] on AADL for AADL tools. and Control Systems Applications and a User’s Guide [37] to AADL notation.

ERTS 2006 – 25-27 January 2006 – Toulouse Page 7/9 Software Engineering and Knowledge Engineering, Vol6, No. 2, 1996, pages 201-227.

8. Conclusion 3. David J. McConnell, Bruce Lewis and Lisa Gray, “Reengineering a Single Threaded Embedded The AADL provides or supports through tools Missile application onto a Parallel Processing significant model based embedded system Platform using MetaH,” 5t Workshop on Parallel engineering benefits. These include: and Distributed Real Time Systems, 1996. 4. Jonathan W. Kruger, Steve Vestal, Bruce Lewis, - Precise semantics supporting analyzable models “Fitting The Pieces Together: System/Software to predict system performance and drive Analysis and Code Integration Using MetaH,” development Digital Avionics Systems Conference, 1998. - Prediction of system runtime characteristics at different fidelity 5. Douglas Gregory, « Aircraft, Launcher & - Bridge between application engineer, architect and Weapon Ineroperability – Review of Technical software engineer Findings », AADL Standardization Meeting, - Prediction early and throughout lifecycle Edinburgh, July 2004 - Reduced integration and maintenance effort 6. Andre Windisch, Herbert Schlatt, « AADL- Modelling of Plug&Play Weapon System The AADL also provides additional benefit based on Architecture », AADL Workshop, Paris, Oct 2004 its standardized features including: 7. Yves LaCerte, « AADL and MDA – Early - Common modelling notation across organizations Experience Applied to Aircraft-Weapon - Single architecture model augmented with Integration », AADL Standardization Meeting, properties Seal Beach, Jan 2005 - Interchange & integration of architecture models - Tool interoperability & integrated engineering 8. Patrick Farail, Pierre Dissaux, “COTRE a Workshop”, DASIA 2002, May environments 2002.

The AADL is based on over 12 years of research, 9. Pierre Gaufillet, « COTRE as an AADL profile », over 40 experiments, other DARPA ADL’s and an AADL Standardization Meeting, Edinburgh, July expert committee. The AADL has been 2004 demonstrated on large complex embedded safety 10. Pierre Gaufillet, « TOPCASED – Toolkit In Open critical systems by leaders in the Avionics domain. A source for Critical Applications & SystEms growing number of tools as well as transition support Development », AADL Workshop, Paris, Oct for AADL are becoming available, including now 2005, http://www.topcased.org/ AADL graphics. It is time to investigate the benefits 11. Society of Automotive Engineers (SAE) Avionics of using the AADL on your systems in the aviation, Systems Division (ASD) AS-2C Subcommittee. space, and automotive domains. “Avionics Architecture Description Language Standard.”, AS 5506, November 2004

9. Acknowledgement 12. Society of Automotive Engineers (SAE) Avionics Systems Division (ASD) AS-2C Subcommittee. The author would like to thank the AADL “SAE Architecture Analysis & Design Language standardization committee for their diligent efforts (AADL) Annex Volume 1 : Graphical AADL and willingness to share through their presentations Notation, AADL Meta-Model and Interchange what they are doing with the AADL. Many of the Formats, Language Compliance and Application papers referenced below have been developed by Program Interface”, proposed draft for committee members. publication, AS 5506 /1, Oct 2005. 13. Peter Feiler, Bruce Lewis, « The SAE AADL 10. References Standard : An Architecture Analysis & Design Language for Developing Embedded Real-Time

Systems », World Computer Congress, ADL 1. Eric Conquet, « ASSERT – Automated proof- Workshop, Toulouse, August 2004 based System and Software Engineering for 14. Joyce Tokar, Lutz Wrage, « The SAE Real-Time systems », AADL Standardization Architecture Analysis and Design Language Meeting, Edinburgh, July 2004 (AADL) Standard : A Basis for Architecture- 2. Pam Binns, Matt Englehart, Mike Jackson and Driven Embedded Systems Engineering, Steve Vestal, “Domain Specific Software International Workshop on Solutions for Architectures for Guidance, Navigation and Automotive Software Architecture, Boston, Oct Control,” Honeywell Technology Center, 2004 Minneapolis, MN, International Journal of

ERTS 2006 – 25-27 January 2006 – Toulouse Page 8/9 15. Pierre Dissaux, « Stood and the AADL », AADL 32. Peter Feiler, David Statezni, « Muti-Fidelity Workshop, Paris, Oct. 2005, http://www.tni- Architecture Modeling », SEI internal report, Oct world.com 2004 16. Joyce Tokar, « SAE Architecture Analysis & 33. Peter Feiler, « Pattern-Based Analysis of an Description Language – Programming Language Embedded Real-Time System Architecture », Guidelines », AADL Workshop, Oct 2005 World Computer Congress, ADL Workshop, Toulouse, August 2004 17. Peter Feiler, « Open Source AADL Tool Environment (OSATE) », AADL Workshop, Paris, 34. Peter Feiler, David Gluch, John Hudak, Bruce Oct 2004 Lewis, “Embedded Systems Architecture Analysis Using SAE AADL”, Technical Note, CMU/SEI- 18. Mamoun Filali, « Cotre Annex HRT-HOOD 2004-TN-005, Software Engineering Institute, embedding », AADL Workshop, Paris, Oct 2005 June 2004 19. Peter Feiler, « AADL Meta Model & XML/XMI », 35. Peter H. Feiler, Bruce Lewis, Steve Vestal, AADL Workshop, Paris, Oct 2004 “Improving Predictability in Embedded Real-time 20. Matt Eby, Janos Mathe, Jan Werner, Chip Clifton, Systems,” Carnegie Mellon Software Engineering « Experimental Platform for Systems-Security Institute, CMU/SEI-2000-SR-011, October 2000. Codesign, AADL Seminar, Dec 2005 36. J. Hudak, « Developing AADL Models 21. Thomas Vergnaud, « The Ocarina Tool Suite », for Control Systems: AADL Workshop, Paris, Oct 2005, A Practitioner’s Guide”, Technical Report http://ocarina.enst.fr CMU/SEI-2005-TR-022 22. Oleg Sokolsky, « The Montana Toolset : OSATE December, 2005 Plugins for Analysis and Code Generation », 37. D. Gluch, “User’s Guide on the AADL AADL Workshop, Paris, Oct 2004 Notation”, Technical Report, March 2006 23. Duncan Clarke, Insup Lee, Hong-liang Xie, « VERSA : A Tool for the Specification and 38. Society of Automotive Engineers (SAE) Avionics Analysis of Resource-Bound Real-Time Systems Division (ASD) AS-2C Subcommittee Systems », University of Pennsylvania, May 1994 "The SAE AADL Standard: A Language Summary": A Summary of the SAE AADL 24. Rajeev Alur, Franjo Ivancic, Jesung Kim, Insup Language - extracted from the standard Lee, Oleg Sokolsky, «Generating Embedded document Software from Hierarchical Hybrid Models », www.aadl.info/downloads/papers/AADLLanguage LCTES’03, San Diego, June 2003 Summary.pdf 25. F. Singhoff, J. Legrand, L. Nana, L. Marce, 39. John Mettenburg, David Lempia, « AADL « Scheduling and Memory requirement analysis Opportunities at Rockwell Collins », AADL with AADL », Proceedings of the ACM SIGAda Seminar, Dec. 2005 International Conference, Nov, 2005. http://beru.univ-brest.fr/~singhoff/cheddar/ 40. Steve Vestal, « Methods and Tools for Embedded Distributed System Scheduling and 26. Steve Vestal, « An Overview of the Architecture Schedulability Analysis », AADL Workshop, Analysis & Design Language (AADL) Error Model Paris, Oct. 2005 Annex », AADL Workshop, Paris, Oct 2005 27. Steve Vestal, « Automating Timing and Safety 11. Glossary Analyses from Architecture Specifications », AADL Standardization Meeting, April 2005 AADL: Architecture Analysis & Design Language ADL: Architecture Design Language 28. Ana Rugina, Karama Kanoun, Mohamed Kaaniche, Jeremie Guiochet, « Dependability ASSERT: Automated proof-based System and Software modelling of a fault tolerant duplex system using Engineering for Real-Time systems AADL and GSPNs », LAAS Research Report no. ENST: Ecole Nationale Superieure Telecommunications 05315, Draft of ASSERT Report, Sept 2005 TOPCASED: Toolkit In Open source for Critical Applications & SystEms Development 29. Ana Rugina, « Dependability Modelling using AADL and the AADL Error Model Annex », AADL Workshop, Paris, Oct 2005 30. Andre Windisch, « ASAAC Modelling with AADL », AADL Standardization Meeting, Edinburgh, July 2004 31. David Statezni, « Analyzable and Reconfigurable AADL Specifications for IMA System Integration », SAE World Avation Conference, Reno, Oct 2004

ERTS 2006 – 25-27 January 2006 – Toulouse Page 9/9