Defense Resource Center
Future Airborne Capability Environment - FACE
Military airborne platforms have traditionally been developed with reference to using a variety of specialized, defence-orientated standards.
The Open Group Future Airborne Capability Environment (FACE consortium) has defined an open avionics environment for US military airborne platform types. Software development of FACE conformant applications demands knowledge of the FACE reference architecture, the definition of FACE components, the adoption of FACE conformant operating systems, and how the FACE technical standard in general embraces the adoption of open systems.
The FACE architectural approach reflects a significant shift in the way that military real time critical systems are constructed across the world which has also seen the widespread adoption of open standards, and demands for safety certification in accordance with such as DO-254 & DO-178C from the world of civil aviation. Similarly, the rise of connectivity across the digital battlefield has also seen the adoption of the aerospace security network and DO-326A across both sectors.
An introduction to FACE
Learn about the Open Group Future Airborne Capability Environment (FACE consortium) initiative
Civil functional safety standards in a military context
Why functional safety standards including DO-178C and ISO 26262 are finding favor in military applications, and how they are being applied
The aerospace security framework and DO-326A
As the demand for connectivity increases, cybersecurity has become a primary challenge in aerospace system development and certification. Read about the Aerospace Security Framework designed to address it, including the DO-326A standard.
Digital battlefield: The final frontier?
The “Digital Battlefield” has emerge as the primary mechanism for real-time situational awareness, becoming a "force multiplier" by embodying technologies that make other resources more effective. Learn why security considerations are vitally important.
Compliance consultancy: You’re not alone
The complexity of the standard(s) and the overheads implied by that complexity can seem breathtakingly onerous. Even more experienced practitioners can be haunted by challenges faced in past projects, and question how they can learn from them to make future projects more cost and time effective.
Could you use a helping hand?
An introduction to FACE
Learn about the Future Airborne Capability Environment (FACE)
Civil functional safety standards in a military context
Why they are finding favour, and how they are being applied
The aerospace security framework and DO-326A
Because functional safety is not the only concern
Digital battlefield: The final frontier?
The key role of connectivity and its security in future warfare
Compliance consultancy: You’re not alone
Could you use a helping hand?
Military avionics organizations have traditionally developed hardware and software using a variety of specialized, defense-orientated standards.
The Future Airborne Capability Environment (FACE) initiative and the widespread adoption of the DO-254 & DO-178C standards reflect a change in that positioning
And the rise of connectivity across the digital battlefield has meant that security has risen to prominence.
DO-178C: The evolution of a standard
DO-178C: The evolution of a standard
DO-178C represents the latest thinking in the design, development, validation, and verification of commercial software-based aerospace systems, and it is adopted widely for military applications too.
Here you can learn on the thinking that gave rise to the standard, and how it evolved from its DO-178B predecessor.
DO-178C is the primary document by which the certification authorities approve all commercial software-based aerospace systems, and increasingly it is adopted for military ones too.
There are heavy demands on developers of these systems especially at the more onerous DO-178C Design Assurance Levels (DALs).
The overhead inherent in the avionics software life cycle from software requirements, through software design, source code development and the application of coding standards, code coverage, low level (unit) testing, and integration testing can seem insatiable.
DO-178C: An overview
This document provides an overview of what is involved in the development of a DO-178C compliant software application from software requirements, through software design, source code development and the application of coding standards, coverage analysis, and software testing - including requirements traceability to each of these phases.
DO-178C embraces a host of concepts and practices that can be daunting for newcomers, and challenging even for experienced practitioners
DO-178C: The evolution of a standard
Reflecting on the thinking that gave rise to DO-178C, and how it built upon its successful DO-178B predecessor.
DO-178C: An overview
An overview of what is involved in the development of a DO-178C compliant software application
Automating requirements traceability and objective tracking
ALM and PLM tools provide facilities for the careful management and monitoring of all aspects of software development for avionics systems, but rely on manual intervention to collate information on code development, verification and validation. Bidirectional requirements traceability is a key characteristic of any compliant DO-178C project. It is easily maintained when things are going according to plan, but much more difficult when something changes - perhaps through a changed customer requirement, or a failed test. It then becomes much more of a challenge to identify where regression testing is necessary, and to ensure that it is completed. Learn how that project management pain point can be soothed by integrating your testing tool suite with your ALM tool of choice.
Automating requirements traceability and objective tracking
ALM and PLM tools provide facilities for the careful management and monitoring of all aspects of software development, but rely on manual intervention to collate information on code development, verification and validation.
Learn how that process can be automated using your ALM tool of choice.
Coding standards
(or “language subsets”)
Code quality presents an ever increasing risk factor as the number of lines of code in avionics applications continue to rise almost exponentially. Coding standards aim to improve the portability, safety and security aspects of a program by restricting those aspects of the language most likely to cause problems. Different standards aim to achieve different things. Both C and C++ are general purpose languages, and neither is always well specified leading to unexpected behavior in some circumstances. Both are therefore prime candidates for the use of coding standards.
MISRA standards are focused on new build critical C and C++ systems, whether they are safety- or security-critical.
CERT standards are specifically concerned with security, and are recommended for both new build and retrospective application.
Ada is a more purposed designed language for critical embedded applications and hence presents fewer "gotchas" for the unwary, but it too can benefit from the prudent application of coding standards.
Getting to grips
with MISRA C:2012
An introduction to the MISRA C standard which was designed for all critical applications - including critical military systems.
Being compliant with MISRA C/C++
This video gives a practical overview of what is required to develop an application that is compliant with MISRA, as defined by the MISRA Compliance:2020.
MISRA C++ in context
This video shows the application of the MISRA C++:2008 standard in the context of a functionally safe application as typified by software based aerospace systems.
Static analysis of Ada
95 source code
This video shows how coding standards can be applied to Ada95 source code as part of an automated code review process.
Addressing your insecurities
with CERT C
An introduction to the CERT C coding standard and a demonstration of how automated test tools can help to achieve its objectives.
Data coupling and control coupling
DO-178C Section 6.4.4 “Test coverage analysis” part D requires that “Test coverage of software structure, both data coupling and control coupling, is achieved.”
According to DO-178C, data coupling is defined as "The dependence of a software component on data not exclusively under the control of that software component" and control coupling is defined as "The manner or degree by which one software component influences the execution of another software component". It's easy to see why they matter, but less obvious how they can be quantified. These documents are designed to help.
Meet data coupling and control coupling
An introduction to the theories and practicalities associated with data coupling and control coupling.
The technicalities of data coupling and control coupling
A deep-dive into the technical details of data coupling and control coupling.
Structural coverage
Source code structural coverage data can be collated during low-level (unit) testing, integration test, and system test. Learn how it provides a basis for the measurement of requirements-based test effectiveness, and how it fits into the broader context of critical software development.
Object code verification (OCV)
According to DO-178C paragraph 6.4.4.2b, "...if the software level is A and a compiler, linker or other means generates additional code that is not directly traceable to Source Code statements, then additional verification should be performed to establish the correctness of such generated code sequences". Object code verification represents the only reliable mechanism to properly fulfill those DAL A requirements.
Here’s why.
DO-33X supplements for DO-178C
DO-33X supplements for DO-178C were created as a way to embrace new technologies and new methods of certification that go beyond the guidance of DO-178C, while Advisory Circulars (AC) are a type of publication offered by the Federal Aviation Administration (FAA) to provide guidance for compliance with these and other standards and rules.
DO-330 replaces the software tool qualification guidance of DO-178B/ED-12B, and enables and encourages the use of this “mature” guidance outside the airborne domain.
DO-331 and DO-332 provide guidance on the use of Model-Based Technologies and Object-Oriented Technologies respectively, in the context of a DO-178C certification. Each provides guidance on use of these technologies in conjunction with DO-178C, and recommends that certain activities and objectives of DO-178C are modified or added to accommodate them.
AC 20-148 describes a mechanism designed for developers to gain full or partial credit for the reuse of a software component in follow-on systems and certification projects, and hence reduce the overhead of certification.
Customer Stories
“LDRA was the only company able to support our automatically generated code out-of-the-box”
“The ability to automate the unit testing process … is very important for Chinese customers”
“Datel made a number of significant achievements in this safety-critical avionics upgrade project”
“LDRA tools automate the part of software engineering that everyone hates — the mundane, repetitive verification tasks”
LDRA Is Here To Help
For more than 40 years, LDRA has developed and driven the market for software that automates code analysis and software testing for safety-, mission-, security-, and business-critical markets. Working with clients to achieve early error identification and elimination, and full compliance with industry standards, LDRA traces requirements through static and dynamic analysis to unit testing and verification for a wide variety of hardware and software platforms. Boasting a worldwide presence, LDRA has headquarters in the United Kingdom, United States, Germany, and India coupled with an extensive distributor network. For more information on the LDRA tool suite, please visit www.ldra.com.
Our Customers
ISO 9001 | TÜV Certification
The TÜV and ISO certificates each say something a little different about LDRA and its products. ISO 9001 certification demonstrates LDRA’s ability to consistently meet and exceed customer expectations. And TÜV approval of software test tools suggests something more specific about the capabilities of the products, and their capacity to meet the exacting demands of the world’s predominant functional safety standards.
LDRA © 2024. All Rights Reserved Privacy Policy Cookie Policy