case時代の⾞載組込みシステムの動向と課題2 case時代の載組込みシステム...

Hiroaki Takada

CASE時代の⾞載組込みシステムの動向と課題

⾼⽥広章2019年9⽉12⽇

1

CASE時代の⾞載組込みシステム

名古屋⼤学未来社会創造機構モビリティ社会研究所教授名古屋⼤学⼤学院情報学研究科教授附属組込みシステム研究センター⻑

APTJ株式会社代表取締役会⻑・CTOEmail: [email protected] URL: http://www.ertl.jp/~hiro/

ソフトウェア品質シンポジウム2019

Hiroaki Takada

⾃⼰紹介本務

▶ 名古屋大学未来社会創造機構モビリティ社会研究所教授▶ 名古屋大学大学院情報科学研究科情報システム学専

攻教授／附属組込みシステム研究センター長その他の役職（主なもの）

▶ APTJ株式会社代表取締役会長・CTO▶ TOPPERSプロジェクト会長▶ 内閣府 SIP自動走行システム交通環境情報構築TF 主査▶ 車載組込みシステムフォーラム（ASIF）会長

研究分野

▶ （組込みシステム向け）リアルタイムOS▶ リアルタイム性解析とスケジューリング理論▶ 機能安全技術，組込みシステムのサイバーセキュリティ▶ 車載組込みシステムと車載ネットワーク，ダイナミックマップ

2



Hiroaki Takada

TOPPERSプロジェクト▶ ITRON仕様の技術開発成果を出発点として，

組込みシステム構築の基盤となる各種の高品質なオープンソースソフトウェアを開発するとともに，その利用技術を提供

組込みシステム分野において，Linuxのように広く使われるオープンソースOSの構築を⽬指す!

プロジェクトの狙い

▶ 決定版のITRON仕様OSの開発

▶ 次世代のリアルタイムOS技術の開発

▶ 組込みシステム開発技術と開発支援ツールの開発

▶ 組込みシステム技術者の育成への貢献

プロジェクトの推進主体

▶ 産学官の団体と個人が参加する産学官民連携プロジェクト

▶ 2003年9月にNPO法人として組織化

3


← ほぼ完了


Hiroaki Takada

Cell3iMager duos

(SCREENホールディングス)

スカイラインハイブリッド (日産)

4


SoftBank 945SH

（シャープ） PM-A970(エプソン)

IPSiO GX e3300 (リコー)

UA-101 (Roland)

H-IIB（JAXA)OSP-P300(オークマ)

開発成果物の主な利用事例

エスクード (スズキ)


Hiroaki Takada

名古屋⼤学組込みシステム研究センター (NCES)設立目的

▶ 組込みシステム分野の技術と人材に対する産業界からの要求にこたえるために，組込みシステム技術に関する研究・教育の拠点を，名古屋大学に形成

活動領域（スコープ）

▶ 大学の技術シーズを実現/実用化することを指向した研究

▶ プロトタイプとなるソフトウェアの開発

▶ 組込みシステム技術者の教育/人材育成

主な研究テーマ（プロジェクト）

▶ AUTOSAR Adaptive Platform（A2Pコンソーシアム）

▶ AUTOSARツールチェーン（APTOOLコンソーシアム）

▶ ダイナミックマップ（DM2.0コンソーシアム）

▶ 車載組込みシステムのセキュリティ強化技術

5

☞ http://www.nces.is.nagoya-u.ac.jp/



Hiroaki Takada

APTJ株式会社APTJの設立背景 ▶ AUTOSARが車載制御システム向けのSPF（広い意味で

のOS）の国際標準になる流れの中で，車載制御システム向けのSPFが海外製だけになるおそれ

▶ 名古屋大学における研究開発だけでは不十分と判断

APTJの活動と位置付け ▶ AUTOSAR CP仕様に準拠した車載制御システム向けの

SPFである Julinar SPFを開発・販売

▶ 名古屋大学における産学連携の研究開発成果を活用（名古屋大学発ベンチャー企業）

▶技術的な強みは，RTOS，機能安全，サイバーセキュリティ，マルチコアプロセッサに関する要素技術と知験

▶ 自動車部品メーカ／自動車メーカとの共同開発

▶ パートナーソフトウェア企業との協力

6



Hiroaki Takada

⽬次CASE・自動運転と車載組込みシステム技術 ▶ 自動運転の動向，自動運転システムの技術構成

▶ CASEが車載組込みシステムに及ぼす影響

自動車と自動運転の安全性

▶ 自動車の安全性と組込みシステム，機能安全

▶ 自動運転と安全性，自動運転の安全性に関する課題

▶ 社会受容性が決める自動運転車の安全性

車載組込みシステム開発の動向と課題

▶ CASEによる車載組込みシステム技術の変化

▶ 車載組込みシステム開発の課題，課題に対するアプローチ

▶ 車載組込みシステム向けのSPF，AUTOSARおわりに

7



Hiroaki Takada

CASE・⾃動運転と⾞載組込みシステム技術

8



Hiroaki Takada

⾃動⾞に起こりつつある変化：CASEC ： Connected（つながる） ▶ 通信ネットワーク等により自動車の外部とデジタル情報を

やりとりすることで，高度な機能やサービスを提供

A ： Autonomous（自動化） ▶ 自動運転，無人運転

S ： Shared & Services（シェアリング，サービス化） ▶ 自動車を個人で持つのではなく，多くの人で共有（シェア）

するように？

▶ モノ（自動車）の所有からサービス（移動）の利用へ

▶ “mobility as a service”（MaaS）

E ： Electric（電動化） ▶ 電気自動車，ハイブリッド自動車，燃料電池自動車

▶ 環境問題（大気汚染，地球温暖化）への対策

9



Hiroaki Takada

⾃動運転の動向実用化に向けて2つ（＋1つ）の方向に分化 ▶ 自家用車（オーナーカー）

▶ 2020年に向けて，自動車専用道での自動運転（レベル3）の実現を目指す

▶ 商用車（バス，タクシー，トラック）

▶限定領域（ODD）での無人運転バスまたはタクシー（レベル4，遠隔監視付き）の実現を目指す

• 走行できる範囲（道路）や状況（天候など）を制限する

• 危険な状況ではゆっくり走行する手がある

▶自動車専用道での隊列走行トラック（後続車は運転手がいなくても良い）の実証実験が進む

10



Hiroaki Takada

自動運転のレベル

11


自動運転レベル

名称定義概要安全運転に係る監視，対応主体

０運転自動

化なし運転者が全ての動的運転タスクを実行運転者

１運転支援システムが縦方向又は横方向のいずれかの車両運動制御のサブタスクを限定領域において実行

運転者

２部分運転自動化

システムが縦方向及び横方向両方の車両運動制御のサブタスクを限定領域において実行

運転者

３条件付運転自動化

システムが全ての動的運転タスクを限定領域において実行。作動継続が困難な場合は，システムの介入要求等に適切に応答

システム（作動継続が困難な場合

は運転者）

４高度運転自動化

システムが全ての動的運転タスク及び作動継続が困難な場合への応答を限定領域において実行

システム

５完全運転自動化

システムが全ての動的運転タスク及び作動継続が困難な場合への応答を無制限に（すなわち，限定領域内ではない）実行

システム


Hiroaki Takada

日本政府の取り組み

▶ 2014年度：内閣府のSIP（戦略的イノベーション創造プログラム）で，自動運転技術への取り組みを開始。関係省庁も自動運転に関する技術の研究開発に力を入れ始める

▶ 2018年4月：高度情報通信ネットワーク社会推進戦略本部・官民データ活用推進戦略会議（本部長：内閣総理大臣）が「自動運転に係る制度整備大綱」を発表

▶ 2018年9月：国土交通省が「自動運転車の安全技術ガイドライン」を公表

▶ 2019年5月：道路交通法と道路運送車両法の改正が成立

▶法律的には，レベル3の自動運転が可能に

▶自動運転中にスマホを使うことなどが可能に

▶自動運行装置（プログラムにより自動的に自動車を運行させるために必要な装置）が保安基準の対象に追加

! 国連（WP1，WP29）による基準化やISOでの標準化に先行

12



Hiroaki Takada

⾃動運転システムの技術構成認知

▶ 周辺認識

▶種々のセンサー（カメラ，LIDAR，ミリ波レーダー（長距離，中距離），超音波センサー等）の組み合わせ

▶ 自己位置推定

▶ GNSS（衛星による測位），ジャイロ，地図（広い意味でのマップマッチング）などの組み合わせ

判断

▶ 行動計画

▶目標走行軌跡・速度，車線変更・合流

制御

▶ 車両制御（パワトレ，ステアリング，ブレーキ）

▶ HMI（対ドライバ，対歩行者）

13



Hiroaki Takada

CASEが⾞載組込みシステムに及ぼす影響ネットワーク接続（Connected） ▶ サイバーセキュリティ対応がますます重要に

自動化，知能化（Autonomous） ▶ 新しい技術（AIや新しいプロセッサ技術など）を取り込んで，

車載組込みシステムは大きく変化

▶ セーフティクリティカルシステムとしては，従来になく複雑

サービス化，シェアリング（Shared & Services） ▶ クラウドと組込みシステムの役割分担がどうなるか？

電動化（Electric） ▶ HVは車載システムを複雑化．EVは単純化

共通課題

▶ ソフトウェアの機動的な更新（OTA）が必要に

▶ 車載システムのアーキテクチャが大きく変わる可能性

14



Hiroaki Takada

⾞載システムのアーキテクチャの変化自律分散型から中央集権型システムへ

▶ 自動運転システムは，自動車全体を操る頭脳

▶高性能なコンピュータ（従来のECUより1〜2桁高性能）を，自動車に搭載することに（搭載方法にも課題）

▶ “ビークルコンピュータ”の導入

▶ ソフトウェア更新（OTA）の対象がビークルコンピュータに限定できると嬉しい

→自動車もソフトウェア中心に．“Software-defined Vehicle”▶ （とは言え）技術的には様々な課題

フォルクスワーゲンが出しているメッセージ

▶ ハードウェアとソフトウェアを分割して調達

▶ ECUのハードウェアとSPFは，自動車メーカが用意？

▶ “ソフトウェア会社になる”

15



Hiroaki Takada

⾃動⾞と⾃動運転の安全性

16



Hiroaki Takada

⾃動⾞の安全性と組込みシステム安全性（など）を高める組込みシステム ▶  自動車の安全性を高めるために，組込みシステムが活用

されている ▶ ABS（アンチロックブレーキ），姿勢制御（例：VDIM） ▶ プリクラッシュセーフティ，緊急ブレーキ ▶ エアバッグ，シートベルト

▶  組込みシステムは，省エネルギー・低排気ガス，利便性・娯楽性の向上のためにも活用されている

組込みシステムそのものの安全性 ▶  安全性（など）を高めるための組込みシステムが誤動作す

ると，逆に危険を引き起こす ▶  組込みシステム（ソフトウェアを含む）は，十分に安全に設

計・開発されなければならない → 機能安全規格の必要性

17



Hiroaki Takada

安全性と機能安全安全性（safety） ▶ システムが規定された条件のもとで，人の生命，健康，財

産またはその環境を危険にさらす状態に移行しない期待度合い（JIS X 0134）

▶ 信頼性（機能単位が，要求された機能を与えられた条件のもとで，与えられた期間実行する能力（JIS X 0014））とは明確に異なる概念

機能安全（functional safety） ▶ 機能的な工夫（安全を確保する機能）により極力安全を確

保する（NECA 技術委員会報告第３の波「機能安全」の概要）

▶例）踏切の警報機や遮断機

▶ 安全を確保するための機能を，安全機能と呼ぶ

▶ 本質安全と対比される考え方

18



Hiroaki Takada

参考：安全性と信頼性安全性と信頼性の定義の相違

▶ 信頼性は要求された機能を実行する能力であるのに対して，安全性は機能とは無関係に定義される概念

▶ 安全性は（機能単位ではなく）システムに対する要件

安全性はあるが信頼性がない場合

例）開かない踏切の遮断機

▶衝突事故を起こさないという意味では，安全性はある

▶機能を果たしていないので，信頼性はない

安全性はあるが信頼性がない場合

▶ 「要求された機能」が安全なものでない場合

信頼性向上策と安全性向上策が相反する場合も

例）2重系にすると，安全性は上がるが，信頼性は下がる

19



Hiroaki Takada

機能安全と安全要求分析機能安全と信頼性のギャップ

▶ 機能により，「人の生命，健康，財産またはその環境を危険にさらす状態に移行しない」ようにするのが機能安全の考え方

▶ まずは，安全性を確保するために必要な機能（安全機能）を定義することが必要

安全要求分析

▶ 安全性を確保するために取るべき手段（安全機能を含む）を抽出するための分析作業

▶ 危険の可能性（ハザード）の洗い出し（hazard analysis）と危険性（リスク）の評価（risk assessment）を行う

▶ 許容できないリスクに対して，対策を検討・追加し，再度リスクの評価を行う

▶ これに成功すれば，後は信頼性を確保すればよいという意味で，機能安全実現に向けての最も重要な作業

20



Hiroaki Takada

⽤語解説：ハザードとリスクハザード（潜在危険）

▶ 潜在的に危険の原因となりうるもの

▶ 自動車のハザードとしては，ブレーキがかからない，ハンドルが切れない，ハンドルが勝手に切れる，などなどが考えられる

リスク（危険性）

▶ ある事象生起の確からしさと，それによる負の結果の組合せ（JIS Z8115: 2000）

▶ 事象 ⇒ 事故生起の確からしさ ⇒ 発生確率負の結果 ⇒ 重大度（または損害）

21


重大度

発生確率

NG

OK


Hiroaki Takada

安全システム技術▶ 許容度を超えるリスクを，軽減するための技術

▶事故の発生確率を下げる

▶事故の重大度を下げる

高信頼システム技術

▶ フォールトアボイダンス

▶ フォールトトレランス

フェイルセーフ（fail safe） ▶ システムの構成要素が故障しても，

システム全体が安全側（重大度が低い側）に動作するように設計する

例）ABSの制御システムが故障したら，動作を止める ▶ 故障を検知する方法とそれによる検知率が問題

▶ 安全側の動作がないシステムには，適用できない

22


重大度

発生確率

NG

OK


Hiroaki Takada

⾞載システムのための機能安全規格：ISO 26262ISO 26262の位置付け

▶ “Road vehicles – Functional safety –”▶ 機能安全の一般規格であるIEC 61508の自動車分野向け

サブ規格

▶ 基本的な考え方はIEC 61508を踏襲しているが，自動車分野の状況に合致するように様々な修正/追加規定

▶自動車向け安全度水準ASIL A〜Dを規定

▶自動車に特化したハザード分類の方法を定義

▶大量生産品であることを考慮

▶複数の組織で開発することを考慮

▶ 初版が2011年11月，第２版が2018年12月に発行

▶ 第２版で，適用範囲が大型車やバイクにも拡大

23



Hiroaki Takada

ISO 26262における機能安全の定義

▶ 電気/電子システムの機能不全のふるまい（≒誤動作）により引き起こされるハザードが原因となる，不合理なリスク（≒許容できないリスク）の不在

規格の性格・考え方

▶ 安全性確保のためのベストプラクティスの集大成

▶安全性確保のための技法が数多く挙げられており，安全度水準（ASIL，A〜Dの4レベル）に応じて使用すべきもの（一部，使用すべきでないもの）を定めている

▶ ハードウェアの信頼性は，部品の故障率から積み上げて計算する

▶ ソフトウェアの信頼性は，プロセスにより確保する

▶ ASIL毎に規定された必須技法を使って開発されたソフトウェアは，十分な信頼性があるとみなす

24


一般的な定義より狭い


Hiroaki Takada

ASIL（Automotive SIL）とは？ ▶ 許容できないリスクを回避するために必要な安全方策の

要求レベル

▶ ASIL D（もっとも厳しい）〜A（もっとも厳しくない）〜QM▶ IEC 61508のSILと違い，確率要求/目標を含まない

▶ ただし，ランダムハードウェア故障に関しては確率目標が与えられる

ASILの決定方法 ▶ ハザードの過酷さ（severity），暴露度（exposure），制御性

（controllability）から決定

過酷さ×曝露度×制御性

▶ 例えば，致命傷の可能性があり，頻繁に発生する状況で起こり，回避が困難なハザードは，ASIL D

25



Hiroaki Takada

⾃動運転と安全性そもそも…

▶ 安全性の向上は，自動運転に対する最大の期待（社会的価値）

自動運転車の安全性に関する議論が高まる

▶ 自動運転車の実用化が近付き，安全性や事故時の法的責任などの制度面に関する議論が高まっている

▶人工知能（特にニューラルネットワーク）を用いた場合の安全性の証明方法は？

▶自動運転車の型式認定の基準は？

▶ 「自動運転車の安全技術ガイドライン」では…

▶ 「自動運転システムが引き起こす人身事故がゼロとなる社会の実現を目指す」

▶ ドイツでは，自動運転のための（安全性に関する）基準を提供することを目的に，PEGASUSプロジェクトを推進

26



Hiroaki Takada

自動運転車による死亡事故

▶ テスラの自動運転車（レベル2）による最初の死亡事故

▶ 2016年5月に米国で発生

▶ ドライバは「ハンドルに手を添えてください」という警告を無視して，オートパイロットモードで走行

▶ NHTSAは，車には欠陥の証拠が認められなかった（つまり，事故はドライバの責任）と結論

▶ 2018年3月にも類似の事故が発生

▶ Uberの自動運転テスト車（レベル4）による死亡事故

▶ 2018年3月に米国で発生

▶自動運転システムの責任．ソフトウェアの問題？

▶他のメーカは，公道でのテスト走行を見合わせ

▶ 重大性の低い事故は他にも多数

27



Hiroaki Takada

⾃動運転の安全性に関する課題社会受容性の見極めと醸成

▶ 自動運転車の安全性はどのレベルであるべきか？

性能限界の考慮（SOTIF） ▶ 認識技術には性能限界がある．それが安全性にかかわる

▶ ISO 26262の機能安全の定義から外れている

フェイルオペレーショナルの実現（機能安全）

▶ 故障時に停止することが許されない機能が増加

▶ 「何が安全か」にも難しい状況が

サイバーセキュリティ上の課題

▶ ネットワーク接続の拡大により，サイバーセキュリティの確保が重要に（という意味では，“connected”の課題）

▶ 自動運転により，リスクが高まる

▶ バックドアをどう防ぐか？

28



Hiroaki Takada

複雑化するSoC（マイコン）とソフトウェア ▶ 複雑なSoC（マイコン）で，リアルタイム性を確保できるか？

▶ リアルタイムシステム向けでないプロセッサコアの適用

▶複雑過ぎて，動きが予測できない（特に，コア間干渉）

▶ これまで以上に複雑なソフトウェアを高い信頼性を維持して作りきれるか？

安全性評価

▶ 自動運転車の安全性をどのように確認するか？

▶自動運転システムの保安基準（型式認定の基準）は？

変化する要求・環境への対応

▶ 発生した事故に対する再発防止策が追加される

▶ 安全目標や求められる安全性のレベルも変化する可能性

29



Hiroaki Takada

SOTIF (Safety Of The Intended Functionality)SOFITとは？ ▶ 性能限界や誤使用など，システムの誤動作以外に起因す

るリスクを想定して安全なシステムを設計すること

▶ 本来の機能安全には含まれる

なぜ，ISO 26262の機能安全の定義は狭いのか？ ▶ 自動車にとっての本来の機能安全は，ABS，姿勢制御，

緊急ブレーキ，エアバッグといったシステムによる安全

▶ SOTIFは，機械技術や制御技術側の課題であった

今，SOTIFが重要視されているのはなぜ？ ▶ レベル3以上の自動運転に必須であるため

▶ これまでの安全運転支援から安全運転そのものへ

▶ 自動車がソフトウェア中心に変わろうとする中で，ソフトウェア技術（や電子技術）が自動車の安全性確保の前線に

30



Hiroaki Takada

⾃動運転⾞の安全性はどのレベルであるべきか？

▶ 従来の自動車業界の水準の安全性の実現は，現時点では困難（ただし，のろのろ運転なら可能性があるかも）

▶ そもそも，事故を避けるのが難しい状況もある

▶  「下手なドライバより安全」であれば，近い将来に実現 ▶ エキスパートドライバ並みは，簡単ではない

31


How good is good enough?

� Which functional performance do highly automated driving functions need to be accepted by driver and society?

ÎTo answer this question generally accepted quality criteria, tools and methods are developed.• employed to the sample application of the highway chauffeur

© PEGASUS | Symposium| 9th November 2017 8

Scenario Analysis and Quality Measures

driving performance

%

Ø ?autopilot ?

less good good very good

human drivers

PEGASUSプロジェクトの資料より

How safe is safe enough?


Hiroaki Takada

⾃動運転の安全性評価への取り組みPEGASUSプロジェクト ▶ ドイツでは，自動運転のための基準を提供することを目的

に，PEGASUSプロジェクトを推進

▶自動運転車の評価フレームワークを開発

▶ システム開発・評価のためにデータベースを活用

国内における取り組み

▶ 自工会（JAMA）：安全構想，シナリオカタログ

▶ 日本自動車研究所（JARI）：交通環境テストシナリオ

▶ SIP-adus：安全性評価環境（シミュレータ）

他の国でも同様の取り組み

▶ フランス：MOOVE，SVA▶ 米国：AMP（Automated Mobility Policy）

32



Hiroaki Takada

Database Approach to Develop and Validate CAD

Traffic Simulation

Dynamic Driving

Simulator Test Track

Field Operational

Tests

Database of Relevant Traffic

Situations

Softwarein-the-loop

Hardwarein-the-loop

Real Traffic

SOP

Functional Concept

ComponentDevelopment

Motivation

E3

Extractions

E1

E5 E4

E2

T1

T2

T3

T4

T5

Test levels

Idea

criteria

critical test situations

severity

accident re-construction

criteria

critical real-world situations

R1 R2 R3 R4

generation of new constellations

criteria

Recording ofsituations & criteria

R

E

Recording intothe DB

Extracting fromthe DB


TrafficSimulation

DynamicDriving

SimulatorTest Track

FieldOperational

Tests

Database ofRelevant Traffic

Situations

Software in-the-loop

Hardware in-the-loop

Real Traffic

SOP

FunctionalConcept

Component Development

Motivation

E3

Extractions

E1

E5E4

E2

T1

T2

T3

T4

T5

Test levels

Idea

criteria

critical testsituations

severity

accidentre-construction

criteria

critical real-worldsituations

R1R2R3R4


criteria


R

E

Recording intothe DB

Extracting fromthe DB


TrafficSimulation

DynamicDriving

SimulatorTest Track

FieldOperational

Tests

Database ofRelevant Traffic

Situations

Softwarein-the-loop

Hardwarein-the-loop

Real Traffic

SOP

FunctionalConcept

ComponentDevelopment

Motivation

E3

Extractions

E1

E5E4

E2

T1

T2

T3

T4

T5

Test levels

Idea

criteria

critical testsituations

severity

accidentre-construction

criteria

critical real-worldsituations

R1R2R3R4


criteria


R

E

Recording into the DB

Extracting from the DB

PEGASUSにおける開発・評価ライフサイクル ▶  データベースを中心に置いたライフサイクル ▶  自動運転車に関する事故が起こることを前提にしたプロセ

スになっている

33


※ PEGASUSプロジェクトの資料より


Hiroaki Takada

社会受容性が決める⾃動運転⾞の安全性社会受容性

▶ 受容可能なリスクは，社会的便益（または，導入しない場合のリスク）との兼ね合いで決まる

▶ 自己責任のリスクは受容しやすい

▶ 社会の動きは，理性的とは限らない

方向性

▶ 次の活動を通じて，社会受容性を醸成することが必要

▶自動運転システムのリスクの説明

▶ それを最小化する努力の説明

▶発生した事故に対する説明

GuaranteeからBest Effortへ？ ▶ リスクが小さく，便益が大きい使途から導入していくべき

34



Hiroaki Takada

参考：⾃動運転の社会的価値安全性の向上

▶ 自動運転により事故を減らす

時間を有効活用

▶ 自動車で移動中に他の仕事ができる

高齢者／地方の移動手段

▶ 公共交通がない地方における移動手段の確保

人手不足の解消

▶ 隊列走行や無人配送で運送業における人手不足の解消

その他（いろいろある）

▶ 自動駐車による時間の有効活用や運転ストレスの低減

▶ カーシェアリングの有効利用（自動運転による回送）

▶ 渋滞緩和

35



Hiroaki Takada

⾞載組込みシステム開発の動向と課題

36



Hiroaki Takada

⾞載組込みシステムの動向 (⾃動運転登場前から)車載制御システムの高度化

▶ 自動車に対する新しい付加価値の多くが，電子制御/コンピュータ/ソフトウェアで実現

▶省エネルギー，低排気ガス（エンジン制御，…）

▶安全性の向上（ABS，エアバッグ，…）

▶利便性の向上，娯楽性の向上（カーナビ，…）

▶ コンピュータを活用することで，軽量化やコストダウンが可能になる場合も

例）車載ネットワークによるワイヤハーネス（自動車内の配線）の軽量化

▶ 統合制御システム/サービス（複数のECUの協調/連携により提供するサービス）が増加

è⾞載組込みシステム/ソフトウェアが著しく複雑化

37



Hiroaki Takada

システムの例）LEXUS LS460（2006年） ▶ 100個以上の車載制御コンピ

ュータ（ECU：電子制御装置）

▶ 組み込まれたソフトウェアの総ライン数が7,000,000行（A4の紙に印刷すると10万ページに）（いずれも雑誌の報道による数値）

38


http://www.lexus.jp/

資料提供：デンソー

車載組込みシステムとネットワーク（イメージ図）

! システムが著しく複雑化

! その後の10年で，ソフトウェア規模はさらに10倍になっているとも⾔われている


Hiroaki Takada

CASEによる⾞載組込みシステム技術の変化システムのますますの大規模化・複雑化

▶ 手足の電子化／コンピュータ化から，頭脳のコンピュータ化へ（AI技術の導入）

▶ 外部接続の拡大（クラウドとの連携，V2X）

▶ ただし，一部の機能がクラウドに移されることにより，組込みシステムはシンプルになるケースも

ソフトウェアの機動的な更新

▶ ソフトウェアの更新による機能アップ・安全性向上

▶ （S）OTA（Software update Over-The-Air）サイバーセキュリティへの対応が必須に

▶ サイバーセキュリティを原因とするはじめてのリコール事例として，クライスラーが140万台をリコール（2015年7月）

▶ 近い内に法規化される見通し

39



Hiroaki Takada

新しいプラットフォーム技術の採用

▶ 急拡大する性能要求にこたえるための新しいプロセッサ技術（GPUやGPGPU，FPGA，メニーコアプロセッサ）の採用 ▶放熱や電力供給も問題に

▶ ソフトウェアプラットフォームの高度化

▶従来のAUTOSAR仕様では力不足．AUTOSARはAdaptive Platformへ

▶ 新しい車載ネットワーク技術（車載Ethernet）の導入

▶ マルチコアや仮想マシン（VM）によるアプリケーション統合（ECU統合，車載センターコンピュータ）

安全性の考え方の変化

▶ フェールセーフからフェールオペレーショナルへ

仮想環境（シミュレーション）の活用が進む

▶ 実車（実物）を用いたテストが限界に

40



Hiroaki Takada

ハードウェアプラットフォームの例NVIDIA Tegra X1 ▶ NVIDIAのモバイル向けGPU▶車載もターゲットに（NVIDIA

DRIVE PXに2個搭載）

▶ Maxwell GPUアーキテクチャ

▶ 256 CUDA Cores▶ ピーク性能：512GFLOPS

（半精度だとその2倍）

▶ ARM Cortex A57×4＋A53×4▶ 最大メモリ帯域：25.6GB/s

41



Hiroaki Takada

ルネサス R-Car H3 ▶ ルネサスの自動運転向けSoC▶ 「自動運転レベル2やレベル3を超えることのできるSoC」

▶ ARM Cortex A57×4＋A53×4

▶ ARM Cortex R7（デュアルコアロックステップ）

▶ GPU：PowerVR GX6650▶ 画像認識ハードウェア：

IMP-X5▶ 最大メモリ帯域：50GB/s▶ ASIL B対応

42



Hiroaki Takada

⾞載組込みシステム開発の課題ディペンダビリティの確保/向上 ▶ システムの大規模化により，設計品質，特にディペンダビリ

ティ（信頼性，安全性，セキュリティ，…）の確保が困難に

▶ 機能安全規格（ISO 26262）への効率的な対応

▶ サイバーセキュリティの確保/強化が大きな課題に

設計生産性の向上（開発の効率化）

▶ システムの複雑化や品質要求により，設計生産性が低下

ECUの数の増加，ネットワーク構成の複雑化 ▶ コストの増大や設置スペースの不足

急拡大する性能要件，扱うデータの増加への対応

新しい技術（AI等）をどのように導入するか？その背景にある深刻な問題

組込みシステム技術者 (人財) 不足

43



Hiroaki Takada

課題に対するアプローチディペンダビリティの確保/向上，説明/証明力の向上 ▶  機能安全規格（ISO 26262）やセキュリティ規格（ISO/SAE

21434，策定中）への対応（良いところを取り入れる）

▶ トップダウンな設計コンセプト（安全コンセプト，セキュリティコンセプト）とアーキテクチャの構築▶ 説明力/証明力の向上に加えて，コスト最適化にも有効

設計生産性の向上（開発の効率化） ▶  ソフトウェア開発プロセスの地道な改善 ▶  設計抽象度を向上させるためのモデルベース開発 ▶  設計資産の“良い”再利用を可能にするためのプロダクト

ライン開発とコンポーネントベース開発 ▶  アプリケーション開発底上げのためのプラットフォームと，

その共通化・標準化（プラットフォームベース開発） ▶  仮想環境（シミュレータ）による検証の効率化

44



Hiroaki Takada

ECUの数の増加への対応 ▶ ECU統合 … 徐々に進行中

▶ プラットフォームの共通化・標準化が前提に

▶ パーティショニング技術が重要に

急拡大する性能要件への対応

▶ 新しいプロセッサ技術（マルチ/メニーコア，GPU，FPGA）の導入

▶ それを使いこなせるソフトウェアの構成/開発技術

ネットワーク構成の複雑化，扱うデータの増加への対応

▶ 新しい車載ネットワーク技術（CAN FD，車載Ethernet）の導入

▶ 新しい通信プロトコル（SOME/IP，DDSなど）の導入

新しい技術をどのように導入するか？

▶ 新たなアライアンス，オープンイノベーション

45



Hiroaki Takada

プラットフォームの活⽤と共通化・標準化プラットフォームとは？

▶ アプリケーションシステム開発の基盤となる部分

▶ プラットフォーム＝ハードウェアPF＋ソフトウェアPF▶ ソフトウェアPF（SPF）＝OS＋ミドルウェア＋デバドラ

! 自動車分野では，車台の意味と区別するために，電子プラットフォームと呼ぶ場合も多い

応用ドメイン毎のプラットフォーム構築

▶ 多様な組込みシステムを，１つのプラットフォームでカバーするのは不可能

▶ 適切な範囲（これが難しい）の応用ドメインを設定し，それに向いたプラットフォームを構築

46



Hiroaki Takada

⾞載組込みシステム向けのSPF車載制御システム向け

▶ AUTOSAR（Classic Platform）仕様のSPFが，業界標準として広く使われていく流れ

IVI（In-Vehicle Infotainment）システム向け ▶ 現状，各種のSPFが使われている

▶ 代表的な標準化活動として，AGL（Automotive GradeLinux）とGENEVIがある

▶ トヨタ自動車がAGLを積極的に牽引．利用を開始

自動運転システム向け

▶ 当面は戦国時代？

▶ ROS（Robot Operating System）/ROS2とAUTOSARAdaptive Platformが有力候補

47



Hiroaki Takada

AUTOSAR (AUTomotive Open System ARchitecture)

▶ 自動車，自動車部品，エレクトロニクス，半導体，ソフトウェア企業によるグローバルパートナーシップ（2003年に設立）▶ ソフトウェアの複雑性を軽減するために，ソフトウェア基

盤（infrastructure）の業界標準を作成▶ コアパートナー（2019年時点）

▶ 2つのプラットフォーム仕様の標準化を推進▶制御システム向けのClassic Platform（CP）仕様（最新は

R4.4.0）は，100を超えるソフトウェア仕様書とほぼ同数の関連ドキュメントなどで構成▶自動運転システム向けのAdaptive Platform（AP）仕様

は開発フェーズ（最新はR18-10）．並行してリファレンス実装が進む

48


BMW Daimler PSA Peugeot CitroenBosch Ford トヨタ自動車Continental GM Volkswagen


Hiroaki Takada

AUTOSAR CPの標準化領域 ▶ ソフトウェアアーキテクチャ

▶ ソフトウェアプラットフォーム（SPF）の構成

▶ RTE仕様

▶ BSWモジュール（OS，デバイスドライバ群，ミドルウェア群）毎のインタフェース（API）仕様

▶ 方法論とテンプレート（Methodology and Templates）▶ アプリケーションシステムの構築手順

▶ アプリケーションインタフェース

▶ SW-C（アプリケーション毎のソフトウェア部品）間で受け渡すデータのカタログ

▶初期は，SW-Cのインタフェースそのものの標準化を目指したが，断念（競争領域で標準化になじまない）

49



Hiroaki Takada

AUTOSARアプローチ ▶ アプリケーションシステム

を，Virtual Functional Busで接続されたソフトウェア部品（SW-C）群の形で論理的に記述

▶ 各SW-Cを，ECUにマッピングする（現時点では手動）と，ECUの構成ファイルをツールにより生成

▶ その際に，ECU記述とシステム制約記述（処理の時間制約など）を与える

▶ ソフトウェアプラットフォーム（SPF）は，RTEとBSWで構成

50

Virtual Functional Bus V2.0.0

R4.0 Rev 1

ECU I

Virtual Functional Bus

AU

TOSA

RSW

-C1

AU

TOSA

RSW

-C2

AU

TOSA

RSW

-C3

AU

TOSA

RSW

-Cn...

ECU II

AU

TOSA

RSW

-C1

AU

TOSA

RSW

-C2

AU

TOSA

RSW

-C3

ECU m

AU

TOSA

RSW

-Cn

RTE

Basic Software

RTE

Basic Software

RTE

Basic Software

...

VFB view

Mapping

System ContraintDescriptionECU

DescriptionsTool supporting deployment

of SW components

Gateway

SW-CDescription

SW-CDescription

SW-CDescription

SW-CDescription

Figure 2.2: Detailed view on the activity “Configure System”

In AUTOSAR, an application is modeled as a composition of interconnected components. This is illustrated in the top half of Figure 2.2 (labeled JVFB viewK). TheJvirtual functional busK is the communication mechanism that allows these components to interact. In a design step called JConfigure SystemK, the componentsare mapped on specific system resources (ECUs). Thereby, the virtual connectionsbetween the components are mapped onto local connections (within a single ECU) oron network-technology specific communication mechanisms (such as CAN or FlexRay frames). Finally, the individual ECUs in such a system can be configured. The concrete interface between the components and the rest of the system on an ECU is called the Run-Time Environment (RTE), which is defined in [Specification of RTE]. A component encapsulates complete or partial automotive functionality. Componentsconsist of an implementation and of an associated formal software-component description (defined in [SW-C Template]). The concept of the virtual functional bus allows for a strict separation between applications and infrastructure. The software components implementing the application are largely independent of the communication mechanisms through which the component interacts with othercomponents or with hardware (such as sensor or actuators). This fulfills AUTOSARUsgoal of relocatability (also see [Main Requirements]). With this the complete communication of a system can be specified including all communication sources and sinks. The VFB can therefore be used for plausibilitychecks concerning the communication of software components. The communication

9 of 74 Document ID 056: AUTOSAR_EXP_VFB - AUTOSAR Confidential -

AUTOSAR Virtual Function Bus 2.0.0より


（AUTOSAR CP）


Hiroaki Takada

AUTOSAR CPのSPFの構成 ▶ Runtime Environment (RTE)▶ SW-C間，SW-CとBSW間の通信インタフェースを提供

▶ Basic Software（BSW）

▶ OS+デバイスドライバ+ミドルウェア群

51


AUTOSAR Layered Software Architecture 4.3.0より- AUTOSAR Confidential -

Document ID 053 : AUTOSAR_EXP_LayeredSoftwareArchitecture74

Not all modules are shown here

ArchitectureOverview of Modules – Implementation Conformance Class 3 - ICC3

page

id: 9

dfc8

Complex Drivers

Microcontroller

AUTOSAR Runtime Environment (RTE)

Microcontroller Drivers Memory Drivers I/O Drivers

I/O Hardware Abstraction

Memory Hardware Abstraction

Memory Services System Services

Onboard Device Abstraction

Communication Drivers

Communication Hardware Abstraction

Communication Services

Application Layer

Port

Adc

Dio

Pw

m

Icu

Ram

Tst

Can

Fls

Wdg

Lin

Mcu

Fr

Gpt

Spi

MemIf

Driver for ext.

I/O ASIC

Driver for ext.

ADC ASIC

WdgIf

Tp

Com

Nm

IpduM

Nm If

ext. Drv Trcv.

NvM

AU

TOS

AR

OS

PduR

This figure shows the mapping of basic software modules to AUTOSAR layers

I/O Signal Interface

Ea Fee

EcuM

Eep

Eth

Dcm

Dlt

Xf

xxx Interface

FlsTst

CorTst

SM

Ocu

FiM

WdgM

Det

Dem

Com

M

StbM

Bsw

M

Tm SecO

C


Hiroaki Takada

AUTOSARの新しい動き：Adaptive Platformの策定・開発 ▶ ADAS・自動運転の実現に向けて，ソフトウェアプラット

フォームにも新しい要求

▶ ADAS・自動運転を狙った新しい仕様として，AUTOSARAdaptive Platform（AP）の策定を開始

▶仕様のみ作成する活動モデルを変更．リファレンスソフトウェア（exemplary software）の開発にも取り組む

▶最初の仕様書が2017年3月にリリースされた後，半年毎に新しい版がリリース

▶ リファレンスソフトウェア（APD，Dは“Demonstrator”）は，AUTOSARのメンバ向けにリリースされている

▶ 従来の仕様は，AUTOSAR Classic Platform（CP）と改名

▶ Classicと言っても「古い」という意味ではなく，役割の違いであり，今後も不要になるわけではない

52



Hiroaki Takada

AUTOSAR APと他のプラットフォームとの使い分け（共存）

53

CASE時代の⾞載組込みシステムExplanations of Adaptive Platform Design

AUTOSAR AP Release 17-03

10 of 31 Document ID 706: AUTOSAR_EXP_PlatformDesign- AUTOSAR Confidential -

Figure 2-1 Exemplary deployment of different platforms

Figure 2-2 Exemplary interactions of AP and CP

AUTOSAR: “Explanations of Adaptive Platform Design”, R17-03より


Hiroaki Takada

AUTOSAR APの位置付け ▶ CPとの関係（早い時期の資料）

54


Another platform for different applications

29 October 2015

Safety criticality

Real time requirements

Computing power

AUTOSAR Classic Platform

Microcontroller

Runtime Environment

CD

Microcontroller Abstraction Layer

Service Layer

ECU Abstraction Layer

Infotainment Platform supporting „Planned

dynamics“

8th AUTOSAR Open Conference - AUTOSAR Adaptive Platform9M. Bechter: “AUTOSAR Adaptive Platform”, 8th AUTOSAR Open Conference 2015より

AUTOSAR CPとIVI向けプラットフォームの間の領域

これは違う

疑わしい


Hiroaki Takada

AUTOSAR CPとAPの技術的な違い ▶ 最大の違いは静的か動的（Planned dynamics）か

▶ 下の表から，CPとAPでは，適用対象のアプリケーション（ECU）のイメージが違っていることがわかる

55


M. Bechter: “AUTOSAR Adaptive Platform – Key concepts and developmentprocess,” 9th AUTOSAR Open Conference（2016）を独自に日本語訳

AUTOSAR Classic Platform AUTOSAR Adaptive Platform

OSEKベース POSIXベース

ROMからコードを直接実行アプリケーションは不揮発メモリからRAMにロードされる

すべてのアプリケーションが1つのアドレス空間を共有（安全性のためにMPUを使用）

各アプリケーションが自分の（仮想）アドレス空間を持つ（MMUを使用）

シグナルベースの通信（CAN，FlexRay）に最適化

サービス指向通信

タスク構成が固定複数の（動的な）スケジューリング戦略をサポート


Hiroaki Takada

APが活用する技術 ! APの標準化では，これまで車載システムで活用できてい

なかったものも含めて，以下のような技術や標準を活用

▶ C++（具体的には，C++11/14）

▶ サービス指向アーキテクチャ（SOA）

▶ システムをサービスの集合で構成するという考え方

▶分散コンピューティングに力点

▶ 並列処理

▶ セーフティとセキュリティ

▶ 動的な振る舞いの計画（Planned dynamics）▶ ソフトウェアの開発とインテグレーション時には，リソース

と通信の動的管理により開発を容易にし，製品提供の時点では，動的な振る舞いを制限する

▶ アジャイル開発

56



Hiroaki Takada

おわりに

57



Hiroaki Takada

⾞載組込みシステム開発の挑戦従来からの課題の深化

▶ ディペンダビリティの確保/向上，サイバーセキュリティの強化

▶ 設計生産性の向上（開発の効率化）

▶ 技術者（人財）の不足新しい技術への対応

▶ AI（機械学習，Deep Learning）▶ 新しいプロセッサ技術（マルチ/メニーコア，GPU，FPGA）

両立させずらい要求にどう対処するか？

▶ 開発効率 vs. ディペンダビリティ

▶ 実行性能 vs. リアルタイム性（ディペンダビリティ）

▶ 新しい技術（AI） vs. ディペンダビリティ

そもそも，どの程度のディペンダビリティが必要か？

58



Hiroaki Takada

取り組むべきこと：組込みシステム開発技術の⾰新新しい環境への対応が必要な一方で… ▶ 我が国の組込みシステム業界（に限らず，ものづくり産業）

の強みは，品質の高いシステム開発（ものづくり）能力にある

▶ 新興国の追い上げの中で，強みを失わない努力が必要

新しい「開発」技術に挑戦しよう！

▶ 我が国の組込みシステム業界は，新しい技術（特にソフトウェア技術）やツールの導入に積極的でない（一般論）

▶ 技術者不足の中で，ツールによる自動化を進めやすくなっている（はず）

▶ システム開発への人工知能技術の適用（AI for SE）は未知数だが，大きな可能性

59



case時代の ⾞載組込みシステムの動向と課題2 case時代の 載組込みシステム...

Documents

case時代の⾞載組込みシステムの動向と課題2 case時代の載組込みシステム...