© 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

© 2017 Arm Limited

Backup

© 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