Bringing the benefits of safety-certifiable COTS to the system level
StoryFebruary 19, 2018
Rick Hearn
Curtiss-Wright
Avionics integrators and aircraft certification agencies now understand and accept that certifiable commercial off-the-shelf (COTS) assemblies can be designed with a complete set of DO-254 and DO-178B data artifacts that will support system and aircraft certification. The next phase: Defining the advantages of these products on the subsystem level when bringing the cost, time, and risk-lowering benefits of safety-certifiable COTS to avionics system designers.
Today, COTS vendors can deliver a toolbox full of safety-certifiable cards, representing a wide range of functionalities that can be integrated into a rugged chassis. Both traditional COTS and certifiable COTS modules deliver reduced costs because once it’s designed a module can be re-used in many different applications. Traditional COTS modules are typically designed with the latest and greatest semiconductor technology and are intended to be very flexible and adaptable to many different design situations. This COTS model helps speed the deployment of cutting-edge semiconductor devices out to the field, especially for military applications. In contrast, for safety-certifiable COTS designs, the use of newer technologies can be less attractive than long-fielded, well-known devices.
For safety-certifiable COTS boards, component selection is more rigorous because devices need to be selected with an eye to the design assurance level (DAL) requirements of the design and the certifiability of its components. For these reasons, the latest semiconductor technologies are often not selected because they do not meet the criteria for aspects such as service history set out in guidance from international certifying agencies such as FAA [Federal Aviation Administration], EASA [European Aviation Safety Agency], and Transport Canada.
For example, a single-board computer (SBC) based on an older A53 Arm processor architecture is preferable for certifiable applications, when compared to an SBC based on A72 Arm cores, because it has been in use much longer, which eases the collection of data artifacts and service history need for certification. Service history includes all the collected knowledge and experience from a device’s previous use in potentially thousands of diverse applications. If the device has previously been used in avionics applications and has accumulated flight hours, all the better.
Safety-certifiable modules also need to be more rigidly defined in order to minimize and eliminate the presence of any extraneous or unneeded features that might add complexity to the certification process, which would make the management and collection of the already voluminous data artifacts required for certification even more difficult. All functionality must be “locked down,” meaning that any unused hardware functions or software features are discarded or disabled in such a way that they can’t affect the performance or safety of the system itself. The certifiable COTS vendor needs to be able to prove that any disabled hardware function will remain off and can’t be accidentally turned on again. Any unneeded or undesired software features should be completely removed. This safeguard also helps to reduce the number of lines of software code that need to be tested for certifiability. Any additional line of code that doesn’t add value, or isn’t needed for the application, will add an unnecessary burden to the certification process.
While certifiable COTS data artifacts can be reused in subsequent designs to deliver considerable cost savings versus a custom design, they will need to be updated and altered to align with any requirement or feature changes for that given system.
Building blocks
Rugged COTS suppliers are now creating certifiable COTS building blocks – each of which is supported with an existing data artifacts package – to ease and speed the development of safety-critical systems. These building blocks include a compliment of SBCs, avionics I/O cards, and graphics cards, all of which can be coupled with modifiable chassis to develop open architecture designs for airborne platforms. These systems, with the elements pre-integrated and qualified to the appropriate environmental levels, provide an ideal starting point for integrators to add their value in the application itself. Even better, working with a proven design removes the program risk, including cost and time, involved and associated with the development of a new design from the ground up. These certifiable building blocks enable avionics system designers to begin developing application software right away, rather than having to wait for the availability of a custom design.
Single-board computers
The industry is looking for high-performance multicore processors to enable consolidation of old federated systems into integrated modular architectures that can accommodate multiple functions and DALs in partitions. This setup requires not only a multicore processor but also support for multicore enabled operating systems with support for ARINC 653. Selection of the processors is based on their suitability for certification to the appropriate DAL (from A through E) with support from the processor supplier and sufficient service history to be fit for purpose. Typically, power architecture processors have been selected for the higher DALs but Arm-based multicore processors are also expected to occupy this space in the near future. There are still challenges to certification with multicore processors due to shared resources, but guidance from industry and the certification agencies has provided direction to overcome these challenges. Moreover, there are multicore processors in the process of being certified for flight today.
Avionics I/O
A wide variety of legacy input/output standards are used in aircraft today. Typical interfaces include MIL-STD-1553, ARINC 429, CANbus, Ethernet, RS-232, RS-422, RS-485, and analog I/O. There are also some newer, deterministic interfaces being used for interconnects, such as safety-critical Ethernet (ARINC 664), Time Triggered Ethernet (TTE), and Time Triggered Protocol (TTP). The wide variety of interface types in use means that every safety-critical system will likely have a unique set of I/O requirements, making it difficult to define a single chassis-level product able to meet most needs.
High-performance graphics
Graphics cards provide the ability to input/capture and process video from various sources in the aircraft. This video can be compressed for storage or routed for display and overlaid with additional information in order to increase situational awareness. The graphics processor or graphics processor unit (GPU) must be carefully selected for certification according to DO rules. Also, the GPU supplier must have a means to mitigate any hazardously misleading information via hardware or software to address the issues defined in CAST 29 and the EASA certification memo CM-SWCEH-001. What’s more, the GPU’s software drivers must support a certifiable version of OpenGL, namely OpenGL SC 1.0 or 2.0. Other important GPU features for safety critical applications include the ability to compress and decompress video (H.264 and H.265) and display it with very low latency.
Rugged chassis
Rugged safety-certifiable COTS chassis building blocks should be standards-based and feature some provable pedigree with respect to DO-160/MIL-STD-810 environmental testing compliance.
Safety certifiable systems
Using the range of safety-certifiable building blocks described above, system integrators can design a wide range of rugged avionics systems able to satisfy rigorous safety requirements. The following overview provides examples of these types of solutions:
Degraded visual environment system
Degraded visual environment (DVE) systems employ radio frequency (RF) or electro optic (EO) sensing technologies – or combinations of both - using data fusion algorithms to provide the best imaging solution depending on the sensing environment. The DVE system displays a representative indication of height and highlights impediments in poor visibility situations such as brownouts (sand), poor weather or whiteouts (snow). A DVE system would typically have one or more processing elements (SBCs), an I/O card to bring in the data from the various sensors and a graphics card.
Graphics processor
A graphics processor, used to display and process video information, is usually developed with a combination of an SBC and one or more graphics cards, depending on the number of video streams.
Mission computing
A mission computer processes video, sensor, and mission navigation data to provide formatted display outputs. Mission computers improve situational awareness and lighten pilot workloads. A mission computer might feature multiple SBCs, graphics cards, and I/O modules, depending on the sophistication of the system and the number of required inputs and outputs.
Flight control computers
The flight control computer (FCC) computes and transmits all normal mode flight control surface actuator commands. Normally, three FCCs are installed on an aircraft. Each of the FCCs would utilize a SBC to execute the flight control algorithms. A FCC also usually has a large array of inputs and outputs in order to gather sensor data and control the appropriate control surfaces.
Safety certifiable aviation processor example
An aviation processor provides a good example of a safety-critical integrated system design. In this example, the system is initially certifiable to DAL C, with a path to DAL A in the future. Housed in a ½ ATR rugged chassis, the aviation processor system, the Curtiss-Wright VPX3-152 power architecture SBC (Figure 1) uses the quad E6500 core NXP T2080 and is combined with a VPX3-719 graphics card featuring an AMD E8860 GPU. The GPU provides graphics capture, display, and processing. The SBC supports a wide array of avionics I/O such as MIL-STD 1553, ARINC 429, DIO, serial channels, and more.
(Click graphic to zoom)
 |
One of the great advantages that safety-certifiable products deliver to designers of avionics systems is that they can get application development underway quickly. Any modifications, such as the deletion or disablement of unneeded software and hardware features, can be done in parallel without delaying the development process.
Rick Hearn is a product manager at Curtiss-Wright Defense Solutions.
Curtiss-Wright Defense Solutions • www.curtisswrightds.com
Figure 1: The VPX3-152 SBC is designed for use in space-constrained applications.
