Requirements and challenges of mixed critical system design

1. Requirements and challenges of mixed critical system design Madeleine Faugère Thales Research and Technology

2. Implementation in the avionic domain Evolution of Mixed criticality concept criticality & Mixed criticality & safety concepts CERTAINTY (ICT FP7 2011- 2014)

3. Mixed criticality in avionics • Mixed criticality is the ability to host applications with different criticality levels on the same system

4. Mixed-criticality exist since ~= year 2000 Evolution from Federated to Integrated Modular Architecture (IMA) Multiple applications share the same processing resource Computing and networking element reduction costs About 30 avionic functions per Computing Unit(CPU) Aims to double/triple on new CPU modules Applications rely on different safety criticality levels Concurrent execution with the guarantee that low critical applications DO NOT perturb high critical ones. Mixed Criticality as today

5. Safety is defined as the freedom of unacceptable risk ensures the absence of catastrophic consequences (hazards) on the user and the environment. Safety ensures the absence of successive holes on the layer of defense Safety Definition

6. Severity of possible accident not acceptable Tolerable Risk acceptable Residual Risk Lower than tolerable risk Hazard category Frequency Always Sometimes Rarely Risk reduction by protection system Very rarely Extremely improbable Severity Minor Major Hazardous Catastrophic

7. DAL: Design Assurance Level (D0 178 B/C) Defined by the potential impact of failure conditions for the aircraft Safety Level definition

8. DAL for a system/function is specified by the client One or more safety level per avionic function Safety level examples

9. Safety process in a nutshell • Safety ensures the absence of successive • holes on the layer of defense

10. Safetyiscostly ! • Current certification methods are costly • Specific development processes (DO 178B/DO 254/ISO26262) are associated DALs/SILs. • Strong design, implementation rules and test activities • Lack of formal verification/validation tools • Mixed criticality is a way to reduce safety cost • If isolation & independence between high/low critical task can be ensured, certification to the highest safety level can be avoided Extra design cost only

11. Implementation in the avionic domain Evolution of Mixed criticality concept CERTAINTY

12. Mixed criticality ensured by partitioning: DO 178 B/C • “Partitioning • Allow multiple software components to run on the same hardware platform • May be achieved by allocating unique hardware resources to each component. • A partitioned software component • Should not be allowed to contaminate another partitioned software component’s code, input/output (I/O), or data storage areas. • Should be allowed to consume shared processor resources only during its scheduled period of execution. • Failures of hardware unique to a partitioned software component should not cause adverse effects on other partitioned software components. • Any software providing partitioning should have the same or higher software level as the highest level of the partitioned software components.”

13. ARINC 653 proposes stdpartitioning Strict spatial and temporal partitioning (ARINC 653) principles enable mixed criticality in the avionic domain: multiple programs with different assurance levels can be used on a single-core device. Memory: protected thanks to the MMU management provided by the hardware/OS Time partitioning: partitions running in dedicated time slots + no partition can delay another partition execution IMA is ARINC 653 compliant Partition 1 Partition 2 Partition 3 Partition 1 … Time ARINC 653 Single core

14. Time partitioning is ONE solution to deal with mixed criticality • Spatial and military domains development do not rely on partitioning • Strong design, validation and test activities • Domains not subject to certification • Partitioning principles have main advantages: • Enable incremental qualification/certification • Respect wellestablishedroles(system integrator, functionsupplier) • Butmixed critical certification methods and tools stay costly • Highest certification level assessment for function and sub-function where function independency is not ensured  high certification cost through • Low performances through system over-provisioning (on WCET) Solution to push forwardMxCgranularityare needed, solution garanteeing isolation whilepreserving performances

15. Mixed criticality on multi cores : new challenges • Partitioning principles are not scalable to multi cores • Insufficient hardware segregation for shared ressources (acces to the shared memory) • Time composability is not ensured New partitionningmecanisms shall be proposed, respecting isolation to the hardware shared ressources while keeping performance in main

16. Evolution of Mixed criticality concept CERTAINTY

17. MCAR program • Designing Future Systems for Airworthiness Certification • Sponsored by AFLR/RBCC (Air Force research laboratory) • Involves Northrop Grumman, Lockheed Martin, Boeing (+ Honeywell, Rockwell Collins, Linux works, Wind river systems, Green Hills, …)

18. MCAR • Different kind of Mixed Criticality • Mission/Flight critical systems (mission based decision taking vs FMS) • Civil/ military domain • Manned / unmanned systems (initiative/authority management) • Challenges • Certification of autonomous systems evolving in a dynamic environment • New verification and validation methods are required to ensure airworthiness certification • Validation and verification methods becomes obsolete (# LOC)

19. SESAR / Next Gen • Single European Sky ATM Research (SESAR) is the name given to the collaborative project that is intended to completely overhaul the European airspace and its Air Traffic Management (ATM).

20. Safety / Security Internet • Security can no more rely on separated systems Air Traffic Management (SESAR/NEXT GEN) shared HW resources Safety shall take care of security concerns

22. Thankyou