Abstract
Single-core processor architectures which are widely-used in safety-critical avionics applications are now becoming scarce due to the migration of semi-conductor manufacturers to multi-core processor architectures. In this article, the suitability of commercial-off-the-shelf (COTS) multi-core processor architectures for safety-critical avionics applications will be considered, and the challenges of undertaking avionics safety-certification will be discussed.
Fig: ARINC 653 compliant OS architecture
The Challenge of Multi-core Processor Selection
Over the last decade, in order to meet the demands of ever increasing performance from the commercial market, and faced with the fundamental performance limit which could be achieved on a single-core processor due to clock speed ceiling, semi-conductor manufacturers transitioned to multi-core processor architectures to achieve performance gains.
The introduction of multi-core processor architectures has provided performance gains for enterprise general purpose applications; it has also presented some unique challenges for their use in safety-critical avionics systems. This is because avionics applications have specific requirements, including (but not limited to) application isolation and determinism, and these are not the primary considerations of semiconductor manufacturers when designing multi-core processors for the commercial market.
The avionics industry, academia and certification authorities have research projects into the use of multi-core processor architectures in avionics applications. A number of researchers have found that there is variation between multi-core processor designs in terms of their suitability for use in avionics applications, due to the impact of architectural design features on application isolation and determinism [1]. These relate to factors arising from shared resources on the device, which include use of a single memory controller or shared bus is used by multiple cores (providing a risk of resource contention), and similarly use of separate or shared Level 2 caches per core.
This uncertainty about the selection of multi-core processors for avionics programmes, has been compounded by the following factors:
i) Although the avionics safety certification agencies EASA and FAA have published the MULCORS research report and the CAST-32 position paper respectively, on the use of multi-core processors in avionics, this does not constitute formal policy or guidance.
ii) Single-core processors which have been used in safety-critical avionics applications are now nearing the end of silicon availability or are no longer available [2].
iii) The historical dominance of PowerPC in the embedded market appears to be somewhat in decline, and the long term future appears to be uncertain with NXP (formerly Freescale) developing ARM-based processors as well as to PowerPC. In addition, the large number of PowerPC QorIQ processor architecture variants makes it unclear if there will be a de facto choice for avionics.
iv) The increasing performance of ARM-based processors means that they may be considered as a viable option for some types of avionics application where PowerPC processors had been used previously.
v) Intel processors which historically were not widely considered for use in avionics applications due in part to their power dissipation requirements are now being considered due to Intel’s low-power 14nm processor devices [3].
These market dynamics have resulted in fragmentation of processor selection for avionics, resulting in a lack of an obvious, single successor for widely-deployed PowerPC single core processors. We are now facing a wide range of contenders in terms of ARM multi-core, PowerPC QorIQ architecture families and Intel Core and Atom architectures.
The Challenge of RTOS Safety Certification
Undertaking DO-178B and ED-12B Level A software certification of an RTOS is extremely expensive, costing millions of Euros and is specific to an underlying processor architecture. It is cost-prohibitive COTS real-time operating system (RTOS) suppliers to undertake DO-178B and ED-12B safety certification on many different processor architectures, with no guarantee of being able to recoup the non-recurring engineering (NRE) costs.
For these reasons, DO-178B and ED-12B Level A COTS RTOS certification evidence packages have been developed for the most widely-used single-core processors in avionics. Wind River has used a COTS evidence approach for the VxWorks RTOS which has enabled the significant DO-178 and ED-12 certification NRE costs to be amortised across multiple customers and programmes using the same processor architecture, reducing the cost of certification on each programme. This also results in a virtuous circle, as these processors have provided the lowest cost options for follow-on certification projects, due to the ability to reuse existing DO-178 and ED-12 certification evidence, rather than having to develop it for a new processor architecture and associated incremental costs.
The Challenge of Multi-core Certification
The route to multi-core certification currently presents a challenge to avionics programmes due to lack of formal policy / guidance published by FAA and EASA. However, the EASA MULCORS research report and FAA CAST-32 position paper should be taken into consideration when planning a safety-critical multi-core avionics project.
Programmes may wish to consider the use of a multi-core processor in their next hardware platform even if their current processing requirements do not exceed that provided by a single core, in order to provide adequate processing capacity to meet future processing requirements. The selection of a multi-core processor may also become a necessity due to the lack of availability of single core processors as mentioned earlier. Similarly, some programmes may wish to use multi-core processors which have more than two cores, as 4-core and 8-core devices are now relatively common. However, CAST-32 does not consider multi-core processors with more than two active cores. Certifying multi-core processors will require substantial research and certification leadership to extend the guidance in the MULCORS and CAST-32 papers.
In both of the above scenarios, programmes will need to be able to utilise certain processor cores and deactivate the unused cores. To meet the multi-core determinism objectives of CAST-32, programmes will need to demonstrate that a deactivated core cannot unexpectedly become active and interfere with the operation of the processor’s other cores. This could either use an approach of regularly reading control registers which are critical to safe operation and resetting the register value in the event of a change of state being detected; or by regularly overwriting the control registers to ensure that the desired state is maintained. Some processors may also provide performance monitoring units which enable the state of an individual core to be determined independently.
The software implementation of core deactivation is processor-specific, and depends on whether individual processor architecture provides the ability for a core to be able to write to a control register to deactivate another core or not. For example, on the PowerPC QorIQ T2080™ processor, deactivation of an individual core can be achieved by setting the relevant bit field in the Core Disable Register during Pre-Boot Initialisation or when the core is in boot hold off mode, and once a core has been deactivated it can only be re-enabled via power-on, hard reset or core reset [4].
The ability of safety-critical avionics programmes to be able to deactivate individual cores and develop a safety-case which includes robust arguments for the deterministic operation of the process may depend on the ability to obtain detailed technical information on the design and operation of the processor from the semiconductor manufacturer. Some companies may make this information publicly available, while others may only provide certain levels of information under non-disclosure agreement. For programmes undertaking DO-254 hardware certification, this will be a particularly important requirement, and will need to ensure that the selected semiconductor manufacturer will provide access to the required information, even if they do not formally support DO-254 certification in the way as companies such as Altera [5].
Conclusions
The avionics market is currently undergoing a significant transition from single-core to multi-core processor architectures, being driven by demands for greater system functionality and the semiconductor product lifecycles which primarily target the much larger commercial market segments. The advances made by semiconductor manufacturers now present a much broader range of viable processor choices for avionics applications than was available in the past. Although there currently appears to be some uncertainty about the best choice of processor for safety-critical avionics programmes, it is likely that positive experiences gained by early adopters on multi-core programmes will result in a virtuous circle of support, further adoption and success, in a similar way to single-core avionics programmes of previous decades generated a rich supplier ecosystem of COTS avionics certification solutions.
References
[1] “Microprocessor Evaluations for Safety-Critical, Real-Time Applications: Authority for Expenditure No. 43 Phase 5 Report”, US Federal Aviation Administration. DOT/FAA/AR-11/5, May 2011. https://www.faa.gov/aircraft/air_cert/design_approvals/air_software/media/11-5.pdf
[2] Product Longevity – Archived (September 2014), NXP website.
https://www.nxp.com/pages/product-longevity-archived-september-2014:LONGEVITY-ARCHIVED
[3] “Advancing Moore’s Law – The Road to 14nm”, presentation, Intel website, 11th August 2014. https://www.intel.com/content/www/us/en/silicon-innovations/advancing-moores-law-in-2014-presentation.html
[4] QorIQ T2080 Family Reference Manual, T2080RM Rev 1, NXP, May 2015.
https://www.nxp.com/webapp/Download?colCode=T2080RM
[5] DO-254 Safety Solutions, Altera website,
https://www.altera.com/solutions/industry/military/applications/do-254/mil-do-254.html
