Allied Standards Avionics Architecture Council
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.
ASAAC is managed by the UK Ministry of Defence, and many major European Avionics companies participate in the Working group, such as:
- BAE Systems
- GE Aviation Systems (formerly Smiths Aerospace)
- Dassault Aviation
- Thales Group
- EADS
- ESG Elektroniksystem- und Logistik-GmbH
- General Dynamics (UK branch)
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:
- Three Layer Software Model [Three Layer Stack]
- System Blueprints
ASAAC Phase II: (Nov-97 to Sept-03)
The ASAAC Phase II programme was sponsored by the Ministry of Defence's 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 the 18th 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:
- Def Stan 00-74:[3] ASAAC Standards Part 1: Standards for Software
- Def Stan 00-74:[4] ASAAC Standards Part 2: Rationale Report for Software Standards
ASAAC initially published provisional standards in five parts in January 2005:
- Def Stan 00-74: Proposed Standards for Software
- Def Stan 00-75: Proposed Standards for Communications/Networks
- Def Stan 00-76: Proposed Standards for Common Functional Modules
- Def Stan 00-77: Proposed Standards for Packaging
- Def Stan 00-78: Proposed Standards for Architecture
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]
- Configuration and initialization: The configuration is considered as defined in a series of blueprints describing thread and process allocation, virtual communication channels... However, the standard does not define precisely the grammar or the language of these blueprints. As for initialization, there is no specific API to allow initialization by the low-level Real-time operating system (RTOS) services.
- Access to Data is abstracted from its actual physical storage.
Links to ARINC 653 and POSIX
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()
Links to STANAG 4626
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
References
- ↑ 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.
- ↑ http://aadl.sei.cmu.edu/aadlinfosite/LinkedDocuments/ASAAC_SAESep1999.pdf. Retrieved 2015-01-28
- ↑ "ASAAC Standards Part 1: Standards for Software" (PDF). Ministry of Defence (United Kingdom). 2008-12-19. Retrieved 2009-03-07.
- ↑ "ASAAC Standards Part 2: Rationale Report for Software Standards" (PDF). Ministry of Defence (United Kingdom). 2008-12-19. Retrieved 2009-03-07.
- 1 2 3 "Flexibility and Manageability of IMS Projects" (PDF). University of York. Retrieved 2008-07-27.
- ↑ "An Overview of the ASAAC Standards". assonline.co.uk. Retrieved 2008-08-02.