Architecture description languages such as AADL allow systems engineers to specify the structure of system architectures and perform several analyses over them, including schedulability, resource analysis, and information flow. In addition, they permit system-level requirements to be specified and analyzed early in the development process of airborne and ground-based systems. These tools can also be used to perform safety analysis based on the system architecture and initial functional decomposition. Using AADL-based system architecture modeling and analysis tools as an exemplar, we extend existing analysis methods to support system safety objectives of ARP4754A and ARP4761. This includes extensions to existing modeling languages to better describe failure conditions, interactions, and mitigations, and improvements to compositional reasoning approaches focused on the specific needs of system safety analysis. We develop example systems based on the Wheel Braking System in SAE AIR6110 to evaluate the effectiveness and practicality of our approach.

A graph G with q edges is said to be harmonious if there is an injection f  from the vertices of G to the group of integers modulo q such that when each edge xy is assigned the label f (x) + f (y) (mod q), the resulting edge labels are distinct. If G is a tree, exactly one label may be used on two vertices. Over the years, many variations of harmonious labelings have been introduced.
We study a variant of harmonious labeling. A function f  is said to be a properly even harmonious labeling of a graph G with q edges if f is an injection from the vertices of G to the integers from 0 to 2 (q-1) and the induced function f*  from the edges of G to 0 to 0,2,…,2 (q-1) defined by f* (xy) = f (x) + f (y) (mod2q) is bijective. This paper focuses on the existence of properly even harmonious labelings of the disjoint union of cycles and stars, unions of cycles with paths, unions of squares of paths, and unions of paths.

This annex is intended to help component vendors and system integrators using the (Future Airborne Capability Environment) FACE Technical Standard. FACE Technical Standard Edition 3.0 provides a data modeling architecture but does not provide mechanisms for describing component behavior or timing properties. This document provides guidance for translating a FACE Standard Edition 3.0 Data Architecture XMI model into AADL so that behavior and timing properties can be added and analyzed.

This annex supports the modeling, analysis, and integration of FACE artifacts in AADL. It gives AADL style guidelines and an AADL property set to provide a common approach to using AADL to express architectures that include FACE components. Using common properties and component representations in AADL makes AADL models of FACE components portable and reusable and increases the utility of tools that operate on such AADL models.

Model-based development tools are increasingly being used for system-level development of safety-critical systems. Architectural and behavioral models provide important information that can be leveraged to improve the system safety analysis process. Model-based design artifacts produced in early stage development activities can be used to perform system safety analysis, reducing costs, and providing accurate results throughout the system life-cycle. In this paper we describe an extension to the Architecture Analysis and Design Language(AADL) that supports modeling of system behavior under failure conditions. This Safety Annex enables the independent modeling of component failures and allows safety engineers to weave various types of fault behavior into the nominal system model. The accompanying tool support uses model checking to propagate errors from their source to their effect on top-level safety properties without the need to add separate propagation specifications. Our tools are also able to compute minimal cutsets for these errors to produce faults trees familiar to safety engineers and certification authorities. We describe the Safety Annex, illustrate its use with a representative example, and discuss and demonstrate the tool support enabling an analyst to investigate the system behavior under failure conditions.

Challenging problems associated with system software complexity growth are threatening industry’s ability to build next generation safety- and security-critical embedded cyber physical weapon systems including vertical lift avionics systems. Contributors to these problems include the growth of software enabled capabilities, interaction complexity in system integration, and ambiguous, missing, incomplete, and inconsistent requirements. Problems continue to hamper systems in the areas of resource utilization, timing and scheduling, concurrency and distribution, and safety and security. A new approach called Architecture Centric Virtual Integration Process (ACVIP), based on the SAE International® Aerospace Standard AS5506C Architecture Analysis and Design Language (AADL), is being developed and investigated by the United States (US) Army to address these challenges. ACVIP is a compositional, quantitative, architecture-centric, model-based approach enabling virtual integration analysis in the early phases and throughout the lifecycle to detect and remove defects that currently are not found until software, hardware, and systems integration and acceptance testing. The Science & Technology (S&T) program called Joint Multi-Role (JMR) Technology Demonstrator (TD) with the Mission System Architecture Demonstration effort is developing, piloting, evaluating and maturing Modular Open Systems Approach (MOSA), a Comprehensive Architecture Strategy (CAS), and Model Based Engineering (MBE) including ACVIP through a number of projects with contractor teams to prepare for the Future Vertical Lift (FVL) family-of-systems. ACVIP plays a key role in addressing issues in cyber-physical systems (CPS) and can be a key contributor to the US Department of Defense (DoD) Digital Engineering Strategy. It provides a well-defined standard as a foundation for a commercial tool marketplace, a ready base for ongoing efforts in maturation and commercialization of the technology, provides early demonstrations of success, and a unique architectural contribution to authoritative source of truth (ASoT). We will first discuss the challenges in CPS development and the contribution ACVIP makes to address these challenges. We then outline how ACVIP is a key component that contributes to all five goals of the DoD Digital Engineering Strategy.