Allied Standards Avionics Architecture Council

Last updated

Allied Standards Avionics Architecture Council, or ASAAC, is an effort to define and validate a set of Open Architecture Standards for Avionics Architecture, particularly in the field of Integrated Modular Avionics.

Contents

ASAAC is managed by the UK Ministry of Defence, and many major European Avionics companies participate in the Working group, such as:

History

The Allied Standard Avionics Architecture Council (ASAAC) was established by the Air Senior National Representatives of France, Germany, the United Kingdom and the United States of America with the intention of reducing procurement and support costs and improving technical and operational interoperability between NATO aircraft and aircraft weapons subsystems. [1]

ASAAC Phase I: (Sept-92 to Feb-94)

This part of the programme was a feasibility study researching the possibilities of a Core Avionics Architecture Concept. It defined the main objectives of: Inter-changeability, Re-usability, Portability, Technology Transparency, Fault Tolerance, Extendability [sic], Maintainability[,] etc.

It also identified the concepts of the:

ASAAC Phase II: (Nov-97 to Sept-03)

The ASAAC Phase II programme was sponsored by the Ministries of Defence of France, Germany, and the UK through a Memorandum of Understanding (MOU). The French SPAé was the executive agency for the ASAAC programme and the Prime Contract was let to Dassault Thomson Avionique Modulaire (DTAM), a GIE type organisation under French company law formed on a 50-50 basis by Dassault and Thomson. The main aeronautic and electronics companies of France, Germany, and the UK took part in the ASAAC programme as sub-contractors of the DTAM GIE. The UK and German teams were the Industrial Avionics Working Group (IAWG), comprising GEC-Marconi, British Aerospace, and Smiths Industries Aerospace and Defense Systems; and the DASA ESG ASAAC Team (DEAT), comprising Daimler-Benz Aerospace Airbus and ESG Elektroniksystem-und Logistik-GmbH. Both teams had co-prime participant status in the programme with the DTAM. The contract was let on 18 November 1997. [2]

ASAAC Phase II - Stage 1: (Nov-97 to May-99)

This was purely a paper based part of the programme in which the ASAAC Standards and Concepts were defined and documented in a series of reports.

ASAAC Phase II – Stage 2: (Dec-99 to Sept-03)

This was the part of the programme where the concepts and standards defined in Phase II – Stage 1 were validated through a series of demonstrations using ASAAC standard software and hardware.

Standard

The current ASAAC standard has two parts:

ASAAC initially published provisional standards in five parts in January 2005:

All but Def Stan 00-74 were withdrawn in July 2007, the MOD and representatives from the Working group considering that it was the only standard bearing any influence.

Proposed Standards for Software (Def Stan 00-74)

Def Stan 00-74 is defined in the context of Integrated Modular Avionics. Software components are located on modules. [5]

The field covered by ASAAC in Def Stan 00-74 is similar to ARINC 653 (ARINC 653 is a software specification for space and time partitioning in avionics). However, there are differences between the two standards: [5] Some features of ASAAC API, such as file handling, thread managing inside process, or debugging, are not considered in ARINC 653.

However, for the part where the two standards overlap, it is often possible to translate ASAAC interfaces in ARINC 653 API calls (and even in POSIX calls). [5] Approximately 30% of the ASAAC API is covered directly by ARINC 653 and POSIX. [6]

For example, the following call defined in ASAAC: 

 receiveBuffer

would be translated in ARINC 653 by:

 RECEIVE_BUFFER()

and also in POSIX by:

 recv()

STANAG 4626 is a NATO standardization of the requirements defined by the ASAAC program, proposed by the MOD and the ASAAC Working group.

See also

Related Research Articles

Avionics Electronic systems used on aircraft, artificial satellites, and spacecraft

Avionics are the electronic systems used on aircraft, artificial satellites, and spacecraft. Avionic systems include communications, navigation, the display and management of multiple systems, and the hundreds of systems that are fitted to aircraft to perform individual functions. These can be as simple as a searchlight for a police helicopter or as complicated as the tactical system for an airborne early warning platform.

In NATO, a Standardization Agreement defines processes, procedures, terms, and conditions for common military or technical procedures or equipment between the member countries of the alliance. Each NATO state ratifies a STANAG and implements it within their own military. The purpose is to provide common operational and administrative procedures and logistics, so one member nation's military may use the stores and support of another member's military. STANAGs also form the basis for technical interoperability between a wide variety of communication and information systems (CIS) essential for NATO and Allied operations. The Allied Data Publication 34 (ADatP-34) NATO Interoperability Standards and Profiles which is covered by STANAG 5524, maintains a catalogue of relevant information and communication technology standards.

Aeronautical Radio, Incorporated (ARINC), established in 1929, was a major provider of transport communications and systems engineering solutions for eight industries: aviation, airports, defense, government, healthcare, networks, security, and transportation. ARINC had installed computer data networks in police cars and railroad cars and also maintains the standards for line-replaceable units.

Linux kernel interfaces An overview and comparison of the Linux kernal APIs and ABIs.

The Linux kernel provides several interfaces to user-space applications that are used for different purposes and that have different properties by design. There are two types of application programming interface (API) in the Linux kernel that are not to be confused: the "kernel–user space" API and the "kernel internal" API.

The Architecture Analysis & Design Language (AADL) is an architecture description language standardized by SAE. AADL was first developed in the field of avionics, and was known formerly as the Avionics Architecture Description Language.

Avionics Full-Duplex Switched Ethernet (AFDX), also ARINC 664, is a data network, patented by international aircraft manufacturer Airbus, for safety-critical applications that utilizes dedicated bandwidth while providing deterministic quality of service (QoS). AFDX is a worldwide registered trademark by Airbus. The AFDX data network is based on Ethernet technology using commercial off-the-shelf (COTS) components. The AFDX data network is a specific implementation of ARINC Specification 664 Part 7, a profiled version of an IEEE 802.3 network per parts 1 & 2, which defines how commercial off-the-shelf networking components will be used for future generation Aircraft Data Networks (ADN). The six primary aspects of an AFDX data network include full duplex, redundancy, determinism, high speed performance, switched and profiled network.

ARINC 661 is a standard which aims to normalize the definition of a Cockpit Display System (CDS), and the communication between the CDS and User Applications (UA) which manage aircraft avionics functions. The GUI definition is completely defined in binary Definition Files (DF).

PikeOS Real-time operating system

PikeOS is a commercial, hard real-time operating system (RTOS) that offers a separation kernel based hypervisor with multiple logical partition types for many other operating systems (OS), each called a GuestOS, and applications. It enables users to build certifiable smart devices for the Internet of things (IoT) according to the high quality, safety and security standards of different industries. For safety and security critical real-time applications on controller-based systems without memory management unit (MMU) but with memory protection unit (MPU) PikeOS for MPU is available.

Integrated modular avionics (IMA) are real-time computer network airborne systems. This network consists of a number of computing modules capable of supporting numerous applications of differing criticality levels.

Lynx Software Technologies, Inc. is a San Jose, California software company founded in 1988. Lynx specializes in secure virtualization and open, reliable, certifiable real-time operating systems (RTOSes). Originally known as Lynx Real-Time Systems, the company changed its name to LynuxWorks in 2000 after acquiring, and merging with, ISDCorp, an embedded systems company with a strong Linux background. In May 2014, the company changed its name to Lynx Software Technologies.

ARINC 653 is a software specification for space and time partitioning in safety-critical avionics real-time operating systems (RTOS). It allows the hosting of multiple applications of different software levels on the same hardware in the context of an Integrated Modular Avionics architecture.

SYSGO GmbH is a German information technologies company that supplies operating systems and services for embedded systems with high safety and security-related requirements, using Linux. For security-critical applications, the company offers the Hypervisor and RTOS PikeOS, an operating system for multicore processors and the foundation for intelligent devices in the Internet of Things (IoT).

IAI Nammer

The IAI Nammer was a fighter aircraft developed in the Israeli aerospace manufacturing Israel Aerospace Industries (IAI) during the late 1980s and early 1990s. The programme was pursued as a private venture and the resultant aircraft was intended for the export market.

STANAG 4626 is a NATO Standardization Agreement which define a set of Open Architecture Standards for Avionics Architecture, particularly in the field of Integrated Modular Avionics. The purpose of this standard is to establish uniform requirements for the architecture for Integrated Modular Avionics (IMA) systems as defined by the ASAAC program. A reference implementation is on SourceForge under an Apache license.

LynxSecure is a least privilege real-time separation kernel hypervisor from Lynx Software Technologies designed for safety and security critical applications found in military, avionic, industrial, and automotive markets.

Open-system environment reference model

Open-system environment (OSE) reference model (RM) or OSE reference model (OSE/RM) is a 1990 reference model for enterprise architecture. It provides a framework for describing open system concepts and defining a lexicon of terms, that can be agreed upon generally by all interested parties.

XtratuM Hypervisor

XtratuM is a bare-metal hypervisor specially designed for embedded real-time systems available for the instruction sets LEON2/3/4 and ARM v7 processors.

An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation.

STANAG 3910High Speed Data Transmission Under STANAG 3838 or Fibre Optic Equivalent Control is a protocol defined in a NATO Standardization Agreement for the transfer of data, principally intended for use in avionic systems. STANAG 3910 allows a 1 Mb/s STANAG 3838 / MIL-STD-1553B / MoD Def Stan 00-18 Pt 2 (3838/1553B) data bus to be augmented with a 20 Mb/s high-speed (HS) bus, which is referred to in the standard as the HS channel: the 3838/1553B bus in an implementation of STANAG 3910 is then referred to as the low-speed (LS) channel. Either or both channels may be multiply redundant, and may use either electrical or optical media. Where the channels use redundant media, these are individually referred to as buses by the standard.

European Component Oriented Architecture (ECOA) is an open specification for a software framework for mission system software comprising components that are both real-time and service-oriented.

References

  1. ↑ R. A. Edwards, "ASAAC Phase I Harmonized Concept Summary", 1994 Avionics Conference and Exhibition Systems integration - is the sky the limit? Conference proceedings, ERA Report 94-0973, ERA Technology Ltd., August 1995, ISBN   0 7008 0587 7.
  2. ↑ "Architecture Analysis and Design Language (AADL)" (PDF). aadl.sei.cmu.edu. Retrieved 28 January 2015.
  3. ↑ "ASAAC Standards Part 1: Standards for Software" (PDF). Ministry of Defence (United Kingdom). 19 December 2008. Archived from the original (PDF) on 6 April 2010. Retrieved 7 March 2009.
  4. ↑ "ASAAC Standards Part 2: Rationale Report for Software Standards" (PDF). Ministry of Defence (United Kingdom). 19 December 2008. Archived from the original (PDF) on 4 April 2010. Retrieved 7 March 2009.
  5. 1 2 3 "Flexibility and Manageability of IMS Projects" (PDF). University of York . Retrieved 27 July 2008.
  6. ↑ "An Overview of the ASAAC Standards". assonline.co.uk. Retrieved 2 August 2008.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.