Leveraging COTS Solutions for Safety-Critical Avionics Applications



With the proper design and test procedures, commercial off-the-shelf computer and I/O boards can qualify for use in safety-critical systems.

Today’s military and commercial aircraft are, in many ways, flying computers. Those computers must meet stringent safety and performance requirements to ensure the plane stays in the air and reaches its destination. To that end, there are both hardware (DO-254) and software (DO-178C) standards that avionics system and subsystem suppliers must meet. The RTCA DO-254 Standard for Design Assurance Guidance for Airborne Electronic Hardware, which was formally recognized by the Federal Aviation Industry just over a decade ago, provides a means to demonstrate compliance for the design of complex electronic hardware in airborne systems. DO-178C Software Considerations in Airborne Systems and Equipment Certification has become the primary document by which the certification authorities such as the FAA, EASA and Transport Canada approve all commercial software-based aerospace systems.

Figure 1:  Safety-critical COTS solutions can be integrated using computer and I/O boards that have gone through DO-254 certification compliance processes and operating system software qualified through DO-178.

Figure 1: Safety-critical COTS solutions can be integrated using computer and I/O boards that have gone through DO-254 certification compliance processes and operating system software qualified through DO-178.

Historically, especially for military avionics, custom boards were created for each unique application and waivers were often given to the suppliers, since the aircraft did not interact with commercial aircraft or fly in commercial air space. The current demand for safety certifiability on military aircraft is to allow their “unfettered access” to civil airspace.  And, as airspace control continues to evolve and modernize, the tools for communication, navigation, and surveillance/air traffic management necessary for military aircraft to comply with the new airspace control requirements must be certified.

Complexity Increases

Because those boards were custom, suppliers of military systems developed and controlled their own safety evidence. However: the technology landscape in the military sphere has evolved – is evolving – rapidly. The benefits and advantages of commercial off-the-shelf (COTS) hardware and software have become increasingly persuasive. Technology cycles have become dramatically foreshortened, with frequent upgrades from silicon vendors for their highly integrated processors, field-programmable logic, and custom application-specific chips. Time-to-deployment has become a significant factor, as has risk mitigation. Increasing complexity coupled with diminishing lifecycles has made avoiding technology lag a real challenge. The impact of these changes is self-evident when it comes to safety certification: the cost and time to marshal safety evidence are becoming prohibitive.

One of the most significant benefits of COTS computer boards and other subsystems has always been that the principle of COTS shifts many burdens away from systems integrators, OEMs and prime contractors, and on to the shoulders of ‘external’ hardware manufacturers—burdens such as planning for technology insertion and obsolescence mitigation. The costs of these provisions (and, of course, initial development) typically have to be amortized over a single product/program for in-house solutions, whereas COTS vendors can expect to defray these over multiple products/programs—contributing significantly to the greater cost-effectiveness of COTS platforms.

As safety certification became increasingly demanding, it was inevitable that COTS hardware manufacturers would progressively take that load too, with the opportunity to create a win-win: substantially reduced time, effort, and risk for the system integrator, and increased sales for the vendor.

Rigorous Vetting Ensures Validation
For COTS boards to be used in commercial planes as well as military aircraft, those boards must undergo the same rigorous vetting process as custom boards to ensure they will perform their tasks flawlessly, reliably, and with no “surprises”. An unexpected operating state or incorrect execution of a command are just two examples of the form these “surprises” can take that could cause anything from a major accident to minor disruption in the entertainment system.

In the avionics world, DO-254 and DO-178C define five design assurance levels (DAL), which are categorized by examining the effects a failure condition has on the aircraft, crew, and passengers. With DO-254, the FAA has indicated that avionics equipment contains both hardware and software, and each is critical to safe operation of aircraft. The failure categories include:

  • Catastrophic—A failure may cause multiple fatalities, as well as the loss of the aircraft.
  • Hazardous—A failure would have a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.
  • Major—A failure significantly reduces the safety margin or significantly increases crew workload. Additionally, the failure might result in passenger discomfort (or even minor injuries).
  • Minor—A failure that slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight-plan change.
  • No Effect—A failure would have no impact on safety, aircraft operation, or crew workload.

The authorities that provide certification require, and DO-254 and DO-178C specify, that the correct DAL should be established using comprehensive analysis methods to establish the failure condition level A-E. As can be imagined, DAL A is significantly more rigorous than DAL E, with consequent impact in terms of time and cost in achieving it. Any software that commands, controls, and monitors safety-critical aspects in the system requires DAL A certification.

Hardware design and verification of the computer boards must be done independently of each other—whether the hardware is developed in-house on a custom basis, or whether it is developed by a COTS manufacturer. The hardware designer works to ensure the design of the hardware will meet the defined requirements. Meanwhile, in parallel, the verification engineer will generate a verification plan, which will allow for testing the hardware to verify that it meets all of its derived requirements. The planning process is the first step where the design authority (the company developing the hardware and which  implements the COTS into its design) declares its approach towards the certification. At this point the Plan for H/W Aspects of Certification (PHAC) is presented to the authorities (EASA, FAA…). In this plan, the developer presents its approach and how DO-254 is implemented. The PHAC is submitted as part of the authorities’ 1st stage of involvement (SOI#1).

Hardware Development Stages
When designing a board, there are multiple steps that the development team should follow to ensure the product meets all of the safety function requirements allocated from the system. Those steps include:

  • Requirements capture—including derived requirements
  • Requirements validation
  • Conceptual design
  • Detailed design
  • Implementation
  • Verification
  • Transfer to production

At the requirements capture step, product requirements are identified and  those for safety flagged. Derived requirements are created and communicated back to the system level in order to ensure compatibility with higher level functionality. The requirements validation process assures that the hardware’s requirements, including derived requirements, are correct and complete with respect to system safety requirements allocated to the hardware item.

Conceptual design is the blueprint or visualization that allows the anticipated design to be evaluated against the requirements for completeness and suitability. The detailed design step is the creation of the electronic representation of the product, VHDL code, schematics, printed circuit board files, etc. and the implementation is the transformation of these files into the physical board product.

The verification process assures that the hardware’s implementation meets all hardware requirements, including derived requirements and safety requirements. Testing is performed to ensure requirements are met with 100% coverage. The last step is the transfer to production, where the task is to ensure that the manufactured product is exactly that which the design documents describe.

Figure_2

Throughout these development stages, additional tasks are performed in parallel to ensure proper configuration control is established and maintained, plus process assurance oversees that each process step is followed in the correct order and completes successfully per transition criteria established during planning. The appropriate certification authority is also consulted throughout the overall process (i.e. Stage Of Involvement or SOI audits for the FAA) to ensure that compliance is both reviewed and agreed by the certification authority from start to finish.

The challenge for COTS hardware vendors is to lift their process to the stringent level required for these steps. However, the industry has proved highly adaptable in the past, and the context can be bounded by nominating modest subsets of products and processes, which can be expanded as experience grows.

Safety certification is, of course, a function of both hardware and software. Long before a COTS board or subsystem makes it through the DO-254 process for verification, the hardware vendor will typically work closely with the software vendor who will be responsible for the operating system DO-178 artifacts—vendors such as Wind River (VxWorks653), DDC-I (DEOS), or Lynx Software Technologies (LynxOS-178). This would typically see the hardware vendor sharing information about the Board Support Package (BSP) that acts as the interface between the board and the operating system. The sum total of the hardware and software artifacts enables qualification of the entire system for manned or unmanned flight systems (Figure 1).

Much as COTS suppliers have assumed responsibility for their hardware throughout the lifetime of a program, they are now creating a portfolio of certification-compliant products such that their customers can quickly assemble systems that can readily be certified in the target airframe—since most of the subsystem hardware is already certification-compliant. For example, at Abaco, the company is creating a safety certifiable portfolio including mission ready subsystems as well as board offerings (single board computers, graphics, and I/O boards).

Abaco’s FORCE2, for example,  is a complete, pre-integrated, mission ready subsystem that provides a roadmap not just to DO-254 certification compliance, but also in support of application design assurance level needs right up to DAL A. Abaco is making a substantial investment in the development and  delivery of the supporting artifacts necessary to achieve safety certifiability so that customers don’t have to—minimizing both the cost and lead-time, with consequent positive impact upon when a platform can expect to be deployed.

Summary
The safety-critical world continues to evolve. For example: the SBC314 single board computer offered with a roadmap to safety certifiability by Abaco, is available with variants up to eight virtual plus physical cores. However, virtual cores cannot be used under current certifiability rules. What’s more, how many physical cores can be used at a particular DAL has been a topic of intense discussion over the last couple of years. A significant challenge for future systems is FAA approval of the latest multicore processors that offer significant performance improvements over current solutions. Projects are under way to get the higher core count processors qualified but, for now, designers have to use less capability than would otherwise be possible, or with capability disabled in an approved manner. As an ultimate backstop, for instance, the SBC314 can be operated in single-core mode. The Certification Authority Software team has created the CAST 32 document which harmonizes the FAA/EASA safety requirements for multicore processors.

The increasing costs and technology lag of deriving ground-up custom in-house designs for safety critical computer equipment are driving OEMs serving this area to reach out to COTS vendors more than ever before. Still greater impetus will be provided by the expected FAA/EASA approval of multi-core platforms (also with COTS operating system support from multiple vendors) in the near future.

As it has historically done, the COTS embedded computing industry—including companies such as Abaco—has risen to the cost, risk, and time challenges that OEMs, systems integrators and prime contractors find themselves facing. Their safety certifiable offerings clearly illustrate this and a willingness to share those challenges in exchange for program rewards.


This article is sponsored by Abaco.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: