Transport Canada issued a Technical Standard Order (TSO) authorization for the PU-3000 in March, making it the first avionics computer to use multicore processors certified to design assurance level (DAL) A, the highest level of assurance requirements imposed by civil aviation authorities for hardware and software on computers that perform life-saving communications, navigation, and surveillance functionality on an aircraft.
Embedded systems suppliers and avionics manufacturers have been working toward achieving such a safety-critical milestone for many years, as the majority of in-service avionics systems rely on single-core processors. While it can be used to host a range of applications from primary flight displays to flight management systems in one box, the TSO-approved PU-3000 as a flight director under TSO-C198 “Automatic Flight Guidance and Control System (AFGCS) Equipment," according to a March 17 press release.
CMC Electronics developed the PU-3000 using the Green Hills INTEGRITY-178 Time-Variant Unified Multi-Processing (tuMP) real-time operating system (RTOS). L3Harris has become the first customer for the new computer, as a flight director system to replace legacy technology on an undisclosed older Part 25 jet.
Kerry Doherty, Director of Strategic Technology, CMC Electronics told Aviation Today through emailed statements that the Montreal-based manufacturer first started exploring the development of new avionics computers based on a multicore system on chips (SOCs) as far back as 2012. He also explained how PU-3000 could eventually be used to enable artificial intelligence and machine learning applications for avionics.
"CMC considers this first multicore TSO as a means to gain experience in dealing with interference concerns and to expose the technology used to the certification authorities," Doherty said.
Computing performance expansion enabled by multicore processors is the result of linking multiple central processing unit (CPU) cores that share the tasks necessary to run an application into a single unit. This allows for the sharing of tasks and resources such as cache memory that would usually be separated out among multiple computers, to be run using the multiple cores of the singular processing unit.
Interference challenges arise when multiple processing cores are used to develop a computer system because it changes the way the system shares resources such as memory or code on an on-demand basis. Running multiple avionics applications on a multicore processor simultaneously can generate interference channels between the applications as they run independently.
Doherty said CMC overcame the interference challenges by using a layered services-oriented design for PU-3000. Providing compliance evidence to the CAST-32A guidance required a detailed interference analysis of all the interference channels present in the system, according to a description of the certification process provided by Doherty.
"Because this would be CMC’s first multicore certification project, CMC decided early on that our first step would be to run our Platform Services across multiple cores. This allows CMC to fully control interference patterns within the Platform Services. The integration runs the INTEGRITY-178 tuMP RTOS and some of CMC’s IAP-7000 Platform Services, such as Health Monitoring, across multiple cores. This step allowed CMC to demonstrate compliance to the CAST-32A guidance," Doherty said.
The 2016 CAST-32A position paper remains the internationally accepted certification criteria for integrating multicore processors into avionics systems and served an integral role in the PU-3000's TSO. The system is designed using several layered services, starting with the Board Support Package, the INTEGRITY-178 tuMP RTOS, Green Hills Layered Products (including the PJFS-178 DAL A File System and ARINC 615A Data Loader), and CMC developed IAP-7000 Platform Services and Drivers.
The FAA’s Certification Authorities Software Team (CAST) notes in its position paper, Multicore Processors CAST-32A, that 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. A platform property that can cause interference between independent applications is called an interference channel," according to the paper.
"When it comes to example applications like a primary flight display or navigation display when analyzing a system to deploy on a multicore platform, we must consider the resource needs and resource sharing that will take place in the final integration. A number of applications may be at different DO-178C DAL levels. For example, the PFD is DAL A, while FDS and RMS are DAL B. These applications also rely on a number of common services to perform their tasks, such as Graphics Rendering Services, which would cause significant interference due to this shared resource,” Doherty said.