In a bid to deliver more performance from individual computer processing units (CPUs), the computer hardware industry is moving away from single-core to multi-core processors, creating serious challenges for all parts of the avionics systems sector — and the FAA’s ability to regulate them.

Transitioning to multicore processors (MCPs) creates all kinds of processing and interference problems that simply didn’t exist with with the SCPs that avionics architectures were originally designed around.

Delays and Interference

The use of multiple processing cores in a single CPU fundamentally changes the architecture of any computer system that employs them. As soon as a CPU has more than one core, resources such as memory that were dedicated to one processor now have to be shared between two or more processors on demand. The result is akin to multiple computers on a network accessing the internet through a shared connection. Time-related delays occur as one user takes bandwidth away from another user.

Then there’s the issue of interference, which can occur when multiple avionics applications are running on a MCP’s cores at the same time.

“Even if there is no explicit data or control flow between these applications, coupling exists on the platform level, which can cause interference between the applications,” the FAA’s Certification Authorities Software Team (CAST) wrote in its position paper, Multicore Processors CAST-32A. A platform property that can cause interference between independent applications is called an interference channel, according to the paper.

Time-related delays caused by resource sharing can be predicted in the avionics system design phase. But interference channels are another kind of animal. Because they can occur between independent applications, interference channels are difficult to predict and may only be found during the testing phase.

For avionics systems designers, the main concern is the large number of possible interference paths caused by multicore configurations, according to Scott Engle, director of business development at Mercury Mission Systems.

“At four CPU cores, one PCI express master IO, two DMAs and two PCIe and 1 controller area network slave IO, there are over 5 million possible interference paths,” Engle said. It is very difficult to write test cases and then understand the results for five million tests. The number of possible interference paths grows quickly to over a billion as you reach eight cores. Until we can automate the testing or work with the silicon manufactures to reduce potential interference, I think we are going to be limited to no more than four cores and use-cases which minimize the possible interference paths.”

Engle believes the limitation to four cores will reduce the effectiveness for the use of multicore CPUs because the designs are based off of software architecture decisions rather than creating the optimal software architecture.

The FAA’s CAST-32A

The FAA’s CAST-32A position paper outlines the agency’s efforts to understand, encapsulate, and take action on issues associated with safely using MCPs in avionics systems.

Among CAST-32A’s concerns:

• The FAA’s documents that regulate the requirements for software existing within airborne systems, DO-178B/ED-12B and DO-178C/ED-12C, were written for SCP avionics systems. They need to be updated for MCPs.
• The time delays caused by MCPs sharing memory can compromise an avionics system’s ability to function properly. These time delay effects can cause increases in the worst-case execution times of the hosted applications.
• The phenomenon of interference channels needs to be examined, understood and remedied to ensure that MCP-based avionics systems perform as required.

CAST-32A’s objectives for addressing MCP issues in avionics systems gets a thumbs-up from Patrick Huyck, Systems Certification Manager at Green Hills Software.

“With CAST-32A, the certification authorities took a new approach that involved industry from the beginning,” Huyck said. “The concerns listed in the document are valid from both perspectives.”

He added that Green Hills Software engineers have personally measured processing delays in MCP-based systems, and discovered they can cause an application to take eight to 12 times longer to execute. Overall, the execution time is dependant on the number of cores contending for the shared memory resources.

As for the response to MCP issues by the avionics makers that Green Hills provides real time operating systems to? Huyck said there are two different perspectives that have emerged. Some manufactures believe multicore inference issues can be circumvented by assigning and scheduling applications on different cores and then allocating an extra-long time slot for processing if interference occurs.

“Others understand how hard the problem is but are still working to find a general solution,” Huyck said. “Green Hills has a solution to multicore interference centered around allocating bandwidth to shared resources on a core-by-core basis, and that allocation is enforced with fine granularity so that high-criticality applications continuously receive their bandwidth allocation.”

A Team Effort

Industry experts interviewed by Avionics agreed that every player in the avionics food chain has to help with safely integrating MCPs into avionics systems. This list includes operating systems makers, middleware vendors, platform suppliers and systems integrators. Some of their efforts can be supported by existing COTS tools, libraries and core software features. Other tools will have to be developed through research and development efforts, including advanced testing procedures to detect interference channels.

Olivier Charrier, aerospace and defense principal engineer at Wind River Systems, believes that platform suppliers play a pivotal role in the MCP investigation process because of the role they play toward integrating the operating system into the embedded processing chain.

“They're putting things together, which is why the platform supplier is one of the best candidates to do that,” Charrier said.

Notwithstanding, it will take the full participation of everyone involved in the avionics system sector to address the issues associated with MCPs. This is not a problem that can be ignored or wished away; the transition of avionics using SCPs to MCPs is inevitable due to trends in the CPU manufacturing industry. At the same time, the issues associated with MCPs should not obscure the fact that their enhanced processing power offers many opportunities to the avionics industry.

“The higher throughput of MCPs enable consolidation of multiple functions in an integrated modular avionics solution, which in turn reduces the size, weight, and power of the system,” said Green Hill’s Huyck. “The increased computing capacity also can provide room for future growth when new requirements or applications are needed. There can also be increases in [mean time between failures] of the solution, resulting from the reduced number of processing boards in the consolidated system.”