先進的な技術を実現する arm ip solutionと機能安全 · iso 26262 railways en 5012x...
TRANSCRIPT
© Arm 2017 Arm Tech Symposia 2017
先進的な技術を実現するArm IP solutionと機能安全
© 2017 Arm Limited
Ken Sugamani | Arm
© Arm 2017 2
What are the challenges?
Complex and demanding compute requirements
Fail-functional safety requirement
Increasing need for security
© Arm 2017 3
Increasing complexity in functional safety markets
AutomotiveAutonomous driving
IndustrialFactory automation
HealthcareRobotic surgery
TransportationTrain control systems
AvionicsFlight systems
ConsumerDomestic robots
© Arm 2017 4
Applicable standards – scaling across verticals
Standards always represent an industry consensus
• Long lead times for standards development (5-10 years)
• Often lagging behind true state-of-the-art
Functional safety
of E/E/PE systemsIEC 61508
Automotive
ISO 26262
Railways
EN 5012x
Machinery
IEC 62061ISO 13849
Aviation
DO-178DO-254
Medical
IEC 62304
Industrial
IEC 61511IEC 61513
Safety Integrity Levels
HighLow
SIL 1ASIL A
ASIL BSIL 2
SIL 3ASIL DASIL C
© Arm 2017 5
What is driving system complexity?
Compute-intensive applications
Software delivered from multiple vendors
Security threats growing exponentially
Higher safety integrity requirements
© Arm 2017 6
Workload consolidation
‘Mixed-criticality’ systems
Reduce development cycles
Reduce physical footprints
Reduce attack surface
Individual tasks on separate SoCs
Safe task A
Task DTask CSafe
task B
GPOSRTOS
SoC SoC SoCSoC
RTOS RTOS
Multi-core CPU
Safety app
Security appGUI
Servo control
Monitor / hypervisor
RTOS GPOS
Vision
© Arm 2017 7
Safety and Compute
Safety island for fine grain checking.
• Traditional dual-core lockstep
Redundant execution paradigm for high performance compute.
• Flexible software architectures
• Compute can utilize CPUs and accelerators that do not have ASIL D coverage capability
System safety concept
Counter
Timer
v8-ACPU
Shared cache
Power
GIC
v8-ACPU
Counter
Timer
v8-ACPU
Shared cache
Power
GIC
v8-ACPU
GICv8-RCPU
Shared cache
Timer
Counter
SMMU
Bus master
SMMU
Bus master
System MPU
Memory system
Ethernet
CAN
DRAM
ASIL B diagnostic capability ASIL D diagnostics capability
© Arm 2017 8
Safety island concept
Combine ‘safety island’ with application processors
• Integrate checker functions into SoC
• Sits on independent power and clock rails to reduce common cause failures
• Manages overall safety for SoC
• Enables both high compute with high safety integrity
• Reduces BOM cost and footprint
SoC
Cortex-A
Cortex-R52
Cortex-A
Cortex-ACortex-A
Sensors(Cortex-M)
Sense Perceive Decide Actuate
CoreLink interconnect
Lockstep CPU
© Arm 2017 9
Requirements: From IP to system
IP integratore.g. MCU designer
Tier 1 designer Automotive OEMIP supplier
ISO 26262
-1-2-3-4-5-6-7-8-9
Applicable requirementNot applicable requirements
Requirements, assumptions
Supporting documentation (evidence)
ISO 26262
-1-2-3-4-5-6-7-8-9
ISO 26262
-1-2-3-4-5-6-7-8-9
ISO 26262
-1-2-3-4-5-6-7-8-9
© Arm 2017 10
Arm functional safety package
• Design and verification process
• Fault detection and control
• Verification summary
Safety manual
• Evidence of safety analysis on the Arm IP
• Aids partners with their own SoC level FMEA
• Interworking relationship
• Replaces conventional DIA
• Ambiguity avoidance
FMEA report Development Interface Report
© Arm 2017 11
The broadest safety CPU portfolio
† availability dependent on processor
▪ Cache parity / ECC†
▪ Exception handling▪ MMU
▪ Exception handling▪ MPU
Cortex-M3/M4
Cortex-M0+
Cortex-A
Armv8-A
▪ Virtualization▪ Bus protection▪ SW test library▪ System error▪ Bus ECC▪ Error management▪ TCM ECC▪ MBIST interface▪ Dual core lockstep▪ Cache ECC▪ Exception handling▪ Two-stage MPU
▪ TCM ECC interface▪ MBIST interface▪ Dual core lockstep▪ Cache ECC▪ Exception handling▪ MPU
▪Dual core lockstep†
▪ECC interface†
▪Exception handling▪MPU▪Stack limit check
▪ Bus ECC▪ Error management▪ TCM ECC▪ MBIST interface▪ Dual core lockstep▪ Cache ECC▪ Exception handling▪ MPU
Cortex-M33Cortex-M23
Cortex-M7
Cortex-R52
Cortex-R5
▪ Cache parity / ECC▪ Exception handling▪ MMU▪ RAS features
Cortex-AA55…
SIL3/ASIL D systematic capabilitySIL2/ASIL B systematic capability
© Arm 2017 12
Beyond CPU – other assets
Arm Compiler 6
• Functional safety qualified
• Qualification kit
• Extended maintenance
System IP
• “Quality managed” IP across CCI, NIC, GIC, CryptoCell and CoreSight
• Robust ASIL D roadmap with supporting collateral
© Arm 2017 13
Software Test Libraries
Any safety system relies on multiple error detection mechanisms
• ECC
• DCLS
• Parity
Software Test Libraries provide another detection mechanism
• Libraries are broken down in to functions that cover specific blocks of the CPU core to ensure correct behaviour
• Multiple suppliers across the ecosystem
Parity
MBIST LBIST
DCLS
TimingProtection
Error management
© Arm 2017 14
What are Software Test Libraries (STL)?
The most optimized STLs for Arm cores with the best-in-class diagnostic coverage
• Complements the industry’s broadest safety CPU portfolio
• Delivered pre-certified for production software integration
• Targeting 90% diagnostic coverage
• Common API framework
• Minimized system impact
• Modularized tests executed across multiple fault tolerant time intervals (FTTI)
CPU Schedule
Cortex-R52 CY17Q4
Cortex-M0+, Cortex-M3, and
Cortex-M4CY18Q1
Cortex-M23 andCortex-M33
CY18Q3
© Arm 2017 15
Arm leads the way in functional safety
Arm offers the most comprehensive, scalable portfolio for safety.
Arm is addressing higher compute performance and higher safety integrity requirements.
Software Test Libraries reduce certification burdens and shorten time to market.
1616 © 2017 Arm Limited
The Arm trademarks featured in this presentation are registered trademarks or trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. All rights reserved. All other marks featured may be trademarks of their respective owners.
www.arm.com/company/policies/trademarks
© Arm 2017 18
Safety vs. security
Some languages are great in making the distinction difficult:
安全, sécurité, Sicherheit, säkerhet, turvallisuus, …
…i.e. not all languages differentiate between safety and security in terminology
Environment
System under consideration
Security Safety
SecurityProtecting what’s inside the box
SafetyProtecting what’s outside the box
© Arm 2017 19
What are we protecting against?
Communication attacks▪ Man in the middle▪ Weak RNG▪ Code vulnerabilities
Software attacks▪ Buffer overflows▪ Interrupts▪ Malware
Physical attacks▪ Fault injection: clock or
power glitch, alpha particles ▪ Side channel analysis▪ Probing, FIB
Lifecycle attacks▪ Code downgrade▪ Excess manufacturing▪ Integrity vulnerabilities
© Arm 2017 20
Automotive networksSmart
antenna
5GWIFIEthernet
Domain controller
Domain controller
End Point
End Point
End Point
End Point
End Point
End Point
End Point
End Point
End Point
End Point
Ethernet (1GB )C
AN
FD
CA
N F
D
Domain controller
Sub domain
End Point
Sub domain
End Point
End Point
CA
N F
D
End Point
End Point
End Point
End Point
LIN
CAN
© Arm 2017 21
Diverse range of compute solutions
Other modules
Radar
Central body control
V2X
Autonomous driving
Vision ADAS Infotainment
Powertrain
Energy-aware schedulingRich OSSecurity
Cortex-A75 + Cortex-A55
Real timeHomogeneous multi-core
Cortex-R52
Heterogeneous multi-coreComputer Vision
Control
Cortex-A55 + Cortex-R52
Low power Efficient performance
Scalable
Cortex-M7, Cortex-M0+
Chassis
Sensor
Audio
Security
High performance multi-clusterMachine LearningFunctional safety
Cortex-A75 + Cortex-R52
© Arm 2017 22
Security by separation
PSA protects sensitive assets (keys, credentials and firmware) by separating these from the application firmware and hardware.
PSA defines a Secure Processing Environment (SPE) for this data, the code that manages it and its trusted hardware resources.
The application firmware runs in the Non-secure Processing Environment (NSPE).
PSA requires a secure boot process so only authentic, trusted firmware runs in the SPE.
PSA depends on secure installation of the initial keys and firmware during manufacture.
Application
RTOS
Device management
Secure partition manager
Secure boot
Root of Trust keys
Platform hardware
Non-secure processing environment
Secure processing environment
Under Embargo until 10:00AM PDT October 24 2017
© Arm 2017 23
Standardize interfaces
PSA specifies interfaces to decouple components.
• Enables reuse of components in other device platforms
• Reduces integration effort
Partners can provide alternative implementations.
• Necessary to address different cost, footprint, regulatory or security needs
PSA provides an architectural specification.
• Hardware, firmware and process requirements and interfaces
Device management
Secure partition API
Secure partition manager
Secure hardware requirements
Boot firmware
Root of Trust keys
Platform hardware
Non-secure processing environment
Secure processing environment
Application
RTOS
Secu
re IP
C
Under Embargo until 10:00AM PDT October 24 2017