Figure 4 - uploaded by John Hudak
Content may be subject to copyright.
Typical Documentation of Avionics System Architecture A typical diagram of such a software architecture mapped onto the hardware is shown in Figure 4. Multiple instances of hardware and software are shown with little or no indication as to the intended functional redundancy. This results in speculation about the intended behavior of the system under fault conditions. Such information tends to be spread throughout the design document. For example, there are four MFD processors, four DMs, and four WAMs. Are they one operational unit with three spares, two operational units each with its own spare, or four fully functional operational units? What is the mechanism by which failures are detected? What is the mechanism by which failover is achieved? Does each replicated unit perform failover switching separately, or are groups of replicated tasks switched together? What data is necessary, if any, for state space preservation? What are the data sources that feed the redundant entities? Answers to these types of questions could not be ascertained from the architectural drawings. Reading through software design documentation uncovered some useful information, but not enough to completely model the system. It is in this setting that the AADL abstractions help guide us to a clear understanding of the fault tolerant aspects of the system.

Typical Documentation of Avionics System Architecture A typical diagram of such a software architecture mapped onto the hardware is shown in Figure 4. Multiple instances of hardware and software are shown with little or no indication as to the intended functional redundancy. This results in speculation about the intended behavior of the system under fault conditions. Such information tends to be spread throughout the design document. For example, there are four MFD processors, four DMs, and four WAMs. Are they one operational unit with three spares, two operational units each with its own spare, or four fully functional operational units? What is the mechanism by which failures are detected? What is the mechanism by which failover is achieved? Does each replicated unit perform failover switching separately, or are groups of replicated tasks switched together? What data is necessary, if any, for state space preservation? What are the data sources that feed the redundant entities? Answers to these types of questions could not be ascertained from the architectural drawings. Reading through software design documentation uncovered some useful information, but not enough to completely model the system. It is in this setting that the AADL abstractions help guide us to a clear understanding of the fault tolerant aspects of the system.

Source publication
Article
Full-text available
The emerging Society of Automotive Engineers (SAE) Architecture Analysis & Design Language (AADL) standard is an architecture modeling language for real-time, fault-tolerant, scalable, embedded, multiprocessor systems. It enables the development and predictable integration of highly evolvable systems as well as analysis of existing systems. This pa...

Context in source publication

Context 1
... this section, we focus on the dependability aspects of a system and how general fault tolerant approaches can be supported by the AADL. Figure 4. Multiple instances of hardware and software are shown with little or no indication as to the intended functional redundancy. ...

Similar publications

Article
Full-text available
The emerging Society of Automotive Engineers Architecture Analysis and Design Language (AADL) standard is an architecture modeling language for real-time, fault-tolerant, scalable, embedded, multiprocessor systems. It enables the development and predictable integration of highly evolvable systems as well as analysis of existing systems. It supports...
Article
Full-text available
In November 2004, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named the Architecture Analysis & Design Language (AADL). The AADL is a modeling language that supports early and repeated analyses of a system's architecture with respect to performance-critical properties through an extendable notation, a tool fram...

Citations

... for a better side-effect towards Development time as its Hurt/-contribution is preferred to the Break/-contribution of Clustering alternative. The selected Primary-backup alternative is subsequently used as a goal to explore two more specific architectural alternatives: Hot standby and Passive standby alternatives (Feiler et al. 2005), where the former is chosen for a better side-effect towards Response time. ...
... If multiple patterns are considered, they may be chosen using a goal-oriented tradeoff analysis similar to that shown in Fig. 5.8. Let us supposed that a hot-standby pattern (Feiler et al. 2005) has been selected for realizing the hot-standby decision. Fig. 5.10 shows the resulting system architecture where two copies of the system (DispatchSystem.1 and DispatchSystem.2) are operational where both simultaneously receive inputs from external entities (CallTaker and ALVS). ...
Chapter
Designing software architectures to meet both functional and non-functional requirements (FRs and NFRs) is difficult as it oftentimes relies on the skill and experience of the architect, and the resulting architectures are rarely derived directly from the requirements models. As a result, the relationships between the two artifacts are not explicitly captured, making it difficult to reason more precisely whether an architecture indeed meets its requirements, and if yes, why. This chapter presents a goal-oriented software architecting approach, where FRs and NFRs are treated as goals to be achieved, which are refined and used to explore achievement alternatives. The chosen alternatives and the goal model are then used to derive, using the provided mapping rules, a logical architecture, which is further mapped to a final concrete architecture by applying an architectural style and architectural patterns chosen based on the NFRs. The approach has been applied in an empirical study based on the 1992 London ambulance dispatch system.
... This allows predicting the effects of particular architectural decisions on the dependability of the system [6]. Other analyses (e.g., related to performance) may be performed on the same AADL model, which allows understanding the tradeoff between the benefits of a certain fault tolerance pattern and its impact on the application's performance [7]. From a practical point of view, the AADL model must be transformed into a stochastic model such as a Markov chain [8] or a Generalized Stochastic Petri net [9], to obtain dependability measures such as reliability, availability, etc. ...
... The reusability of the AADL model is also enhanced by the use of a set of fault tolerance patterns. The hot standby redundancy pattern presented in [7] has been a source of inspiration for the three patterns presented in this paper. The pattern presented in [7] aims at easing the understanding of the functional architecture by clearly showing what is replicated and what the active system components are. ...
... The hot standby redundancy pattern presented in [7] has been a source of inspiration for the three patterns presented in this paper. The pattern presented in [7] aims at easing the understanding of the functional architecture by clearly showing what is replicated and what the active system components are. Our patterns additionally include a customizable layer of dependability-related information (error/failure and recovery behavior) and of dynamics necessary for evaluating dependability measures. ...
Article
Full-text available
Performing dependability evaluation along with other analyses at architectural level allows both making architectural tradeoffs and predicting the effects of architectural decisions on the dependability of an application. This paper gives guidelines for building architectural dependability models for software systems using the AADL (Architecture Analysis and Design Language). It presents reusable modeling patterns for fault-tolerant applications and shows how the presented patterns can be used in the context of a subsystem of a real-life application.
... Integration for mission critical systems [8], Security Level Analysis and Memory/Buffer Analysis [14] on a queueing system, Safety Level and Reliability Analysis [14] using the MetaH tool partitioning analyzer to partially verify the consistency of the safety levels, and Deadline, Priority Check based on Rate-Monotonic Analysis (RMA) [9]. Additional information on constructing an AADL model can be found in [20]. ...
Conference Paper
Fault Tree Analysis (FTA) is a safety-analysis technique that has been extended recently to accommodate product-line engineering. This paper describes a tool-supported approach for integrating product-line FTA with the AADL (Architecture Analysis and Design Language) models and associated AADL Error Models for a product line. The AADL plug-in we have developed provides some automatic pruning and adaptation of the fault tree for a specific product from the product-line FTA. This work supports consistent reuse of the FTA across the systems in the product line and reduces the effort of maintaining traceability between the safety analysis and the architectural models. Incorporating the product-line FTA into the AADL models also allows derivation of basic quantitative and cut set analyses for each product-line member to help identify and eliminate design weaknesses. The tool-supported capabilities enable comparisons among candidate new members to assist in design decisions regarding redundancy, safety features, and the evaluation of alternative designs. Results from a small case study illustrate the approach.
... The AADL core language allows analyzing the impact of different architecture choices (such as scheduling policy or redundancy scheme) on a system's properties [10]. An architecture specification in AADL is an hierarchical collection of interacting components (software and compute platform) combined in subsystems. ...
Article
Full-text available
For efficiency reasons, the software system designers' will is to use an integrated set of methods and tools to describe specifications and designs, and also to perform analyses such as dependability, schedulability and performance. AADL (Architecture Analysis and Design Language) has proved to be efficient for software architecture modeling. In addition, AADL was designed to accommodate several types of analyses. This paper presents an iterative dependency-driven approach for dependability modeling using AADL. It is illustrated on a small example. This approach is part of a complete framework that allows the generation of dependability analysis and evaluation models from AADL models to support the analysis of software and system architectures, in critical application domains.
... However, our tagged language and mechanism will be valuable in parsing and checking XML based models. In addition we would like to integrate this tool into the OSATE toolset-a tool environment for the SAE AADL [1,7,8]. Our Java based model checking tool has the potential to provide service across the Internet in the Service-Oriented Distributing Computing environment [20] for supporting software engineering education and research [14]. ...
... Society of Automotive Engineers standard Architectural Analysis & Design Language-the SAE AADL [1,7,8]. This will involve the development of a normative standard for the syntax and semantics of model checking and CCQ that is consistent with the SAE AADL normative standard. ...
Conference Paper
Full-text available
This paper presents preliminary results in defining templates and a framework for an automation tool for generating temporal logic queries from the expected properties of requirements documents specified in natural Language. Specifically, we first extend the theoretic results published in [16]from Linear Temporal Logic (LTL) to Computation Tree Logic (CTL). Then we present a template to elicit informal queries in a form that can be automatically mapped to either LTL or CTL queries. These efforts are the foundation for the development of a Java-based formal query generation tool that will facilitate the generation of formal queries from informal specifications. The tool will be integrated into the OSATE Eclipse-based analysis and design environment for the Society of Automotive Engineers (SAE) standard---the Architecture Analysis & Design Language (AADL) [1].
... For certain OQAs, the AADL-model-based engineering community has associated analytical frameworks and prototyped implementations (http://www.aadl.info). Two examples are securityand redundancy in support of safety-critical and mission-critical systems[Feiler 2004]. ...
... Similarly, security in the form of confidentiality must validate security properties along end-to-end information flows. OQAs such as reliability or availability lead to the use of both @BULLET the Error Model Annex[SAE 2006]for dependability modeling for stochastic predictions[Feiler 2007b]@BULLET replication patterns to achieve fault tolerance through physical redundancy in computer hardware and logical redundancy in application software[Feiler 2004]Table 63 outlines for each application pattern the intent of the application pattern and the assumptions the pattern makes. Furthermore, the table suggests the most appropriate model representation to capture the application's intent. ...
Article
Nowadays, real-time critical embedded systems are more and more complex due to an increase of the integrated components. Following that trend, avionic systems development complexity increases too. So early modeling processes are more and more used in order to anticipate on plat-forms performance and help sizing them. Particularly, hardware resources usage exploration is a key aspect for performance exploration. Current processes allow to model avionic platform from requirements to architectural level of abstraction, but they do not allow to model a behavioral avionic platform. Thus, they do not allow to explore the hardware resources usage of the platform, neither to compare some alternatives of architectures at early phase of development cycle. My PhD work presents our avionic platform modeling and simulation process that answer that problem. The goal is to complete current modeling processes to offer more accurate early performance analysis, and compare them with the system requirements. For that, we propose a for steps method : i) an application modeling and stimuli extraction step ; ii) an architectural modeling step, based on the AADL (Architecture Analysis and Design Language) and its ARINC653 annex ; iii) a behavioral execution platform model (hardware and middleware) generation step with SystemC-TLM ; iv) a simulation and analysis step, when performance are compared with system requirements. At last, we will present our validation part on an avionic case study.
Article
System engineering practice for the design and development of the embedded computer systems in avionics today is significantly more empirical (experimental) than analytical. The result has been typically expensive problems in the integration and evolution of complex systems, whether the program succeeds or fails. The AADL provides a standards-based way to describe the computer architecture hardware and software components in precise terms allowing early analysis and incremental system construction to predictive models. Multiple domains of engineering analysis can be integrated into a single specification. It can be used to bridge system development phases. This new standard-based capability is foundational for advancing our ability to engineer avionics systems early and throughout the lifecycle across the industry. This paper overviews the history, standard, language, analysis methods, advanced architecture research programs using the AADL, provides large model examples, and includes publicly briefed slides from a NATO study on the rapid integration of weapons onto aircraft platforms that recommended the AADL.
Conference Paper
The Society of Automotive Engineers (SAE) Architecture Analysis & Design Language, AS5506, provides a means for the formal specification of the hardware and software architecture of embedded computer systems and system of systems. It was designed to support a full Model Based Development lifecycle including system specification, analysis, system tuning, integration, and upgrade over the lifecycle. It was designed to support the integration of multiple forms of analyses and to be extensible in a standard way for additional analysis approaches. A system can be automatically integrated from AADL models when fully specified and when source code is provided for the software components. Analysis of large complex systems has been demonstrated in the avionics domain.
Conference Paper
Full-text available
For efficiency and cost control reasons, system designers’ will is to use an integrated set of methods and tools to describe specifications and design, and also to perform dependability analyses. The SAE (Society of Automotive Engineers) AADL (Architecture Analysis and Design Language) has proved to be efficient for architectural modeling. We present a modeling framework allowing the generation of dependability-oriented analytical models from AADL models, to facilitate the evaluation of dependability measures, such as reliability or availability. We propose a stepwise approach for system dependability modeling using AADL. The AADL dependability model is transformed into a GSPN (Generalized Stochastic Petri Net) by applying model transformation rules that can be automated. The resulting GSPN can be processed by existing tools. The modeling approach is illustrated on a subsystem of the French Air Traffic Control System.