AUTOSARにおける「Safety, Security」に対する最新動向＆事例紹介

株式会社デンソー

電子基盤システム開発部

佐藤洋介

1

Introduction

• 本日の趣旨– 本発表では、AUTOSAR技術動向を紹介することで、Safety&Securityに

関する海外OEM向けECU開発の現場感を共有したいと考えます

– 日本との温度差やSafety&Securityに関わる実製品開発の現状を知る上での一助となれば幸いです

• Agenda– Ⅰ. Background

• ECUビジネス動向、車載システム技術動向

– Ⅱ. AUTOSAR仕様策定状況• 技術的特徴、仕様策定の年表

– Ⅲ. AUTOSAR導入の現状• 海外OEMの導入モチベーション、ISO26262、Cyber security

2

Ⅰ. Background

3

ECUビジネス動向

4

製造設計開発

企画研究

海外移転加速・US, AU・ASEAN海外設計拠点化

・EU, US・インド, 中国共同研究加速

・EU, US・インド, 中国

1990年代

2000年代

2010年代

2015年?派遣切り社会問題化

低コスト、グローバル開発（海外設計拠点化）

【事業環境】・ECU価格競争激化・OEMからの低価格化要求への対応・OEMからの現地サポート要求への対応

車載システム技術動向

5

1990 2005 2010 202x

Stand Alone

Systems

Networked Sub-systems

Service Integrated Systems(Vehicle and Infrastructure)

Integrated Vehicle Systems

Control Systems

ECU systems

Environment

Safety

Comfort

Convenience

NetworkAccess

Processing Data communication Network system Integrating applications Autonomous cooperation system

Integration On-demandStandalone

大規模・複雑化、車載ネットワークのオープン化

まとめ（Background)

• ECUビジネス動向と製造形態の変化– 価格競争の激化とOEMからの低価格化要求への対応から、「低コス

ト、グローバル開発（海外設計拠点化）」へ

• 車載システム動向– 大規模・複雑化、車載ネットワークのオープン化

• 自動車業界全体としての取り組み– Automotive Open System Architecture（2003年設立）

– 開発コストの低減のための

「競争領域と非競争領域を意識した水平分業化」

6

オープンな標準ソフトウェア・アーキテクチャAUTOSAR仕様の策定へ

Ⅱ. AUTOSAR仕様策定状況

7

AUTOSAR Organization

8

10 Core Partners

46 Premium Members

CapeWare

24 Associate Members

AUTOSARの技術的特徴

9

• 標準プラットフォームベース開発/コンポーネントベース開発– 標準仕様に基づいたソフトPFとソフト部品の再利用

• 標準ソフトPFのランタイムであるRTE上でソフト部品SWCを再利用する

– ハードウェア非依存• RTEにより、SWCはECUハードウェアに非依存となり、SWC流通が促進

ECU-Hardware

AUTOSAR Runtime Environment (RTE)

ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftware

Basic SoftwareStandardized

Interface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

MicrocontrollerAbstraction

AUTOSARSoftware

Component

Interface

ECUFirmware

StandardSoftware

StandardizedAUTOSARInterface

Services

StandardizedInterface

ECUAbstraction

AUTOSARInterface

StandardizedInterface

ComplexDeviceDrivers

AUTOSARInterface

API 2VFB & RTErelevant

StandardizedInterface

Communication

StandardizedInterface

StandardizedInterface

OperatingSystem

API 1RTErelevant

API 0

StandardizedInteface

API 3 PrivateInterfaces inside Basic Software

possible ECU-Hardware

AUTOSAR Runtime Environment (RTE)

ActuatorSoftware

Component

AUTOSARInterface

ApplicationSoftware

Component

SensorSoftware

Component

ApplicationSoftware

Component

..............

AUTOSARSoftware

Basic SoftwareStandardized

Interface

AUTOSARInterface

AUTOSARInterface

AUTOSARInterface

MicrocontrollerAbstraction

AUTOSARSoftware

Component

Interface

ECUFirmware

StandardSoftware

StandardizedAUTOSARInterface

Services

StandardizedInterface

ECUAbstraction

AUTOSARInterface

StandardizedInterface

ComplexDeviceDrivers

AUTOSARInterface

API 2VFB & RTErelevant

StandardizedInterface

Communication

StandardizedInterface

StandardizedInterface

OperatingSystem

API 1RTErelevant

API 0

StandardizedInteface

API 3 PrivateInterfaces inside Basic Software

possible

競争領域

協調領域（=標準仕様化対象）BSW(Basic SoftWare)

A社部品

B社部品

C社部品

D社部品

AUTOSAR仕様の年表

• 2003年、AUTOSARコンソーシアム設立

• 2011年、AR2.1を使用した量産車SOP(BMW 3 series)• 2013年、多くの海外OEMがAR3.xまたはAR4.xを導入開始

10

2012201120102009200820072006200520042003

AUTOSARconsortium establishment

R2.0R1.0 R2.1

R4.0

R3.0 R3.2R3.1

R4.1.1R4.0.2

R3.2.2

・機能安全仕様(メモリ保護、時間保護等）の追加・コンフォーマンス仕様の追加によるベンダー間の互換性向上

・安定版・BSWベンダー依存仕様多

SOP: Start Of Production

まとめ（What’s AUTOSAR ）• AUTOSAR仕様の現状：AR3.x vs. AR4.x

– AUTOSAR 3.x• First specification released: End of 2007• 仕様的に安定はしているが、ISO26262やCyber Securityはサポート外

– AUTOSAR 4.x• First specification released: End of 2009• 新機軸であるISO26262, Cyber security, Partialnet, Ethernet,,,対応

11

• In 2017– 多くのECUへAR4.x対応要求– AR3.x対応要求は減少傾向

海外OEMとビジネスする上でAUTOSAR対応は必須であり、AR4.xが主流となる

Ⅲ. AUTOSAR導入の現状

12

海外OEMの導入モチベーション

• 低コスト開発への対応– グローバル開発のインフラ（共通開発環境）として

– これまでOEM毎に独自であった通信仕様を標準化されたAUTOSAR COM/DIAGに置き換えることにより、独自仕様・評価パッケージ作成コストを削減することができる

– グローバルスタンダードな標準仕様を導入することで、新たなサプライヤの参入障壁を引き下げることができる

• 新機軸対応– Safety: ISO26262– Cyber security(CSM/SHE)– エコ(Partialnet)– 高速化(Ethernet,CAN‐FD)

13

本日の報告内容

※ISO26262規格概要については情報獲得が容易であるため、本発表では解説しません。

ISO26262認証のポイント

• 安全に設計されていることを、証明するため、– 開発&設計の中身（技術）が安全であること

– 開発&設計の進め方（プロセス）が適切であること

• を、認証機関にエビデンス（＝セーフティケース）を示して、論理的・体系的に説明できることが求められる

14

６．製品開発：ソフトウェアレベル

6-5 ソフトウェアレベルにおける製品開発の開始

6-6 ソフトウェア安全要求事項の詳細仕様

6-10 ソフトウェアの結合および試験

6-8 ソフトウェアユニットの設計および実装

6-11 ソフトウェア安全性要求事項の整合性検証

6-7 ソフトウェアアーキテクチャ設計

6-9 ソフトウェアユニット試験

６．製品開発：ソフトウェアレベル

6-5 ソフトウェアレベルにおける製品開発の開始

6-6 ソフトウェア安全要求事項の詳細仕様

6-10 ソフトウェアの結合および試験

6-8 ソフトウェアユニットの設計および実装

6-11 ソフトウェア安全性要求事項の整合性検証

6-7 ソフトウェアアーキテクチャ設計

6-9 ソフトウェアユニット試験

• ソフトウェア設計上の観点– 同一コンポーネント内に異なるASILのサブコンポーネント

を配置する場合、異常の伝播が発生しないこと（=ソフトウェアパーティショニングが正しく設計されていること）の説明を要求している

– 静的・動的なパーティションで区切り、影響範囲を狭めることが重要

Safety: ISO26262

【事例】AUTOSARを利用したISO26262対応

• BSWを使用する上での課題– BSWに潜在する不具合：

Safety SWCに異常が伝搬する

– BSWがSafety processに沿って開発されていない

15

• AUTOSAR仕様で定義されている Safety Functions– OS Scalability Class

• SC1 : OSEK + Basic scheduling• SC2 : Timing Protection• SC3 : Memory Protection (w/ HW support)• SC4 : SC2+SC3

– OS‐Application (Partition)• Trusted : Supervisor execution (No restriction)• Non‐trusted : User execution (restricted)

Non Safety Functions

(QM)Safety

(ASIL)

Safety: ISO26262

Trusted, Non-trustedの範囲設定をどうするか？

【事例】AUTOSARを利用したISO26262対応

• Trusted, Non‐trustedの範囲設定のアプローチ– 手段① BSW + Safety Appを「Trusted」とする

– 手段② Safety Appのみを「Trusted」とする

16

BSW本体をTrustedとするよりも、BSWにISO26262対応用機能を持たせる形が現実的

Non-Trusted

Trusted

Trusted TrustedNon-Trusted

Non-Trusted

Safety: ISO26262

BSW ASIL Trusted（ASIL OS: ¥100,000,000)

QM Non‐trusted（OS: ¥4,000,000)

Non‐safety App QM Non‐trusted QM Non‐trusted

Safety App ASIL Trusted ASIL Trusted

【事例】ISO26262対応用機能の例• ISO26262対応用機能の例：Vector社製MICROSAR

– SafeContext: 異常を伝搬させない空間保護– SafeWatchdog： Checkpointによる実行監視機能

17

【出典】http://vector.com/

Safety: ISO26262

車載システムに求められる技術的セキュリティ

• SR.1: 電子制御によるセーフティ機能のデータの完全性と信頼性の保証– セーフティ機能にかかわる認証や制御を行う際に、制御の命令等のデータが、攻

撃者によって書き換えられること等を防ぐ

• SR.2: ECUまたはファームウェアのインストール、設定の完全性、信頼性の保証– アップロードされる新しいセキュリティアルゴリズム、セキュリティ機能の秘密の情

報、動作の許可など認可情報を保護

• SR.3: セキュアな実行環境の提供– ECUへの攻撃が成功したとしても、キーとなる秘密の情報が格納された「トラスト

ゾーン」へのアクセスを防ぐ

• SR.4: 自動車の機能、データへのアクセス制御機能の提供• SR.5: 車載ECUプラットフォームの信用性(trusted)の保証• SR.6: セキュアな車載ストレージの提供• SR.7: 特定の車載通信と外部通信の機密性の保証• SR.8: プライバシの保証• SR.9: セキュリティ機能の干渉防止

18

Cyber security

【出典】IPA発行「自動車の情報セキュリティへの取組みガイド」

車載ネットワークのオープン化により、車載ネットワークを介した脅威が増加

実製品におけるCyber security要求

• 2016年IVER製品におけるCyber security動向– 各OEM毎に「Secure requirements specification」を整備

• Requirements to both software and hardware• Process requirements

– Requirements to Tier1 Configuration Management– Programming guidelines

– Secure flash boot loader– Encrypted data communication

• AUTOSAR BSWの下記モジュールで実現する– CSM: Crypto Service Manager– （CRY: Cryptographic Library）– SHEDRV: Driver for Secure Hardware Extension

19

IVER: Integration Vehicle Engineering Release

Cyber security

喫緊で暗号化の要求が増大しているため、AUTOSARでは暗号化から仕様化を開始

AUTOSARにおけるCyber security• CSM/SHE

– Controllerへ暗号化・複合化セキュリティロジックを一体化することにより、従来のソフトのみの構成や、外部バスを経由した通信が傍受可能な外付けセキュリティチップを用いた方法を上回る

– ルネサス製RH850 F1MやSpansion製Coretex R4などがSHE規格に対応

– AES128暗号化、MAC生成、乱数発生、セキュアブート、鍵管理などが主な機能

20

Cyber security

【出典】http://www.spansion.com/

鍵格納用ストレージ

暗号機能部

制御用マイコン接続部

実製品への導入の流れと傾向

21

• Release 3.xを導入するOEM– 特定ベンダー(Vectorなど)依存– 従来通信仕様を継続使用

• Release 4.xを導入するOEM– 特定ベンダーに非依存– AUTOSAR通信仕様準拠(COM,DIAG,FBL)

まとめ（AUTOSAR導入の現状）

• AUTOSARを取り巻く技術動向– 仕様面：Infotainment, Connectivity分野の拡大が顕著– 製品面：新機能（Safety,Security,,,)の導入が開始、対応が求められる

• AUTOSARは新機能導入のフレームワークとして動いている– AUTOSAR導入のタイミングは、車載システム形態が変化するとき

22

終わりに

• 車載システム全体の動向– ECU価格競争の激化とOEMからの低価格化要求への対応から、「低

コスト、グローバル開発（海外設計拠点化）」へ

– 大規模・複雑化、車載ネットワークのオープン化

• AUTOSAR仕様策定状況– 2017年以降ではAR4.xが主流となる

– 新機軸であるISO26262, Cyber security, Partialnet, Ethernet, CAN‐FDなどを取り込みながら仕様を策定中

• 海外自動車業界の動向– グローバル開発のインフラ（共通開発環境）としてAUTOSAR導入開始

– AUTOSARは新機軸導入のフレームワークとして動いている

23