M. Gatti, Thales
Download
Report
Transcript M. Gatti, Thales
CTIC CONFERENCE – MAY 2013
www.thalesgroup.com
Development and certification
of Avionics Platforms on MultiCore processors
Marc GATTI – August 29th, 2013
Context
2 /
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.
CTIC CONFERENCE – MAY 2013
Access to MULCORS report
https://www.easa.europa.eu/safety-andresearch/research-projects/large-aeroplanes.php
AGENDA
3 /
Multi-core:
CTIC CONFERENCE – MAY 2013
Introduction
Problems to Solve
Regarding certification
Software Aspects
Failure Mitigation Means & COTS Relative
Features
Conclusion
CTIC CONFERENCE – MAY 2013
4 /
Introduction
MULTI-CORE
Multi-Core: Introduction
5 /
CTIC CONFERENCE – MAY 2013
Multi-Core processor
Architecture: Unified
Memory Access
Multi-Core processor
Architecture: Distributed
Architecture
Multi-Core processor
Architecture: Single
Address space, Distributed
Memory
Multi-Core: Introduction
6 /
Airb. SW
Airb. SW
Airb. SW
Drivers
Drivers
Drivers
O.S.
O.S.
O.S.
Intended Function
BSP
BSP
BSP
Core
Core
Core
Core
Core
Core
Cache
Cache
Cache
Cache
Cache
Cache
BUS
Register
BUS
Register
Register
Register
EXT MEMORY
External Network
HW adaptation Layer (BSP)
Hypervisor layer (when required)
Operating System
Drivers
Airborne Software
External Bus
Hypervisor
CTIC CONFERENCE – MAY 2013
EXT MEMORY
Register
Register
Register
INTERCONNECT
Register
7 /
Problems to Solve
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Multi-Core: Introduction
8 /
CTIC CONFERENCE – MAY 2013
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
Multi-Core: Introduction
9 /
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
CTIC CONFERENCE – MAY 2013
Conflicts
Management
Conflicts
Management
Conflicts
Management
Conflicts
Management
Multi-Core: Introduction
10 /
DETERMINISM IN EMBEDDED AIRCRAFT SYSTEMS
Abstract notion partially described in DO-297
Definition based on
Multicore COTS Processors
CTIC CONFERENCE – MAY 2013
Execution Integrity
WCET analysis
Platform Usage Domain
Robust Partitioning (not only for IMA system)
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
CTIC CONFERENCE – MAY 2013
MULTI-CORE
12 /
CTIC CONFERENCE – MAY 2013
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
Multi-Core Processor features
13 /
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 services to be managed
Arbitration
of incoming requests
Arbitration rules
Arbiter internal logic
Network topology
Allocation
Allocation
of the physical destination devices
of a path to the destination.
Support for atomic operations,
CTIC CONFERENCE – MAY 2013
Hardware locking mechanisms
Snooping mechanisms for cache coherency
Inter Processors Interruptions (IPI) for inter-core
communications
Multi-Core Processor features
14 /
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
Direct mapped cache
CTIC CONFERENCE – MAY 2013
cache
Replacement policies
CACHE COHERENCY MECHANISM
Required in architecture that integrates several storage devices
hosting same data.
Coherency protocols:
Invalidate protocols
Update
protocols
Multi-Core Processor features
15 /
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
CTIC CONFERENCE – MAY 2013
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.
Multi-Core Processor features
16 /
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
Shared I/O features similar to shared services configuration:
Access
CTIC CONFERENCE – MAY 2013
accesses to the memory have to be well managed.
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
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Partitioned system features
18 /
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
CTIC CONFERENCE – MAY 2013
Symmetrical
Multi-processing (SMP).
Each partition are activated on one core with true parallelism between partitions
Asymmetrical Multi-processing (AMP).
Operating System global view
19 /
From Single Core to Multi-Core in AMP (Asymmetric multi-processing)
APP1
APP2
APP3
T1
T1
T1
T2
T2
T3
T3
T2
T3
T4
T4
T5
Space & Time Partitionning
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
Operating System
CORE
CORE
CORE
BRIDGE
CTIC CONFERENCE – MAY 2013
Memory
Controller
I/O
Controller
INTERCONNECT
BUS /
Network
Interface
Memory
Controller
Solve
Conflict
I/O
Controller
BUS /
Network
Interface
Memory
Controller
Operating System global view
20 /
From Single Core to Multi-Core in SMP (Symmetric multi-processing)
APP1
T1
APP2
APP3
T1
T1
T1
T2
T2
APP1
T2
T2
T3
T3
T3
T4
T4
T3
T5
T4
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
CORE
BRIDGE
CTIC CONFERENCE – MAY 2013
Memory
Controller
I/O
Controller
CORE
CORE
INTERCONNECT
BUS /
Network
Interface
Memory
Controller
Solve
Conflict
I/O
Controller
BUS /
Network
Interface
Memory
Controller
Current mono-core concept
21 /
APP2
APP1
T1
APP3
T1
T1
T2
T2
T3
T2
T3
T3
T4
T4
T5
Space & Time Partitionning
Operating System
CORE
BRIDGE
Memory
Controller
I/O
Controller
BUS /
Network
Interface
Thread /
Process
T4
T3
T1
T3
T3
T2
Partition 1
T1
Partition 2
T3
T2
T2
T1
T4
T1
T2
T1
OS
Core
CTIC CONFERENCE – MAY 2013
T5
T4
T1
T1
Appli. 1
T
Appli. 2
T
Appli. 3
T
idle
Partition 3
Partition 4
time
22 /
APP4
APP1
APP3
APP2
T1
T1
T1
T1
T1
T2
T3
T3
T2
T2
T3
T3
T4
T3
T4
T1
T2
T2
T2
AMP
APP5
APP5
T4
T3
T5
Space & Time Partitionning
Space & Time Partitionning
Operating System
Operating System
CORE
CORE
INTERCONNECT
Core 2
Memory
Controller
T5
T2
T2
T2
T1
T1
T3
T3
T2
T1
T2
T1
Partition 2.2
T1
T1
Partition 2.4
Partition 2.3
T4
T3 T3
T1
T3 T3
T3
T2
T1
Partition 1.1
T1
Partition 1.2
T3
T2
T2
T1
T2
T1
OS 2
T3
T3
Thread /
Process
T4
T4
Partition 1.1
CTIC CONFERENCE – MAY 2013
BUS /
Network
Interface
I/O
Controller
T1
T1
OS 1
Core 1
Memory
Controller
Appli. 1
T
Appli.2
T
Appli 3
T
Appli 4
T
Appli 5
T
Appli 6
T
Appli 7
T
idle
Partition 1.3
Partition 1.4
time
SMP
23 /
APP2
APP1
T3
APP3
T2
T1
T3
T1
T4
T2
In SMP mode, Processes,
Threads or Tasks should be
allocated to cores statically to
achieve determinism
T2
T4
T1
T3
T5
Space & Time Partitionning
Operating System
CORE
CORE
INTERCONNECT
I/O
Controller
T2
BUS /
Network
Interface
T2
Memory
Controller
T2
Thread /
Process
T2
T5
T4
T1T1
Partition 1
T4
T4
T3
T3
T1T3
Partition 2
T1T1
Partition 3
OS
Core 1 Core 2
CTIC CONFERENCE – MAY 2013
Memory
Controller
T3
T1
Appli. 1
T
Appli. 2
Appli. 3
T
T
idle
T1
Partition 4
time
24 /
Failure Mitigation Means & COTS Relative Features
CTIC CONFERENCE – MAY 2013
MULTI-CORE
Multi-Core: Failure Mitigation
25 /
FMEA and/or FFPA for a single or a multi-core processor is
not achievable at processor level
Software Error Rate SEE (Single Event Effect)
Measurements on SER are usually performed by the manufacturers on
their own
Deep Sub Micronics
CTIC CONFERENCE – MAY 2013
Mitigation has to be provided, by the equipment provider, at board level
where this processor is used
DSM has impact of long term reliability
CTIC CONFERENCE – MAY 2013
26 /
CONCLUSION
CONCLUSIONS
27 /
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
CTIC CONFERENCE – MAY 2013
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,
CONCLUSIONS
28 /
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
CTIC CONFERENCE – MAY 2013
behavior
Shall be well known and well managed
Hypervisor level
Hypervisor can be used to constraint the behavior of the interconnect.
Constraints reduce performances but offer determinism