B Lewis

Feiler Multi-Dimensional

P Feiler

Multi-Dimensional Model Based Engineering for Performance Critical Computer Systems Using the AADL

Keywords: Architecture, Computer Architecture, Model Based Development, Architecture Design Language, Computer System Engineering, Computer Modelling, AADL, Architecture Analysis & Architecture, Computer Architecture, Model Based Development, Architecture Design Language, Computer System Engineering, Computer Modelling, AADL, Architecture Analysis & Design Language

published or not. The documents may come   L'archive ouverte pluridisciplinaire

Introduction

A key to engineering an embedded system is to analyze the operational characteristics of its realization as a software-intensive system through a model of its software runtime architecture, its compute platform, its interface to the physical environment, and the deployment of the software on the hardware platform. In order to achieve these operational characteristics, the architecture must provide valid data, at the right time, within resource limitations, with proper security, and provide required levels of fault tolerance and dependability. Model-based engineering involves the creation of models of the system at a level of abstraction that is relevant to the analysis to be achieved. Traditionally, this has led to the creation of different models of the same system by different stakeholders. Dependability engineering resulted in the creation of fault trees for fault analysis and markov models for reliability analysis. Resource utilization analysis is based on resource demands and resource capacities. Scheduling analysis is based on a timing model of the application tasks. Security analysis involves the creation of a model in terms of security levels and domains applied to subjects and objects. In other words, a number of independently created models reflect the same system architecture and any change to this architecture during its life time requires each of these models to be updated and validated that it correctly reflects the actual system architecture. Similarly, it is difficult to consistently reflect any changes in one analysis dimension in other dimensions, e.g., consistently reflect the impact of choosing a different security encryption scheme on intrusion resistance as well as on schedulability and end-to-end latency. So it becomes important to integrate the different analysis dimensions into a single architecture model. An architecture model that is annotated with analysis-specific information can drive model-based engineering by generating the analysis-specific models from this annotated model. This allows changes to the architecture to be reflected in the various analysis models with little effort by regenerating them from the architecture model This approach also allows us to evaluate the impact across multiple analysis dimensions. The AADL was developed for just such a purpose. It was developed from significant experimentation and research over 15 years. It provides a language that is useful across domains where real-time, embedded, fault tolerant, secure, safety critical, software-intensive systems are developed. Its natural fields of application include avionics, automotive, autonomous systems, process control, and medical. Because of the strong need in today's complex systems, it has stimulated large industrial initatives to leverage the power of architectural multi-dimensional analysis and automated system integration from the specifications and models.

Standard Development

History

The AADL language has been formed from three major areas. Its proof of concept and base for development was the MetaH language. MetaH was developed by Honeywell Labs, with Dr. Steve Vestal as principle investigator, over 12 years and three DARPA programs [1]. It was used in over 40 experimental projects, many of them DARPA programs, internal Honeywell investigations, Army experiments [2] and/or SEI experiments. The second major area of input to the language was the other ADL languages developed by DARPA and within industry. Experience with these languages and MetaH, especially at the SEI by Dr. Peter Feiler, were also leveraged in the design of the AADL which broadened the domain of application and helped form the core AADL from which extensions would be later developed. Expertise on the standardization committee with UML and HOOD/STOOD were also leveraged to validate concepts, provide an industrial strength solution and ease integration within the industry. The third major area of input was through the members of the SAE committee (see figure 1) which developed the requirements document, the core standard AS5506, and the annexes to the standard. Many language features were formed from the expressed needs of industry representatives from many of the major aviation and real time systems companies in the US and Europe.

Many of the participants are leading engineers in their companies developing the next generation approaches for computer system development. These engineers recognized early the need for a common standard ADL to support computer system engineering in performance critical systems. A fourth area now impacting the AADL is industrial pilots and university research programs that have adopted the AADL as a means to express performance critical architecture, analyze and then automate the integration of performance critical systems. These research programs along with industry experiences with AADL version 1.0 are providing and will provide guidance for AADL version 2.0, which will be balloted in summer, 2008. Research projects in Europe have significantly contributed to the standard, and are expected to continue to do so. COTRE [3,4] and TOPCASED [5] are two Airbus led programs that have worked closely with the committee.

The ASSERT [6] program, European Union funded and European Space Agency led, is also working closely with the committee. Several new research programs in the US and in Europe will be discussed later which will impact the standard into the future. The OMG MARTE committee has developed and is prototyping guidelines for expressing AADL as a subset of the MARTE profile. As this subset is formalized into a full profile through a joint AADL/MARTE effort, it is expected to become the standard AADL profile for UML. An annex is being developed to better support analysis in Net-Centric systems. Based on the experience with SAE AADL in industrial projects improvements have been suggested. Version 2 of the AADL standard includes better support for architecture patterns, for modelling protocols, virtual channels, processor partitioning, and layered architectures. First ballot of AADL V2 is expected in Spring 2008.

AADL Language

The AADL provides components with well defined and precise semantics to describe computer system architecture. Precise semantics, hybrid automata, are used to express system state and timing. Version 2 will add additional temporal logic expressions for ports and threads. Using the well defined and precise semantics allows quantitative analysis, system integration and glue code generation to build predictable systems.

The language is designed to be incrementally refined as more information is available and provides permissions relative to the semantics. Components have a type and one or more implementations.

Software components include data, subprogram, thread, thread group and process. The hardware components include processor, memory, bus and device. The system component is used to describe hierarchical grouping of components, encapsulating software components, hardware components and lower level system components within their implementations. Interfaces to components and component interactions are completely defined. The AADL supports data and event flow, synchronous call/return and shared access. In addition it supports end-to-end flow specifications that can be used to trace data or control flow through components. The AADL supports real-time task scheduling using different scheduling protocols. Properties to support General Rate Monotonic Analysis and Earliest Deadline First are provided in the core standard. The core also provides a property extension mechanism to define properties needed for additional forms of analysis. Execution semantics are defined for each category of component and specified in the standard with a hybrid automata notation. Modal and configurable systems are supported by the AADL.

Modes specify runtime transitions between statically known states and configurations of components, their connections and properties. Modes can be used for fault tolerant system reconfigurations affecting both hardware and software as well as software operational modes. The AADL supports component evolution through inheritance, allowing more specific components to be refined from more abstract component. Large scale development is supported with packages which provide a name space and a library mechanism for components, as well as public and private sections. Packages support independent development and integration across contractors. AADL language extensibility is supported both through a property sublanguage for specifying or modifying AADL properties.

The AADL also provides an annex extension mechanism that can be used to specify sub-languages that will be processed within an AADL specification. An example is the Error Modeling Annex which allows specification of error models to be associated with core components. The combination of annex extensions and user defined property sets provide the means to integrate new specification capabilities and new analysis approaches to support the analysis tools and methods desired for multiple dimensions of analysis. A number of other papers are referenced for a more detailed description of the language and are available on the AADL website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] under "Home/Presentations and publications repository".

Model Based Engineering and Process Integration

Model-Based Engineering Process

The Model Based Engineering (MBE) for computer systems, as we use the term, includes the concepts of architectural specification, architectural analysis, and automated integration with generation of communication, glue code and the system executive to construct the final system. The MBE analyses are computer processable from the specification and quantitative.

The AADL supports all the MBE concepts and adds significant additional capability and flexibility in a public standard. See figure 2 for the discussion below. Architecture analysis is rerun each time the specification is updated, to provide model checking of the architecture as the architecture itself is refined (early trade-off analysis of architectural styles and hardware/communication effects or changes during the development or lifecycle) and as software components are developed and refined. Properties reflect the attributes of hardware and software components, connections, and ports and along with language semantics are used in analyses. Properties can capture estimates, requirements, or component options. Estimates may proceed to final values based on measurement as development proceeds.

The integration of property values (estimates to measured) can be compared to higher level requirements. Multiple architecture analysis methods, such as schedulability, latency, safety, are selected and run on the system model as it is incrementally developed. Models can be high level, low fidelity abstractions for some analyses, or early in development. The specification is refined during development and used to explore solutions as risks are discovered. Large models may be generated from system databases. Analysis methods provide the cross checking needed to understand the effects of component or system change on schedulability, latency, safety, utilization, fault tolerance etc.

The analyses themselves can be incrementally added as new analysis tools become available by adding the appropriate properties throughout the system lifecycle. System of systems integrators can collect AADL specifications of lower level systems and analyze the higher level integrated system. Analysis methods and analysis tools will have to be selected consistent with the system architecture approach used. System developers will develop some special analysis for their own system 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 Beacon), hand coded, or reused/re-engineered. Given the AADL specification, source code for the application and the execution environment (processors, buses. memory, devices plus operating system, compilers etc), tools can automate the process of system configuration, composition and runtime system generation.

These system integration/generation tools need to be consistent with the analysis methods and AADL semanticsgenerated according to the AADL specification. However, with generation, prototypes can be rapidly developed to experiment with the system effects due to architecture changes. An additional concept, the model bus, provides for automated, systematic integration of information from various engineering sources, tools and notations into the architecture specification. Advanced industrial research at Airbus and Boeing, as well as others, include the model bus for transferring data to and from models and to and from development and analysis tools.

Research at Rockwell has found that tools are typically extendable to allow more specific semantics and that the AADL makes an excellent intermediate language to represent the semantics of architecture in the databases and across tools. Transformations do not need to cover the whole domain of a specific language or toolset but only those parts that are needed to populate the analysis models. Model buses work from meta-models of the notations and transformations occur at the meta-model level.

Analysis Methods

Once the architecture or a critical subset of the architecture has been captured in an AADL specification, the properties can be added for the analysis of interest. For analysis, architecture data is extracted from the specification (by plug-ins in Eclipse based OSATE environment [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] and are solved within the plug-in or exported to an external analysis toolset. The ability to perform analyses can be incrementally added to a specification by adding properties, adding any additionally needed aspects of the architecture, and if the analysis interface does not already exist, tooling to extract from the specification the needed information to export. To develop the ability to run multiple analyses on the same architecture, properties are added for each analysis. See figure 3 for an example from the aviation domain, a partition specified as an AADL process with properties to support multiple analyses, in this case partition latency, security, and processor and memory utilization.

This example also demonstrates the incremental capabilities built into the AADL, at this point the DisplayManager has only port groups defined in its interface, yet that is sufficient to evaluate data flow timing across partitions. This subsystem is part of a much larger example of incremental specification and multidimensional modelling in an avionics architecture made available [START_REF] Feiler | Evolution of an Avionics System[END_REF].

Figure 3 A Subsystem with Multiple Properties

The fact that the AADL can be used for multiple domains of analyses has been demonstrated as illustrated in Figure 4. At the center of the figure is the specification captured in the AADL. Multiple analysis methods from each of these domains have been demonstrated with AADL specifications using publicly available tools or internal tools. Analysis development has been a rapidly expanding area. A number of analyses not on this diagram have also been demonstrated, such as simulation of AADL architectures, Petri net analysis, concurrency analysis based on process algebra and fault containment analysis.

AADL Integration Pilot (OSATE) CDU Key Press Analysis

Analyze Latency…

Analyze Latency…

Figure 4 Example use of Latency Analysis

In the domains of data quality and security analysis, several analysis tools were added to OSATE during a recent research study at the SEI. This study was applying AADL and analysis techniques for the design of Sensor Networks but the analysis of security and data quality should be applicable to many applications.

Analysis in the resource consumption domain on a similar aviation system was demonstrated at Rockwell using internal analysis tools. The workload analysis results identified the possibility of reducing the number of processors, thereby decreasing system cost on each system. See Figure 5. Analysis of resource consumption using AADL is available through multiple toolsets. A partial list of tools is on the AADL website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] under "Tool Integrators" page then "toolsets" and under "Home" page then "Rapid Growth Seen In New AADL Toolsets". In fault tolerant, safety critical systems error modeling is an important aspect of architectural design and should be integrated into the architecture specification so it can be cross checked against changes. The MetaH language originally supported reliability modeling and this capability has been significantly extended in the AADL through the Error Modelling annex to support multiple forms of safety and dependability analysis through error models that are attached to architectural components [START_REF] Vestal | An Overview of the Architecture Analysis & Design Language (AADL) Error Model Annex[END_REF]. See Figure 6. Additional information on error modelling and plug-ins are also on the SEI website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] under "Home" then "OSATE error modelling plug-in and other materials" for a guide to building error models.

Each component can have an error model. The architecture specification provides the foundation for understanding propagation and the effect of failure. Component error models integrate into a system error model through the architecture specification. Architecture specification changes then affect the error modeling directly making it much easier to maintain and discover impacts. See Figure 7. Some of the supported analysis approaches include hazard analysis, failure modes and effects analysis (FMEA), fault trees, and Markov processes. Honeywell has demonstrated error modeling (hazard and FMEA) using annex capabilities on a large aircraft system [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]. ASSERT has modeled a dual redundant fault tolerant computer system using the annex [START_REF] Rugina | Dependability modelling of a fault tolerant duplex system using AADL and GSPNs[END_REF][START_REF] Rugina | Dependability Modelling using AADL and the AADL Error Model Annex[END_REF]. Error models are used to develop multiple types of system dependability models and these can be analyzed within a single specification allowing consistency checking between them. See figure 8.

Figure 8 Integrating Dependability Analysis

Honeywell has done analysis on multiple aircraft platforms with a variety of buses, system synchronization approaches, and sizes. These analyses included resource consumption on processors and buses, global scheduling across multiple scheduling paradigms, switched network tuning, and FMEA and Hazard analysis [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]. These experiments and others among AADL users have had a direct impact on the AADL standard, demonstrating and refining capabilities for industrial application. See figure 9.

19

AADL Workshop Oct 2005

Evaluations

Evaluations of various methods and tools have been carried out over the past few years using one or more of the following workloads.

Air transport aircraft IMA (simplified production workload)

Globally time-triggered 6 processors, 1 multi-drop bus 105 threads, 51 message sources

Military helicopter MMS (first release, partial)

Globally time-triggered 14 dual processors, 14 bus bridges, 2 multi-drop buses 306 threads, 979 [source, destination] connections

Air transport aircraft IMA (preliminary, partial)

Globally asynchronous processors, precedence-constrained switched network 26 processors, 12 switches 1402 threads, 2644 [source, destination] connections

Regional aircraft IMA (production workload)

Globally time-triggered 49 processors, 2 multi-drop busses 244 processes (TBD threads), 3179 [source, destination] connections

Figure 9 Aviation System Architectures Modeled

An aviation system AADL specification is available with instructions to demonstrate incremental, multifidelity analysis across multiple analysis dimensions. It has been posted on the SEI web site [START_REF] Feiler | Evolution of an Avionics System[END_REF]. It uses the Open Source AADL Toolset Environment (OSATE) editor and analysis plug-ins. There are a number of AADL tools, many with analysis capability listed on the web site [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF]. Specifications can be moved from tool to tool to leverage analysis capabilities. In many cases the tools are designed to work together but well defined semantics and a significant core capability have enabled specifications to be moved from toolset to toolset to leverage analysis as demonstrated on ASSERT.

An important aspect in integrating multiple analysis approaches is the standardized AADL meta-model and XML schema. It provides a standard database format for analysis tool interaction. Tools can not only read from the XML models but also post back into it. For instance, a scheduling and binding toolset would be used to optimize processor and bus utilization given the constraints on binding captured in the AADL and the properties of threads and communication overheads. Given that binding, a reliability, latency or safety analysis could follow. Finally, from the system instance, the system could be automatically integrated with generation of glue code. See figure 10.

Significant Industrial Initiatives and Research Drive Future Capability

The AADL standard's capability and extensibility has attracted a number of industrial initiatives and research projects on embedded systems analysis and verification. Some of them are listed in figure 25. Most of these projects are cooperating with the AADL standardization committee to identify new capabilties needed in the language as well as developing analysis and code generation tools, and engineering methods. Industrial initiatives are piloting the technology to work out changes in processes to accommodate MBE using AADL, including acquisition, development, and certification. The ASSERT and the TOPCASED initiatives have already made significant contributions to the AADL language and tools. See figure 11.

The Support for Predictable Integration of mission Critical Embedded Systems (SPICES) project [START_REF] Tilman | SPICES -Support for Predictable Integration of mission Critical Embedded Systems[END_REF], as described in their presentation to the AADL committee, is strongly oriented to AADL modelling and analysis for use in containers which would be integrated to form systems. "The principal goals of SPICES are to extend the capacities of the microCCM component-based framework and to couple it with an AADL modeller in order to offer to system architects, software architects, and application designers a component-based modelling, design and analysis environment for distributed realtime embedded systems that should be deployed over heterogeneous targets such as GPP, DSP or FPGA." See Figure 12. Another new industrial initiative with a strong AADL focus is sponsored under the Aerospace Vehicle Systems Institute (AVSI) System and Software Integration Verification (SSIV) work tasks [START_REF] Chilenski | Aerospace Vehicle Systems Institute Systems and Software Integration Verification Overview[END_REF] and lead by Boeing. The AVSI is a cooperative of aerospace companies, DoD, and FAA to improve the integration of complex subsystems in aircraft. This AVSI project includes not only US contractors and system integrators but also European as well.

Airbus and Dassault are joining with Boeing, Lockheed Martin and a number of US suppliers.

There is an opportunity for European suppliers to also participate.

The theme of the AVSI-SSIV is "Integrate -then Build". It's objectives are listed in figure 14, and includes integrated analysis of the system, software, and hardware for performance, safety, security, and functionality. The prediction of system behaviour by analysis to assure acceptability occurs before the system building process begins through virtual integration. Some requirements are determined through analysis. These analyses will at least maintain existing levels of safety and security but are expected to improve them, since analysis and formal modelling will find issues testing and simulation often miss. This approach moves the industry beyond process toward evidence for safety and security.

As can be seen in figure 15, this approach modifies the acquisition process.

The system integrator provides virtual models of "parts" to potential suppliers, who respond with their models of these subcomponents that fit the requirements they are bidding. Then these components are virtually reintegrated, with feedback, by the system integrator. This approach fits with investments made in Europe with the AADL and Model Based Engineering. AVSI-SSIV is designed as a multi-phased program. The first phase was a planning phase and is near completion. The next phase is a one year task to demonstrate viability of the approach, which includes demonstrating AADL, analysis and the model bus and develop a new model based acquisition process for industry. This next phase will start in the spring of 2008 and is estimated at about $4M. Additional work packages are being defined for follow on research and industrial process definition, which if funded, could reach $40M.

Modified Business Model Modified Business Model

 System Integrator defines a new product using internal repository of virtual "parts"  Specifications for virtual subcomponents sent to suppliers

Figure 15 AVSI-SSIV Virtual Integration Based Acquisition

Figure 16 illustrates the way the model bus will be used to integrate models, exchange information between tools and between the system integrator and the suppliers.

The model bus plays an important role by keeping the approach from depending on specific tools. It allows the integration of tool results into the models and the models with analysis tools. The AADL was selected after an extensive study of architecture description languages in industry and academia for its capability, existing tools, and extensibility mechanisms.

Version

Aerospace Vehicle Systems Institute

Slide 6 Both the AVSI-SSIV and the SPICES programs are interested in exploring incremental certification approaches and the impact that quantitative/formal modelling can have on certification and testing.

Overview of Multi Overview of Multi--Aspect Model Aspect Model Repository & Model Bus Repository & Model Bus

Conclusion

The AADL's standardized component well defined, semantics for runtime system architecture, integrating the computer hardware and software specifically supports capturing the architecture for multi-dimension analysis. As such, it becomes an excellent place to integrate computer system engineering requirements, platform development and software engineering concerns. New research projects are likely to add new analyses and more highly automated approaches for system integration as well as new industrial acquisition processes which leverage model based engineering across multiple critical system performance dimensions. The AADL provides or supports through tools significant model based embedded system engineering benefits. These include:  Precise and well defined semantics supporting analyzable models to predict system performance and drive development  Prediction of system runtime characteristics at different fidelity  Bridge between application engineer, architect and software engineer  Prediction early and throughout lifecycle  Reduced integration and maintenance effort

The AADL also provides additional benefit based on its standardized features including:

Acknowledgement

The author would like to thank the AADL standardization committee for their diligent efforts and willingness to share through their presentations what they are doing with the AADL. Many of the papers referenced below have been developed by committee members.

Introduction

A key to engineering an embedded system is to analyze the operational characteristics of its realization as a software-intensive system through a model of its software runtime architecture, its compute platform, its interface to the physical environment, and the deployment of the software on the hardware platform. In order to achieve these operational characteristics, the architecture must provide valid data, at the right time, within resource limitations, with proper security, and provide required levels of fault tolerance and dependability.

Model-based engineering involves the creation of models of the system at a level of abstraction that is relevant to the analysis to be achieved. Traditionally, this has led to the creation of different models of the same system by different stakeholders. Dependability engineering resulted in the creation of fault trees for fault analysis and markov models for reliability analysis. Resource utilization analysis is based on resource demands and resource capacities. Scheduling analysis is based on a timing model of the application tasks. Security analysis involves the creation of a model in terms of security levels and domains applied to subjects and objects. In other words, a number of independently created models reflect the same system architecture and any change to this architecture during its life time requires each of these models to be updated and validated that it correctly reflects the actual system architecture. Similarly, it is difficult to consistently reflect any changes in one analysis dimension in other dimensions, e.g., consistently reflect the impact of choosing a different security encryption scheme on intrusion resistance as well as on schedulability and end-to-end latency.

So it becomes important to integrate the different analysis dimensions into a single architecture model. An architecture model that is annotated with analysis-specific information can drive model-based engineering by generating the analysis-specific models from this annotated model. This allows changes to the architecture to be reflected in the various analysis models with little effort by regenerating them from the architecture model. This approach also allows us to evaluate the impact across multiple analysis dimensions.

The AADL was developed for just such a purpose. It was developed from significant experimentation and research over 15 years. It provides a language that is useful across domains where real-time, embedded, fault tolerant, secure, safety critical, software-intensive systems are developed. Its natural fields of application include avionics, automotive, autonomous systems, process control, and medical. Because of the strong need in today's complex systems, it has stimulated large industrial initatives to leverage the power of architectural multidimensional analysis and automated system integration from the specifications and models.

Standard Development

History

The AADL language has been formed from three major areas. Its proof of concept and base for development was the MetaH language. MetaH was developed by Honeywell Labs, with Dr. Steve Vestal as principle investigator, over 12 years and three DARPA programs [1]. It was used in over 40 experimental projects, many of them DARPA programs, internal Honeywell investigations, Army experiments [2] and/or SEI experiments.

The second major area of input to the language was the other ADL languages developed by DARPA and within industry. Experience with these languages and MetaH, especially at the SEI by Dr. Peter Feiler, were also leveraged in the design of the AADL which broadened the domain of application and helped form the core AADL from which extensions would be later developed. Expertise on the standardization committee with UML and HOOD/STOOD were also leveraged to validate concepts, provide an industrial strength solution and ease integration within the industry.

The third major area of input was through the members of the SAE committee (see figure 1) which developed the requirements document, the core standard AS5506, and the annexes to the standard. Many language features were formed from the expressed needs of industry representatives from many of the major aviation and real time systems companies in the US and Europe.

Many of the participants are leading engineers in their companies developing the next generation approaches for computer system development. These engineers recognized early the need for a common standard ADL to support computer system engineering in performance critical systems.

A fourth area now impacting the AADL is industrial pilots and university research programs that have adopted the AADL as a means to express performance critical architecture, analyze and then automate the integration of performance critical systems. These research programs along with industry experiences with AADL version 1.0 are providing and will provide guidance for AADL version 2.0, which will be balloted in summer, 2008.

Research projects in Europe have significantly contributed to the standard, and are expected to continue to do so. COTRE [3,4] and TOPCASED [5] are two Airbus led programs that have worked closely with the committee.

The ASSERT [6] program, European Union funded and European Space Agency led, is also working closely with the committee. Several new research programs in the US and in Europe will be discussed later which will impact the standard into the future. Annexes provide a way of extending the language incrementally so that tools can support or use those aspects important for their domain of application. Several new annexes are under development. The Behaviour Annex has been prototyped and used on several research programs in Europe.

It is now being updated for AADL version 2.0. It will have a strong fit with the core language.

The UML profile of AADL has been partially (as of this writing) implemented in the Rhapsody toolset based on a UML 2 meta-model developed by Ed Colbert.

The OMG MARTE committee has developed and is prototyping guidelines for expressing AADL as a subset of the MARTE profile. As this subset is formalized into a full profile through a joint AADL/MARTE effort, it is expected to become the standard AADL profile for UML. Also, an annex is being developed to better support analysis in Net-Centric systems.

Based on experience with SAE AADL in industrial projects, improvements to the language have been suggested. Version 2 of the AADL standard includes better support for architecture patterns, for modelling protocols, virtual channels, processor partitioning, and layered architectures. First ballot of AADL V2 is expected in Spring 2008.

AADL Language

The AADL provides components with well defined and precise semantics to describe computer system architecture. Precise semantics, hybrid automata, are used to express system state and timing. Version 2 will add additional temporal logic expressions for ports and threads. Using the well defined and precise semantics allows quantitative analysis, system integration and glue code generation to build predictable systems.

The language is designed to be incrementally refined as more information is available and provides permissions relative to the semantics.

Components have a type and one or more implementations.

Software components include data, subprogram, thread, thread group and process. The hardware components include processor, memory, bus and device. The system component is used to describe hierarchical grouping of components, encapsulating software components, hardware components and lower level system components within their implementations.

Interfaces

to components and component interactions are completely defined. The AADL supports data and event flow, synchronous call/return and shared access. In addition it supports end-to-end flow specifications that can be used to trace data or control flow through components.

The AADL supports real-time task scheduling using different scheduling protocols. Properties to support General Rate Monotonic Analysis and Earliest Deadline First are provided in the core standard. The core also provides a property extension mechanism to define properties needed for additional forms of analysis. Execution semantics are defined for each category of component and specified in the standard with a hybrid automata notation.

Modal and configurable systems are supported by the AADL.

Modes specify runtime transitions between statically known states and configurations of components, their connections and properties. Modes can be used for fault tolerant system reconfigurations affecting both hardware and software as well as software operational modes.

The AADL supports component evolution through inheritance, allowing more specific components to be refined from more abstract component. Large scale development is supported with packages which provide a name space and a library mechanism for components, as well as public and private sections. Packages support independent development and integration across contractors. AADL language extensibility is supported both through a property sublanguage for specifying or modifying AADL properties.

The AADL also provides an annex extension mechanism that can be used to specify sub-languages that will be processed within an AADL specification. An example is the Error Modeling Annex which allows specification of error models to be associated with core components. The combination of annex extensions and user defined property sets provide the means to integrate new specification capabilities and new analysis approaches to support the analysis tools and methods desired for multiple dimensions of analysis. A number of other papers are referenced for a more detailed description of the language and are available on the AADL website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] under "Home/Presentations and publications repository".

Model Based Engineering and Process Integration

Model-Based Engineering Process

The Model Based Engineering (MBE) for computer systems, as we use the term, includes the concepts of architectural specification, architectural analysis, and automated integration with generation of communication, glue code and the system executive to construct the final system. The MBE analyses are computer processable from the specification and quantitative.

The AADL supports all the MBE concepts and adds significant additional capability and flexibility in a public standard. See figure 2 for the discussion below. Architecture analysis is rerun each time the specification is updated, to provide model checking of the architecture as the architecture itself is refined (early trade-off analysis of architectural styles and hardware/communication effects or changes during the development or lifecycle) and as software components are developed and refined. Properties reflect the attributes of hardware and software components, connections, and ports and along with language semantics are used in analyses. Properties can capture estimates, requirements, or component options. Estimates may proceed to final values based on measurement as development proceeds.

The integration of property values (estimates to measured) can be compared to higher level requirements.

Multiple architecture analysis methods, such as schedulability, latency, safety, are selected and run on the system model as it is incrementally developed. Models can be high level, low fidelity abstractions for some analyses, or early in development. The specification is refined during development and used to explore solutions as risks are discovered. Large models may be generated from system databases.

Analysis methods provide the cross checking needed to understand the effects of component or system change on schedulability, latency, safety, utilization, fault tolerance etc.

The analyses themselves can be incrementally added as new analysis tools become available by adding the appropriate properties throughout the system lifecycle. System of systems integrators can collect AADL specifications of lower level systems and analyze the higher level integrated system. Analysis methods and analysis tools will have to be selected consistent with the system architecture approach used. System developers will develop some special analysis for their own system 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 Beacon), hand coded, or reused/re-engineered. Given the AADL specification, source code for the application and the execution environment (processors, buses. memory, devices plus operating system, compilers etc), tools can automate the process of system configuration, composition and runtime system generation.

These system integration/generation tools need to be consistent with the analysis methods and AADL semanticsgenerated according to the AADL specification. However, with generation, prototypes can be rapidly developed to experiment with the system effects due to architecture changes. An additional concept, the model bus, provides for automated, systematic integration of information from various engineering sources, tools and notations into the architecture specification. Advanced industrial research at Airbus and Boeing, as well as others, include the model bus for transferring data to and from models and to and from development and analysis tools.

Research at Rockwell has found that tools are typically extendable to allow more specific semantics and that the AADL makes an excellent intermediate language to represent the semantics of architecture in the databases and across tools. Transformations do not need to cover the whole domain of a specific language or toolset but only those parts that are needed to populate the analysis models. Model buses use meta-model specifications of the notations and transformations occur at the metamodel level.

Analysis Methods

Once the architecture or a critical subset of the architecture has been captured in an AADL specification, the properties can be added for the analysis of interest. For analysis, architecture data is extracted from the specification (by plug-ins in Eclipse based OSATE environment [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] and are solved within the plug-in or exported to an external analysis toolset. The ability to perform analyses can be incrementally added to a specification by adding properties, adding any additionally needed aspects of the architecture, and if the analysis interface does not already exist, plug-ins to extract from the specification the needed information to export. To develop the ability to run multiple analyses on the same architecture, properties are added for each analysis. See figure 3 for an example from the aviation domain, a partition specified as an AADL process with properties to support multiple analyses, in this case partition latency, security, and processor and memory utilization.

This example also demonstrates the incremental capabilities built into the AADL, at this point the DisplayManager has only port groups defined in its interface, yet that is sufficient to evaluate data flow timing across partitions. This subsystem is part of a much larger example of incremental specification and multidimensional modelling in an avionics architecture made available [START_REF] Feiler | Evolution of an Avionics System[END_REF].

Figure 3 A Subsystem with Multiple Properties

The fact that the AADL can be used for multiple domains of analyses has been demonstrated as illustrated in Figure 4. At the center of the figure is the specification captured in the AADL. Multiple analysis methods from each of these domains have been demonstrated with AADL specifications using publicly available tools or company internal tools. Analysis development has been a rapidly expanding area with the expressability of the AADL.

A number of analyses not on this diagram have also been demonstrated, such as simulation of AADL architectures, Petri net analysis, concurrency analysis based on process algebra and fault containment analysis. Here are some example analyses. The latency analysis example provided by Rockwell [START_REF] Mettenburg | Industrial Applications of AADL -AADL Avionics Case Studies and Concepts for integrating AADL into System Development[END_REF] is based on an existing aviation architecture using the OSATE toolset and analysis plug-in. Its output indicates a violation in the real-time performance domain. 1600 flows were specified. See figure 4 below.

AADL Integration Pilot (OSATE) CDU Key Press Analysis

Analyze Latency…

Analyze Latency…

Figure 4 Example use of Latency Analysis

In the domains of data quality and security analysis, several analysis tools were added to OSATE during a recent research study at the SEI. This study was applying AADL and analysis techniques for the design of Sensor Networks but the analysis of security and data quality should be applicable to many applications.

Analysis in the resource consumption domain on a similar aviation system was demonstrated at Rockwell using internal analysis tools. The workload analysis results identified the possibility of reducing the number of processors, thereby decreasing system cost on each system. See Figure 5. Analysis of resource consumption using AADL is available through multiple toolsets. A partial list of tools is on the AADL website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF] under "Tool Integrators" page then "toolsets" and under "Home" page then "Rapid Growth Seen In New AADL Toolsets". In fault tolerant, safety critical systems error modeling is an important aspect of architectural design and should be integrated into the architecture specification so it can be cross checked against changes. The MetaH language originally supported reliability modeling and this capability has been significantly extended in the AADL through the Error Modelling annex to support multiple forms of safety and dependability analysis through error models that are attached to architectural components [START_REF] Vestal | An Overview of the Architecture Analysis & Design Language (AADL) Error Model Annex[END_REF]. See Figure 6. Additional information on error modelling and plug-ins is also on the SEI website [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF]. See under "Home" then "OSATE error modelling plug-in and other materials" for a guide to building error models.

Each component can have an error model. The architecture specification provides the foundation for understanding propagation and the effect of failure. Component error models integrate into a system error model through the architecture specification. Architecture specification changes then affect the error modeling directly making it much easier to maintain and discover impacts. See Figure 7. Some of the supported analysis approaches include hazard analysis, failure modes and effects analysis (FMEA), fault trees, and Markov processes. Honeywell has demonstrated error modelling (hazard and FMEA) using annex capabilities on a large aircraft system [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]. ASSERT has modelled a dual redundant fault tolerant computer system using the annex [START_REF] Rugina | Dependability modelling of a fault tolerant duplex system using AADL and GSPNs[END_REF][START_REF] Rugina | Dependability Modelling using AADL and the AADL Error Model Annex[END_REF].

Error models are used to develop multiple types of system dependability models and these can be analyzed within a single specification allowing consistency checking between them. See figure 8.

Figure 8 Integrating Dependability Analysis

Honeywell has also done analysis on multiple aircraft platforms with a variety of buses, system synchronization approaches, and sizes. These analyses included resource consumption on processors and buses, global scheduling across multiple scheduling paradigms, switched network tuning, and FMEA and Hazard analysis [START_REF] Vestal | Automating Timing and Safety Analyses from Architecture Specifications[END_REF]. These analyses and others among AADL users have had a direct impact on the AADL standard, demonstrating and refining capabilities for industrial application. See figure 9.

AADL Workshop Oct 2005

Evaluations

Evaluations of various methods and tools have been carried out over the past few years using one or more of the following workloads.

Air transport aircraft IMA (simplified production workload)

Globally time-triggered 6 processors, 1 multi-drop bus 105 threads, 51 message sources

Military helicopter MMS (first release, partial)

Globally time-triggered 14 dual processors, 14 bus bridges, 2 multi-drop buses 306 threads, 979 [source, destination] connections

Air transport aircraft IMA (preliminary, partial)

Globally asynchronous processors, precedence-constrained switched network 26 processors, 12 switches 1402 threads, 2644 [source, destination] connections

Regional aircraft IMA (production workload)

Globally time-triggered 49 processors, 2 multi-drop busses 244 processes (TBD threads), 3179 [source, destination] connections Figure 9 Aviation System Architectures Modeled An aviation system AADL specification is available with instructions to demonstrate incremental, multifidelity analysis across multiple analysis dimensions. It has been posted on the SEI web site [START_REF] Feiler | Evolution of an Avionics System[END_REF]. It uses the Open Source AADL Toolset Environment (OSATE) editor and analysis plug-ins. There are a number of AADL tools, many with analysis capability listed on the web site [START_REF]OSATE Toolset, Error Modeling Plug-ins[END_REF]. Specifications can be moved from tool to tool to leverage analysis capabilities. In some cases the tools are designed to work together for tighter integration, but well defined semantics and a significant core capability have enabled specifications to be moved from toolset to toolset to leverage analysis as demonstrated on ASSERT.

An important aspect in integrating multiple analysis approaches is the standardized AADL meta-model and XML schema. It provides a standard database format for analysis tool interaction. Tools can not only read from the XML models but also post back into it. For instance, a scheduling and binding toolset would be used to optimize processor and bus utilization given the constraints on binding captured in the AADL and the properties of threads and communication overheads. Given that binding, a reliability, latency or safety analysis could follow. Finally, from the system instance, the system could be automatically integrated with generation of glue code. See figure 10.

Significant Industrial Initiatives and Research Drive Future Capability

The AADL standard's capability and extensibility has attracted a number of industrial initiatives and research projects on embedded systems analysis and verification. Most of these projects are cooperating with the AADL standardization committee to identify new capabilities needed in the language as well as developing analysis and code generation tools, and engineering methods.

Industrial initiatives are piloting the technology to work out changes in processes to accommodate MBE using AADL, including acquisition, development, and certification. The ASSERT and the TOPCASED initiatives have already made significant contributions to the AADL language and tools. See figure 11.

The Support for Predictable Integration of mission Critical Embedded Systems (SPICES) project [START_REF] Tilman | SPICES -Support for Predictable Integration of mission Critical Embedded Systems[END_REF], as described in their presentation to the AADL committee, is strongly oriented to AADL modelling and analysis for use in containers which would be integrated to form systems. "The principal goals of SPICES are to extend the capacities of the microCCM component-based framework and to couple it with an AADL modeller in order to offer to system architects, software architects, and application designers a component-based modelling, design and analysis environment for distributed realtime embedded systems that should be deployed over heterogeneous targets such as GPP, DSP or FPGA." See Figure 12. The first is to develop needed extensions to the AADL. These typically would be annexes like the Behaviour Annex Airbus is currently developing, but also corrections, extensions to the current standard where needed. The second work package is the development of additional AADL modelling tools and integrated verification and validation tools. The third work package is the generation of validated FPGA's and validated software component containers and how to build tools to port them onto the platform. Two work packages not shown on the figure focus on pilots and dissemination. Another new industrial initiative with a strong AADL focus is sponsored under the Aerospace Vehicle Systems Institute (AVSI) System and Software Integration Verification (SSIV) work tasks [START_REF] Chilenski | Aerospace Vehicle Systems Institute Systems and Software Integration Verification Overview[END_REF] and lead by Boeing. The AVSI is a cooperative of aerospace companies, DoD, and FAA to improve the integration of complex subsystems in aircraft. This AVSI project includes not only US contractors and system integrators but also European as well.

Airbus and Dassault are joining with Boeing, Lockheed Martin and a number of US suppliers.

There is an opportunity for European suppliers to also participate.

The theme of the AVSI-SSIV is "Integrate -then Build". It's objectives are listed in figure 14, and includes integrated analysis of the system, software, and hardware for performance, safety, security, and functionality. The prediction of system behaviour by analysis to assure acceptability occurs before the system building process begins through virtual integration. Some requirements are determined through analysis. These analyses will at least maintain existing levels of safety and security but are expected to improve them, since analysis and formal modelling will find issues testing and simulation often miss. This approach moves the industry beyond process toward evidence for safety and security.

As can be seen in figure 15, this approach modifies the acquisition process.

The system integrator provides virtual models of "parts" to potential suppliers, who respond with their models of these subcomponents that fit the requirements they are bidding. Then these components are virtually reintegrated, with feedback, by the system integrator. This approach fits with investments made in Europe with the AADL and Model Based Engineering.

Modified Business Model Modified Business Model

 System Integrator defines a new product using internal repository of virtual "parts"  Specifications for virtual subcomponents sent to suppliers Figure 15 Virtual Integration Based Acquisition Figure 16 illustrates the way the model bus will be used to integrate models, exchange information between tools and between the system integrator and the suppliers.

The model bus plays an important role by keeping the approach from depending on specific tools. It allows the integration of tool results into the models and the models with analysis tools. The AADL was selected after an extensive study of architecture description languages in industry and academia for its capability, existing tools, and extensibility mechanisms. The combination of research projects and industrial initiatives are bringing AADL tools and analyses to industry as well as contributing to the AADL standard.

Conclusion

The AADL's standardized component based, well defined, semantics for runtime system architecture, integrating the computer hardware and software specifically supports capturing the architecture for multi-dimension analysis. As such, it becomes an excellent place to integrate computer system engineering requirements, platform development and software engineering concerns.

New research projects are likely to add new analyses and more highly automated approaches for system integration as well as new industrial acquisition processes which leverage model based engineering across multiple critical system performance dimensions.

The AADL provides or supports through tools significant model based embedded system engineering benefits. These include:

Figure 1 :

 1 Figure 1 : Industry-Driven International SAE AADL Standard 2.2 Current State The core AADL standard [7], version 1.0 was published in Nov. of 2004. A standard set of Annexes was published in June of 2006 [8]. These annexes included Graphical AADL Notation, AADL Meta-Model/XML Definition, Programming Language Guidelines, and Error Modeling. Annexes provide a way of extending the language incrementally so that tools can support or use those aspects important for their domain of application. Several new annexes are under development. The Behavior Annex has been prototyped and used on several research programs in Europe. It is now being updated for AADL version 2.0. It will have a strong fit with the core language. The UML profile of AADL has been partially (as of this writing) implemented in the Rhapsody toolset based on a UML 2 meta-model developed by Ed Colbert.The OMG MARTE committee has developed and is prototyping guidelines for expressing AADL as a subset of the MARTE profile. As this subset is formalized into a full profile through a joint AADL/MARTE effort, it is expected to become the standard AADL profile for UML. An annex is being developed to better support analysis in Net-Centric systems. Based on the experience with SAE AADL in industrial projects improvements have been suggested. Version 2 of the AADL standard includes better support for architecture patterns, for modelling protocols, virtual channels, processor partitioning, and layered architectures. First ballot of AADL V2 is expected in Spring 2008.

Figure 2 :

 2 Figure 2 : Model Based System Engineering

Figure 3 14 ©

 314 Figure 3 Analysis of Multiple Critical QualitiesHere are some example analyses. The latency analysis example provided by Rockwell[START_REF] Mettenburg | Industrial Applications of AADL -AADL Avionics Case Studies and Concepts for integrating AADL into System Development[END_REF] is based on an existing aviation architecture using the OSATE toolset and analysis plug-in. Its output indicates a violation in the real-time performance domain. 1600 flows were specified. See figure4below.

Figure 5

 5 Figure 5 Aircraft Resource Consumption Modeling

1 ©Figure 6 Figure 7

 167 Figure 6 Component Error Models

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

Figure 10 :

 10 Figure 10 : Standardized and Simplified Tool Integration Supported

Figure 11

 11 Figure 11 Industrial Initiatives Using the AADL

Figure 14

 14 Figure 14 AVSI-SSIV Objectives

Figure 16

 16 Figure 16 Integrated Tools/System Model via Model Bus & Repository

Figure 1 :

 1 Figure 1 : Industry-Driven International SAE AADL Standard 2.2 Current State The core AADL standard [7], version 1.0 was published in Nov. of 2004. A standard set of Annexes was published in June of 2006 [8]. These annexes included Graphical AADL Notation, AADL Meta-Model/XML Definition, Programming Language Guidelines, and Error Modelling.

Figure 2 :

 2 Figure 2 : Model Based System Engineering

Figure 3

 3 Figure 3 Analysis of Multiple Critical Qualities

9 ©Figure 5

 95 Figure 5 Aircraft Resource Consumption Modeling

1 ©Figure 6 Figure 7

 167 Figure 6 Component Error Models

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

Figure 10 :

 10 Figure 10 : Standardized and Simplified Tool Integration

Figure 11 Industrial 8 SPICESFigure 12

 11812 Figure 11 Industrial Initiatives Using the AADL

Figure 13 SPICES

 13 Figure 13 SPICES Extends AADL through System Building

www.aadl.info www.aadl.info 9 Ambulatory Information Fusion Supply Chain Mechanized Sensor & Signal Processing System Integration •Runtime System Generation • Application Composition • System Configuration Devices Memory Bus Processor Model-Based System Engineering Automatic Target Recognition Guidance & Control System Analysis • Schedulability • Performance • Reliability • Fault Tolerance • Dynamic Configurability Architecture Modeling Abstract, but Precise HTTPS DB GPS Ada Runtime Execution Platform . . . . . . . . . . Application Software Software System Engineer Composable Components Predictive System Engineering

	Reduced
	Development &
	Operational Cost

system, software, and hardware integration models in one framework  Support component-based system assurance through analysis of functionality, performance, safety and security  Increase the degree of standardization and commonality for technical data exchanged between airframers, suppliers, and regulatory authorities  Integrate -then build  Predict system behavior through analysis to ensure it is acceptable  Build to the requirements determined through the analysis  Reduce the cost of developing avionic systems  Maintain or improve existing levels of safety and security  Start with the aerospace industry  Leverage capabilities developed in related domains  Coordinate with related domains when advantageous  Foster U.S. Government and Aerospace industry Cooperation  Complement the large, government/industry funded European R&D efforts

	Expanded Objectives Expanded Objectives
	Version	Aerospace Vehicle Systems Institute	Slide 4 August 7, 2007
		Figure 14 AVSI-SSIV Objectives
		Aerospace Vehicle Systems Institute	Slide 7

 Integrate

Version Aerospace Vehicle Systems Institute Slide 6 Overview of Multi Overview of Multi--Aspect Model Aspect Model Repository & Model Bus Repository & Model Bus

  Figure 16 Integrated Tools/System Model via Model Bus & Repository AVSI-SSIV is designed as a multi-phased program. The first phase was a planning phase and is near completion. The next phase is a one year task to demonstrate viability of the approach, which includes demonstrating AADL, analysis and the model bus and develop a new model based acquisition process for industry. This next phase will start in the spring of 2008 and is estimated at about $4M. Additional work packages are being defined for follow on research and industrial process definition, which if funded, could reach $40M. Both the AVSI-SSIV and the SPICES programs are interested in exploring incremental certification approaches and the impact that quantitative/formal modelling can have on certification and testing. Research programs are also a major contributor. A major advantage of the AADL is that research into new analysis methods does not depend on the development of specializations of generalized languages, such as UML, but rather the use of the standardized, well defined, architectural semantics of AADL. (UML, however, can be used to express AADL through specialization, avoiding inventing one's own custom language.) The result is that analysis tools can be leveraged across the industry and new research methods can be rapidly applied to existing AADL specifications. A number of research organizations and PhD students are leveraging the AADL for architectural analysis including safety critical avionics architecture, formal methods and assumption management at the University of Illinois under Prof. Lui Sha and Sensor Network Design and Analysis at the University of Virginia under Prof. Sang H. Son and Prof. John Stankovic. See papers at IEEE Real-Time Systems Symposium 2007. Prof. David Gluch has been applying AADL for safety, reliability and dependability analysis in real time fault tolerant systems at Embry Riddle University. The Software Engineering Institute has research projects in security analysis and fault avoidance and fault management under Dr. Jorgen Hansson and Dr. Peter Feiler. Prof. Oleg Sokolsky at the University of Pennsylvania has developed tools for AADL simulation and a process algebra based scheduling analysis toolset in association with Fremont Associates. Tools for automated integration of realtime networked systems based on AADL specifications (OCARINA) have been developed under Prof. Laurent Pautet and Prof. Jerome Hughes and advanced scheduling analysis tools (Cheddar) under Prof. Frank Singhoff at ENST ( Ecole Nationale Superieure des Telecommunications ) including integrations with TOPCASED and STOOD toolsets. Prof. Mamoun Filali of Universite Paul Sabatier, CNS, and IRIT has researched AADL and formal methods and is leading the development of the Behaviour Annex. Research at LAAS, (Laboratoire d'Analyse et d' Architecture des Systemes) contributed to the Error Modelling Annex and guidelines for its application.

	Requirements	AADL	Verification
	Eclipse		OSATE
	MatLab		SCADE
	SimuLink	Model Repository	TOPCASED
	Rhapsody		?
	Esterel		DOORS
		SysML
	Design		Integration/Deployment

© Copyright 2006 Rockwell Collins, Inc. All rights reserved.

© Copyright 2006 Rockwell Collins, Inc. All rights reserved.

Real-Time systems », AADL Standardization Meeting, Edinburgh, July 2004. [START_REF]Avionics Architecture Description Language Standard[END_REF]

Acknowledgement

The author would like to thank the AADL standardization committee for their diligent efforts and willingness to share through their presentations what they are doing with the AADL. Many of the papers referenced below have been developed by committee members.


J-M Astruc
email: jean-marc.astruc@continental-corporation.com

N Becker

Towards functional safety in automotive electronics

Keywords: Automotive E/E systems, functional safety, IEC61508, ISO26262

The part of electronics in automobile design becomes more and more important with an exponential growth during the last 10 years. Nowadays, innovation in automotive industry is driven by electronics. New upcoming electrical/electronic systems (E/E systems) such as advanced driver assistance systems or x-by-wire systems as well as consumer expectation regarding safety will require a dedicated standard to ensure design, development and production of safe products before their introduction on the market. ISO/TC22/SC3/WG16 has been formed to issue the ISO26262 international standard that will specifically address functional safety of E/E systems of automotive industry. This paper provides information about the future ISO26262 which is based on the current results of ISO/TC22/SC3/WG16 [1], those still being subject to changes before the international standard release.

Introduction

The use of E/E systems in the automotive industry has significantly increased over the past few years. Nowadays, it represents approximately 30% of the value of new vehicles [2]. E/E systems enable introduction of more and more complex and sophisticated functions inboard of vehicles, ranging from low-emission and low-fuel consumption engine management systems to highperformance stability control for chassis or advanced driver assistance systems. In case of malfunction, such system could have the potential for endangering the vehicle occupants or other road users. One major task of designers is to identify such hazardous conditions, determine their potential causes, e.g. hardware device failure, design flaw or weak manufacturing process, and mitigate or reduce the associated risks to an acceptable level in order to keep the E/E systems safe, even in case of malfunction. How safe is safe enough? An answer to this question is given by the application of current stateof-the-art. Industries with early and deep safety culture have defined and maintain their own state-of-the-art through standards. That is the case of Aeronautics with ARP 4754 [3], , and , as well as Railways with EN 5012x series [6]. The world-wide automotive industry represented within the ISO/TC22/SC3/WG16 is in the process of establishing such a state-of-the-art with ISO26262 project. The ISO26262 project is dedicated to the functional safety of automotive E/E systems, where functional safety is a state in which vehicle functions implemented by E/E systems do not present any intolerable risk resulting from:

• Specification, implementation or realization errors, • Failure during operation period, or

• Reasonably foreseeable misuse or operational errors.

Overview and principles

Adaptation of IEC61508

ISO26262 is intended to be the adaptation of IEC61508 [7] to the automotive industry. The IEC61508 standard entitled "Functional safety of Electrical/Electronic/Programmable Electronic safety related systems" was primarily originated by process and automation industries. Since 1998 it is used as a stand-alone standard and also as a basis for establishing other sector or product standards. Attempts of application of IEC61508 in automotive industry in the past have shown some weaknesses, including:

• A poor suitability to real-time embedded systems, • No adaptation to automotive development and life cycles, • No description of OEM / supplier relationships,

• No orientation to mass production of consumergoods. Moreover, additional characteristics of the automotive industry have to be taken into account in this adaptation: • There is no likely catastrophic event in the automotive industry: without additional aggravating circumstances a single failure in a road vehicle cannot lead potentially to as many casualties as a train or industrial plant accident; therefore the safety scale needs to be adapted.

• The E/E systems and functions inboard of vehicles are often used by drivers without any knowledge other than their basic driving habits, coming back to their driver's license. Moreover, there is no monitoring of vehicle maintenance: taking a car to garage for periodic service is not mandatory. However, safety of the vehicle needs to be ensured. • Innovation comes as often from the suppliers as from the OEMs, the standard must address the specificity of the automotive development process of the automotive industry.

Scope of ISO26262

ISO26262 is restricted to functional safety of E/E systems installed in road vehicles of class M, N and O, namely:

• Motor vehicles with at least four wheels designed and constructed for the carriage of passengers, • Motor vehicles with at least four wheels designed and constructed for the carriage of goods, • Trailers (including semi-trailers).

For this purpose, ISO26262 gives guidelines how to take into account system, hardware as well as software failures and to control their potential effects on vehicle safety. However, ISO26262 does not address performance of E/E systems; e.g. the effectiveness of an airbag to reduce the injuries of vehicle occupants in case of crash is out of the scope of ISO26262, while features designed to avoid unexpected deployment of the airbag are in.

ASIL -Automotive safety integrity level

ISO26262 introduces a four-level ranking for functional safety risks, so called Automotive Safety Integrity Levels or ASILs which is derived from the SIL scaling of IEC61508. The highest level of IEC61508 (SIL4) is not applicable to automotive for reason previously mentioned; thus there is no direct correspondence between ASILs and SILs. ASIL assigned to an E/E system depends on potential consequences of its malfunctions. The ASIL defines the nature and rigor of measures to be applied for ensuring functional safety of this E/E system. It begins with definition of the "item". The term "item" generically designates a function, an E/E system, or a component that is to be taken under consideration. Its definition includes functionalities, operating modes and conditions, environment, etc. Next is the identification of the "safety goals", i.e. the conditions to be maintained at item level in case of failure to avoid unacceptable risk (see section 3). A "safety goal" corresponds to the positive wording for a safety-related undesired event of an item. An ASIL is attributed to every safety goal. The functional safety concept of the item is the first step of the design of the safety architecture of the item (see section 4.1). It is a set of requirements applying to the different parts of the architecture of the item to guarantee its safety. It covers the potential failures of the different parts of the item. It may also refer to mechanical or other technologies parts, which are out of the scope of ISO26262. The technical safety concept implements the functional safety requirement (see section 4.3) on system architecture. It also allocates the technical safety requirements to hardware (see section 5) and software (see section 6).

Random and systematic failures

Safety-related special characteristics identified during system, hardware and software development are monitored during the production of the item (see section 7). In addition to this core technical process, the ISO26262 standard adds some requirements on the management (see section 8).

Hazard assessment and risk analysis

As stated before, the aim of the ASIL evaluation is to provide the industry with a robust way of assigning a level of safety effort to the item under consideration. This is the reason why the methods and parameters to be taken into account are explicitly mentioned in ISO26262: it is the best way to avoid discrepancies between evaluations performed by different teams with different methods. The ASIL evaluation is performed at the vehicle level. The target of this evaluation is to evaluate the risk level on a graph "severity vs frequency" ; the ASIL level and the associated measures described in the standard will enable the system to reach the "acceptable area".

The first step is to identify the safety goals for the item to be considered throughout the development. For this purpose, after having established the functionalities of the item, an analysis of the effect of its failures on the vehicle shall be performed. A scenario tree shall be established to identify the situations in which such a failure may have safety impacts. For each scenario, the effects of failure of the item are evaluated on the severity/frequency graph. Frequency has been decomposed in Exposure and Controllability. Therefore three parameters are evaluated:

• Exposure: this is the occurrence of the driving situation in which a failure in the item may be dangerous during the life of the vehicle. It is ranked from E1 (very low probability, such as the occurrence of a crash during the lifetime of the vehicle) to E4 (very often / always, such as driving on a motorway) with a roughly ten-time increase in probability from one step to the next. • Controllability: this is the estimation of the ability of the driver to control the effects of the feared event if it occurs. It is ranked from C0 (any driver can control the event, the skills required to get a driver's licence are sufficient) to C2 (Less than 90% of drivers are able to control the event). This parameter is evaluated through expert advice and/or novice tests. A Code of Practice on the evaluation of controllability in the automotive industry has been published in the European Project PReVENT/Response 3 [8]. • Severity: this is an evaluation of the criticality of the consequences of the event if the driver was not able to control it in a potentially dangerous driving situation. It is ranked from S0 -no consequences to S3 -Life-threatening injuries (survival uncertain), fatal injuries. The ASIL evaluation for each scenario is given through a risk graph implemented in a table in the standard. The ASIL level of the safety goal is the maximum ASIL reached for the different scenarios. An item whose failure would be often dangerous (E4), difficult to control (C2), and with severe consequences (S3) would be ASIL D; any change in the evaluation of a parameter will decrease the ASIL evaluation, down to QM (Quality Management): at this level, the usual quality management activities performed in a non-safety development are considered sufficient to handle properly the item.

In addition to each safety goal, the appropriate safe states shall be described.

The safety goal classification implies several systemwide requirements:

• To apply activities and method to avoid systematic failures, at the selected ASIL level, • To introduce safety mechanisms to control random hardware failures. Quantitative targets are required for ASIL levels B, C and D with regard to the coverage of these safety mechanisms. Quantitative targets are also required for the probability of occurrence of random hardware failures for ASIL C and D.

Functional safety at system level

After having established the safety goal and its ASIL evaluation, it is time to proceed with the system design.

The target is to establish a functional and technical safety concept for the item.

ASIL allocation

One of the outcomes of the functional safety concept is that each functional safety requirement shall be assigned an ASIL level, and shall be allocated to an element of the architecture of the system. Basically, each element shall be assigned the ASIL level of the safety goal. However, ISO26262 offers a possibility named ASIL decomposition: it allows to take into account the architecture of the item to alleviate the ASIL level at the element level for the avoidance of systematic faults, if :

• They implement redundantly the same safety requirement, • They are independent from each other (no common cause of failure). Some important points shall be noted : • This ASIL decomposition mechanism only deals with measures related to systematic failures. The random hardware failures are allocated independently to the elements of the architecture, following other rules (Fault tree analysis for instance).

• The confirmation and verification measures shall be applied at the initial ASIL (the ASIL of the safety goal).

Technical safety concept

The Technical Safety Concept describes how the functional safety concept is technically implemented in the item, for every element of the architecture.

For instance, if the functional safety concept requires the diagnostic of a certain element, its type, its coverage, along with its frequency, shall be described in the technical safety concept. Other examples include the allocation of probability of violation of the safety goal to the hardware elements.

The technical safety concept shall also specify the test intervals for the safety mechanisms (e.g. at each power-up of the vehicle).

The system design and its technical safety concept shall be verified through a safety analysis such as a system-FMEA, and by simulation or vehicle-level tests.

The Technical safety concept and its requirements shall be developed down to the allocation between hardware and software of each element.

Verification and validation of functional safety

The implementation of the technical safety concept shall be verified through tests at the relevant level (system, software, hardware). It can include test of the implantation against the technical safety requirements, errors injection, validation on test benches including HIL, etc. Moreover, the safety concepts shall be validated at the vehicle level at the end of the development, before the release for production. This validation shall cover the controllability, the safety measures used to control systematic and random failures, etc.

Functional safety at hardware level

The goal of this phase is to implement the requirements of the technical safety concept allocated to the hardware. Both systematic and random hardware failures have to be considered in this phase.

Hardware development process

Development of hardware is divided into several activities:

• Safety specification of the hardware: the target is to come up with a set of hardware safety requirements, implementing the technical safety concept. They shall be verified to be consistent and exhaustive.

Measures for systematic failures of hardware

For the avoidance of systematic failures, this part of the standard relies on strict development methods, including semi-formal methods for specification for ASIL C and D. The standard also promotes the use of HW design simulation for ASIL C and D.

Probability target for hardware random failures

A probabilistic evaluation of the safety risk due to random hardware failures is mandatory for ASIL C and D. This evaluation may be done directly at the system level, for instance through a quantitative fault tree. This evaluation shall take into account both single point faults and multiple point faults. It shall also take into account the diagnostic frequencies of the different parts of the hardware. The target for this evaluation can be derived from different sources:

• Either an evaluation of a suitable existing design, or • An informative table given in annex of the standard. The target is an average failure rate per hour over the lifetime of the vehicle; it is set at 10 -8 per hour for ASIL D systems and 10 -7 per hour for ASIL C systems. It can also be done at component level: for ASIL D system, identified single points failures must have a failure rate of 10 -10 per hour if the diagnostic coverage for this single point failure is below 90%. Corresponding probabilistic targets are derived for better diagnostic coverage and multiple point failures.

Architecture targets for hardware random failures

An evaluation of the diagnostic coverage at the system level is also required by the standard for ASIL C and D. It is an adaptation of the Safe Failure Fraction of IEC 61508. Two metrics are defined in ISO26262. They are both calculated as ratios of failure rates; this improves their robustness against doubts in the absolute values of failure rates derived from databases or from field observation. They only apply to safety-relevant components; these are components whose at least a failure mode may impair safety. This avoids modifying the metrics by taking into account components unrelated to the safety of the hardware under consideration. The first metric is named "Single point faults metric". It is defined as the ratio of the failure rates of safety related elements which fail in a safe state (either inherently by design, or through a diagnostic mechanism) to the sum of the failure rates of safety related components in the hardware of the item. It can be illustrated as follows:

R

Faults leading to a safe state through a safety mecanism

Safe faults

If R are the faults leading directly to a violation of the safety goal (esp. the single point faults without diagnostic), the metric is defined as

F S R F S SPFM + + + =
The target for this metric is set at 99% of coverage for ASIL D systems, as a mandatory requirement. Lower ASIL levels have adapted requirements. A second metric is dedicated to latent faults. It aims to minimize the proportion of latent faults that are not indicated to the driver and might impair its safety in the long run. Undetected loss of a safety mechanism falls into this category: it is generally not directly dangerous but reduces the safety of the driver because a further fault in the system may be dangerous. This metric is defined in a similar way as the previous one; it is the ratio of the failure rate of the multiple point faults which are perceived by the driver (generally indicated by a warning lamp) to the sum of the failure rates of the system. The target for this metric is set at 90% of coverage for ASIL D systems, as a mandatory requirement. Lower ASIL levels also have adapted requirements. Since the efficiency of diagnostic measures is a crucial point for both the probabilistic and the coverage evaluations, a table of usual measures is given in ISO26262 as general guideline.

Functional safety at software level

Like in any other sectors of industry, software used in automotive industry is subject to systematic failures, but not to random failures. Such systematic failures are mainly due to faults introduced in software during development or industrialization. They can potentially lead or contribute to the violation of safety goals assigned to automotive E/E systems. ISO26262 will provide a set of ASIL-dependent measures to be applied during development that aims at:

• Preventing the introduction of faults in software,

• Detecting the ones that could have been introduced. There are no quantitative targets assigned to software since software is not subject to random failures.

Software development process

For the purpose of fault avoidance, the description of software development process proposed in ISO26262 relies on academic V-cycle model. The development of software starts with the specification of software safety requirements once the technical safety requirements of E/E system are mapped on hardware and software components. It ends with software safety acceptance testing which is part of the safety validation of E/E system. The other basic phases of software development are:

• Software architectural design,

• Software unit design and implementation,

• Software unit testing, and

• Software integration and testing.

Sequencing and arrangement of those phases and their corresponding activities, methods and tools need to be planned and tailored prior to their execution or use. Tailoring depends on characteristics of software under consideration: it is new software to be developed, or software is entirely or partly reused, or COTS is to be integrated, etc. Additionally, the use of specific software or system engineering techniques such as model-based development or auto-coding has also an impact on the initiation of the software development that need to be planned at the very beginning of software development.

Co-existence of software with different ASILs

Because ISO26262 focuses on functional safety of E/E systems, one may think that software development phases only apply to the safety-related part(s) of software. Moreover, some phases such as the specification of software safety requirements or the software safety acceptance testing are only dedicated to the safety-related parts of software while others such as software architectural design or software integration and testing need to encompass software as a whole. Basically, in case of coexistence of safety-related software components with non-safety-related software components or in case of software components assigned with different ASILs in the same running environment, the complete software has to comply with the highest ASIL inherited from the technical safety requirements of E/E system unless freedom of interference between those components can be demonstrated. Interference means that a failure of a non-safetyrelated component potentially causes other safetyrelated component(s) to fail, respectively a failure of a component with lower ASIL causes other component(s) with higher ASIL to fail. Demonstration of freedom of interference between software components can be supported by the use of partitioning techniques.

Measures for systematic failure of software

Basically, the measures for preventing introduction of faults in software promote modularity, traceability with upstream work products and control of complexity. Among others, the formalism of notation to be used for work products varies with ASIL. The measures for detection of faults in software apply to work products as well as for software under its executable form. Work products are checked for compliance and completeness regarding upstream work products they are issued from. Attributes such as correctness, consistency and adequacy with target hardware are also checked. Additionally, potential failures of software are analysed at design and implementation level in order to determine how they could impair the software safety requirements or introduce hazards that have not yet been identified by previous safety analyses. Similarly to some other safety standards, testing of software is mainly driven by functional requirements.

Completeness of functional requirement-based testing is assessed through coverage of structure of software. The nature of structures to be covered (e.g. statement, decision, etc.) varies with ASIL.

Hardware-software interfaces

Regarding functional safety, hardware-software interface encompasses hardware resources that support execution of software as well as hardware devices controlled by software for the implementation of technical safety requirements of an E/E system. ISO26262 will provide guidance to ensure that adequate information is timely made available, shared and jointly verified by hardware and software development.

Calibration data

Software-based E/E systems in automotive industry are usually targeted for more than one vehicle or engine configuration or variant, e.g. a vehicle is equipped or not with cruise control, or with automatic gear box instead of manual one, or a system has to fit with different types of sensors or actuators, etc. For ensuring an adequate system performance and vehicle driveability for every application, an adaptation to each running environment is necessary. This is done with calibration data which tuning provides correct values for configurationspecific system, engine or vehicle parameters. ISO26262 will provide guidance for identification and management of safety-related calibration data as well as for verification of applications that use such calibration data.

Production and operation

The functional safety also relies on proper production and operation of E/E systems and components. ISO26262 requires that the safety-related special characteristics of elements shall be identified during the development process. These are characteristics of elements or systems for which uncontrolled deviation may lead to safety consequences. These characteristics shall be guaranteed to be within the tolerance in the production process, for instance through individual tests of each component. The automotive industry has a deep background with this kind of requirement, since it also applies to most safety-related mechanical components. The configuration management and management of calibration data are of prime importance; the production in automotive industry is often surprisingly diverse and improper configuration of the vehicle or component could lead to unpredictable results (e.g. when a software is uploaded to the wrong version of hardware). The next step is the operation of the E/E system by the customer. He will often need information on how to use the system, how to act when a warning lamp lights up, etc. This shall be included in the customer documentation. Relevant maintenance and decommissioning instructions shall also be issued for the workshops.

Functional safety assurance

ISO26262 will not only focus on technical aspects of functional safety, it will also address safety assurance of E/E automotive systems at organisational and project level.

At company level

Company duty includes setting policy and defining goals for achievement of functional safety. Policy includes statement of general policy and companyspecific rules and processes in order to comply with ISO26262 especially in the field of independent safety assessment, problem tracking and reporting, and lesson learning. It also implies installation of processes for in-field monitoring, reporting and handling of safety-related incidents once the product is put on the market, those being in line with general product safety regulations such as European directive 2001/95 and US Tread Act. Appropriate organisational structure will have to be set up in order to support responsibility, accountability of functional safety and grant corresponding authority. Moreover, people with adequate expertise and skill on functional safety of E/E automotive systems shall be assigned and sustained by the organization.

At project level

Project manager has basically the overall responsibility for ensuring functional safety, including the assignment of someone in the role of safety manager for his project. Safety manager is in charge of providing support and information to the project manager for any decision regarding functional safety. Safety manager is also responsible for functional safety management tasks: • For a carried over product, i.e. the one that is reused and installed without any change in a new environment, integration of this product within the new target environment and validation at system level are performed according to ISO26262, provided it is shown there is no impact on the product itself.

• Upgrade of a product for a new application implies design and/or implementation changes to the product. Design changes may result from requirements modification, functional or performance enhancement, cost optimization, etc., while implementation changes may be caused by changes in calibration data, correction of implementation errors such as software bug fixes, upgrade of production tools. In such case, the safety lifecycle is partly revisited depending on the impact of change with specific emphasis to potential side effects. The resulting product is integrated in the vehicle and validated at system level according to ISO26262.

• In case of development of a new product from scratch, the complete safety lifecycle is applied.

Proven-in-use argumentation

Additionally, ISO26262 will provide guidance for proven-in-use argumentation.

Proven-in-use argumentation for an existing product is an alternate means of compliance with the application of the safety lifecycle when field data are available. It may be used when:

• the product is carried over on a new target vehicle or engine, or reused for a new application, or • the product has been developed prior to the release of ISO26262 and/or to another safety standard, or • The product is COTS product not specifically developed for automotive industry. Proven-in-use argumentation relies on the following criteria:

• configuration management during service period, • change control, including those changes that may have been introduced since the previous usage of the product, • nature and availability of data resulting from development of the product, • analogy between future conditions of use and those encountered during the service period • relevance of service history Once those criteria are fulfilled, proven-in-use argumentation allows adjustment of reduction or suppression of design and implementation measures related to the nature of the product and its intended use.

Achievement and perspective

The goal for release of ISO26262 as an international standard is 2010.

•

  Hardware design: it shall implement the hardware safety requirements.• A safety analysis shall be applied to identify:

	o Single point faults.
	o Dual point faults (faults in a component that
	result in the violation of the safety goal in
	conjunction with another fault in another
	component. )
	o Compliance with targets for probabilistic and
	coverage metrics for the hardware
	• Components	qualification	and	hardware
	validation: the standard relies on well-proven
	test methods, such as environment testing,
	functional testing, over limit testing, fault
	injection testing, and corresponding standards
	(e.g. ISO 16750, etc.).

A Publicly Available Specification should be issued mid-2008 for public commenting and feedback purposes. The current work of ISO/TC22/SC3/WG16 has established a common understanding of what is functional safety of E/E systems within a dedicated expert community of OEMs and suppliers. It is in the process of reaching a consensus on current state-ofthe-art regarding all aspects of functional safety, including system, hardware and software. Once this international standard will be issued, it will define an international state-of-the-art for the development of such systems and therefore will be very useful for al stakeholders in the design of electronically implemented functions and systems in the automotive industry.