Development and certification of Avionics Platforms on Multi-Core processors

1. Development and certification of Avionics Platforms on Multi-Core processors Marc GATTI – August 29th, 2013

2. Context • This presentation is based on the final report that concludes the MULCORS project contracted with EASA. • The reports provides the main outputs, recommendations and conclusions per EASA Specifications attached to the Invitation to Tender EASA.2011.OP.30. • Access to MULCORS report • https://www.easa.europa.eu/safety-and-research/research-projects/large-aeroplanes.php

3. AGENDA • Multi-core: • Introduction • Problems to Solve • Regarding certification • Software Aspects • Failure Mitigation Means & COTS Relative Features • Conclusion

4. Introduction Multi-core

5. Multi-Core: Introduction • Multi-Core processor Architecture: Unified Memory Access • Multi-Core processor Architecture: Distributed Architecture • Multi-Core processor Architecture: Single Address space, Distributed Memory

6. Multi-Core: Introduction Airb. SW Airb. SW Airb. SW • Intended Function • HW adaptation Layer (BSP) • Hypervisor layer (when required) • Operating System • Drivers • Airborne Software Drivers Drivers Drivers O.S. O.S. O.S. Hypervisor BSP BSP BSP Core Core Core Core Core Core Cache Cache Cache Cache Cache Cache External Bus External Network BUS BUS Register Register Register Register EXT MEMORY EXT MEMORY INTERCONNECT Register Register Register Register

7. Problems to Solve Multi-core

8. Multi-Core: Introduction • What’s a multicore processor? • Multicore processor characterized by N (N ≥ 2) processing cores + a set of shared resources (Memories, PCIe, Ethernet, Cache, Registers, etc.) • Two main types of processors • The first one where interconnect between cores is based on an arbitrated bus • The second one where interconnect between cores is based on a network • Multicore management in certified embedded platform can be summarize to shared resources conflicts management for DAL_A, DAL_B or DAL_C constraints

9. Multi-Core: Introduction • Access conflits • Interconnect between cores • If InterConnect = bus  Accesses arbitration is done at this level • If InterConnect= network  Accesses arbitration depend of numbers of authorized parallel routes (Memories accesses, Bus accesses, Networks accesses, etc.) Conflicts Management Si InterConnect = BUS Si InterConnect = Réseau Conflicts Management Conflicts Management Conflicts Management Conflicts Management

10. Multi-Core: Introduction • Determinism in embedded aircraft systems • Abstract notion partially described in DO-297 • Definition based on • Execution Integrity • WCET analysis • Platform Usage Domain • Robust Partitioning (not only for IMA system) • Multicore COTS Processors • Conflicts Management • Spatial Management: how to manage accesses to be sure that one core can’t access to a space reserved for another core. • Temporal Management: • For Memory Accesses • Operating System • Architecture Choice regarding Industry needs (AMP or SMP)

11. Regarding Certification Multi-core

12. Processor Selection • Manufacturer Selection criteria • Experience in Avionic domain • Experience with the certification process • Publication • Life expectancy • Long term support • Design information on COTS processor • Robustness tests like SEE (Single Event Effect) or SER • Processor Architecture Focus • Virtual Memory service • MMU components • Use of hierarchical memory to improve Software performances

13. Multi-Core Processor features • Interconnect • The first shared resource between cores. • Interleaves concurrent transactions sent by the cores to the shared resources • Architecture and impact on determinism • Architecture and partitioning insurance • Interconnect servicesto be managed • Arbitration of incoming requests • Arbitration rules • Arbiter internal logic • Network topology • Allocation of the physical destination devices • Allocation of a path to the destination. • Support for atomic operations, • Hardware locking mechanisms • Snooping mechanisms for cache coherency • Inter Processors Interruptions (IPI) for inter-core communications

14. Multi-Core Processor features • Shared cache • Shared cache in Embedded Aircraft Systems requires a solution to the following problems: • Shared cache content prediction. • Cache content integrity. . • Concurrent accesses impact. • Cache organizations • Fully associative • N-way set associative cache • Direct mapped cache • Replacement policies • Cache coherency mechanism • Required in architecture that integrates several storage devices hosting same data. • Coherency protocols: • Invalidate protocols • Update protocols

15. Multi-Core Processor features • Shared services • Providing Shared Services among the cores. • Interrupts generation and routing to cores • Core and processor clock configurations • Timer configurations • Watchdog configurations • Power supply and reset • Support for atomic operations • cores • Support execution of multiple software instances in parallel. • Use of inter-core interrupts. • Memory mapping defined in the Memory Management Unit.  Warning: A non-coherent configuration may weaken Robust Partitioning.

16. Multi-Core Processor features • Peripherals: main memory and I/O’s • Sharing main memory sharing physical storage resources and memory controllers. • Space partitioning: Storage resource can be partitioned when necessary. • Sharing accesses to the memory have to be well managed. • Shared I/O features similar to shared services configuration: • Access simultaneously read and/or write buffers. • Classic rules of time and space partitioning can be applied • Initiate specific protocols operations: uninterrupted access is required during the protocol execution to be able to fulfill correctly the concerned protocol. • Concurrent accesses to shared I/O may occur simultaneously from different cores. • Some I/O are accessed according to a protocol, others are accessed from a read and/or write buffer  Atomic access patterns have to be ensured.

17. Software Aspects Multi-core

18. Partitioned system features • Components evolution to take benefit of multi-core platforms • The most “flexible” component is the integration software layer. Possible designs: • A single OS instance shared among all the cores • A private OS instance per core • A virtualization layer hosting several operating systems in dedicated virtual machines. • Partition Deployment • One partition is activated on all cores and has an exclusive access to platform resources • Symmetrical Multi-processing (SMP). • Each partition are activated on one core with true parallelism between partitions Asymmetrical Multi-processing (AMP).

19. Operating System global view From Single Core to Multi-Core in AMP (Asymmetric multi-processing) APP5 APP2 APP5 APP3 APP4 APP1 T1 T1 T1 T1 T1 T1 Space & Time Partitionning Space & Time Partitionning Space & Time Partitionning T2 T2 T2 T2 T2 T2 T3 T3 T3 T3 T3 T3 T4 T4 T4 T5 Operating System Operating System Operating System CORE CORE CORE T4 T5 BRIDGE INTERCONNECT Solve Conflict Memory Controller I/O Controller Memory Controller I/O Controller BUS / Network Interface BUS / Network Interface Memory Controller Example of two cores processor and two memory controllers. For more than two cores (or less than two Memory Controller) conflicts to the Memory Controller have to be managed

20. Operating System global view Space & Time Partitionning From Single Core to Multi-Core in SMP (Symmetric multi-processing) APP2 APP3 APP1 APP1 T1 T1 T1 T1 Space & Time Partitionning T2 T2 T2 T2 T3 T3 T3 T3 T4 T4 T5 T4 Operating System Operating System CORE CORE CORE BRIDGE INTERCONNECT Solve Conflict Memory Controller I/O Controller Memory Controller I/O Controller BUS / Network Interface BUS / Network Interface Memory Controller Example of two cores processor and two memory controllers. For more than two cores (or less than two Memory Controller) conflicts to the Memory Controller have to be managed

21. T4 T4 T3 T3 T3 T2 T2 T2 T1 T1 T1 T1 T1 Current mono-core concept Space & Time Partitionning APP2 APP3 APP1 T1 T1 T1 T2 T2 T2 T3 T3 T3 T4 T4 Operating System T5 CORE BRIDGE Memory Controller I/O Controller BUS / Network Interface Thread / Process T5 T4 Appli. 1 T OS Core T3 Appli. 2 T T2 Appli. 3 T T1 T1 idle time Partition 1 Partition 2 Partition 3 Partition 4

22. Space & Time Partitionning Space & Time Partitionning AMP APP5 APP4 APP5 APP3 APP1 APP2 T1 T1 T1 T2 T1 T1 T1 T2 T2 T2 T2 T3 T2 T3 T3 T3 T4 T4 T3 T3 T4 T5 Operating System Operating System CORE CORE INTERCONNECT Memory Controller I/O Controller BUS / Network Interface Memory Controller Thread / Process T5 T4 T4 Core 1 OS 2 T3 T3 T3 T Appli. 1 T3 T2 T2 T2 T2 T2 T Appli.2 T1 T1 T1 T1 T1 T1 T Appli 3 Partition 2.4 T Partition 1.1 Partition 2.2 Appli 4 Partition 2.3 T4 T Appli 5 OS 1 Core 2 T3 T3 T3 T3 T3 T3 T Appli 6 T2 T2 T2 T2 T Appli 7 T1 T1 T1 T1 T1 T1 T1 idle time Partition 1.1 Partition 1.2 Partition 1.3 Partition 1.4

23. Space & Time Partitionning T2 T4 T3 T1 T1 SMP APP1 APP2 APP3 T2 T1 T1 T3 T3 T4 In SMP mode, Processes, Threads or Tasks should be allocated to cores statically to achieve determinism T2 T2 T4 T3 T1 T5 Operating System CORE CORE INTERCONNECT Memory Controller I/O Controller BUS / Network Interface Memory Controller Core 2 Thread / Process T2 T2 T2 OS T Appli. 1 T Appli. 2 T5 T Appli. 3 T4 T4 Core 1 T3 T3 idle T1 T1 T1 T1 T1 T3 time Partition 1 Partition 2 Partition 3 Partition 4

24. Failure Mitigation Means & COTS Relative Features Multi-core

25. Multi-Core: Failure Mitigation • FMEA and/or FFPA for a single or a multi-core processor is not achievable at processor level • Mitigation has to be provided, by the equipment provider, at board level where this processor is used • Software Error Rate  SEE (Single Event Effect) • Measurements on SER are usually performed by the manufacturers on their own • Deep Sub Micronics • DSM has impact of long term reliability

26. conclusion

27. Conclusions • Complexity of Multi-Core Processors • Has increased over the past few years, • Level of demonstration for design assurance remains at least the same as or better than for COTS without such increment in complexity. • A COTS component remains a COTS component • Features proprietary data from the COTS manufacturer • Approaches: • Access to additional data under agreements with the COTS manufacturer • And/or mitigation of potential COTS faults or errors at board or equipment level,  

28. Conclusions • MULCORS put emphasis on specific Multi-Core features linked to Shared Resource Accesses like Memory, Bus, Network, Internal Registers, Clock Management, etc. • Features that are the main differences between single-core and multi-core devices that have to be managed • Airborne Software Level • Airborne Software behavior • Airborne Software applications allocation to cores can demonstrate the non-interaction between cores. • Interconnect behavior • Shall be well known and well managed • Hypervisor level • Hypervisor can beused to constraint the behavior of the interconnect. • Constraints reduce performances but offer determinism