自動車の“安全”を考える、ISO 26262の先にある「SaFAD」にどう対応すべきか:AUTOSARを使いこなす(16)(5/5 ページ)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第16回では、AUTOSARと関わりの深い“安全”に関する動向を取り上げる。ISO 26262の先にあるものについて、自動車関連企業11社が発表した「SaFAD paper」を基に解説しよう。
SaFADの考え方から見えてくる、プラットフォームと標準規格への向き合い方
AUTOSAR Classic Platform(CP)のApplication Interface(AI)のような、非競争領域の「Application」に関する標準アーキテクチャが定められて、かつそれが十分に普及していれば、一層具体的かつ有効なアプローチを示すことができます。あいにく現状(R19-11)でのCPではApplication Interfaceは普及してはいませんし、そもそも、AUTOSAR APではApplication Interfaceの定義自体がまだありません。
ですが、論理アーキテクチャや物理アーキテクチャについては、AUTOSAR以外でも、また、さまざまなアーキテクチャ階層について想定(さらにそれを推し進めて、デザインパターン化、標準化)することは可能です。今後そのような取り組みが増えていけば、いわゆるプラットフォームレベルでカバーできる各種メカニズムも増やしていくことができます。例えば、JASPARのAD/ADAS車両制御IF WGから2020年3月13日にJASPARのWebサイト上で一般公開された「AD/ADAS車両制御インタフェース仕様書Ver.1.0(ST-AVI-1)」のような取り組みも、そのような「ベース」の役割を果たせる可能性があると考えています。
ただ同時に、「想定」を作ればよい、選べばよい、というものではないこともすぐに見えてきます。
一般に、システムの実現のためのアーキテクチャ設計(=上位要件を実現するアーキテクチャ要素群とI/Fを特定し、各要素に対して、ブレークダウンした要件を割り付ける活動)にはさまざまな選択肢があります。さらに、そのよりメタなアーキテクチャ階層モデル※9)についても同様です。
※9)よりメタなアーキテクチャ階層モデル:例えば、モビリティシステム全体から単体ソフトウェアに向かってブレークダウンしていくとしたら、以下のような階層構造が考えられます(あくまで一例です、実際には間引いて使うことになるでしょう)。
・モビリティシステム全体
・モビリティシステムの「登場人物/要素」(例:クルマやインフラ、交通参加者)
・クルマのシステムドメイン
・クルマのECU
・ECU内のサブシステム(例:プロセッサ)
・プロセッサ内の(Virtual) Machine((仮想)ハードウェアとソフトウェアの集合体)
・ソフトウェア内のクラスタ
・ソフトウェアのモジュール(例:AUTOSAR CPでのSW-CやBSW)
・ソフトウェアのモジュール内構成要素
なお、最後の「ソフトウェアのモジュール内構成要素」については、例えば、RTOSとCRCライブラリ関数とでは、単体ソフトウェアまでのさらなるブレークダウンの必要性や適切な構成は大きく異なってくるでしょう(最終的な「末端」に近いモジュールの種別に依存)。そのため、一律な基準の設定は難しいのですが、最終的な「末端」の具体化が行われることで、都度定義可能になることでしょう。
これらのメタな階層モデルや実際のアーキテクチャ構成などの「想定」の上には、「具体的」な設計資産が構築されていくことになります。想定を推し進めて築き上げられるデザインパターンが標準化され共有されていくことで、業界全体の共通資産を増やしていくことができます。
しかし、前述の通り、アーキテクチャには多数の選択肢が存在し得ます。採用したその「想定」が世の中の主流であり続けてくれればよいのですが、もしも結果的に傍流になってしまいますと、利用可能な設計資産は相対的に減少していってしまいますし、state-of-the-artではないもの(時代遅れ)という扱いに追いやられてしまいかねません。「具体的であること」「具象化できること」はとても重要なのですが、標準化活動という戦場には同時に、「高い抽象度」に上がってみないと見えてこないような、暗黙の、または、明示された「想定」を多数派として維持し続ける、あるいは、それに追従し続けるための戦いの側面もあります。
日本国内では、「抽象化されたもの」を「具体性がない」と過小評価してしまう場面を少なからず目にしますが、そう決めつけて軽視するのは少々もったいないように思われてなりません。そういった部分を「握る」ということの必要性について無頓着な様子をおみかけするたびに、少々心配になってしまうのも事実です。
次回のテーマは現時点では未定ですが、いずれにしましても、また少し間を開けさせていただくことになると思います。ですが、AUTOSAR R20-11のリリースを迎えましたら、その概要をご紹介できればと思います。
参考文献(順不同)
[1]ISO 26262:2018 Road vehicles - Functional safety (all parts)
[2]ISO/PAS 21448:2019 Road Vehicles - Safety of the intended functionality (SOTIF)
[3]Safety First for Automated Driving (SaFAD paper) (2019-07)
[4]国土交通省自動車局 自動運転車の安全技術ガイドライン (2018-09-12)
[5]ACEA Strategy Paper on Connectivity (2016-04)
[6]伊藤: 自動車データ活用に関する欧州の動向 JARI Research Journal (2018-05-01)
[7]自動走行ビジネス検討会 自動走行システムにおけるサイバーセキュリティ対策 (2019-06-26)
[8]AV: Bringing Standards Together for Safety, EE Times Asia (2020-04-21)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「AUTOSARを使いこなす」バックナンバー
- ≫連載「AUTOSAR〜はじめの一歩、そしてその未来」バックナンバー
- AUTOSARの最新リリース「R19-11」とは(中編)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第15回では、前回に引き続き、2019年12月に一般公開されたAUTOSARの最新リリース「R19-11」について紹介する。 - AUTOSARの最新リリース「R19-11」とは(前編)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第14回では、2019年12月に一般公開されたAUTOSARの最新リリース「R19-11」について紹介する。 - 日本のAUTOSAR関連開発:マニュアル頼りで大丈夫? 外注化は今のままで持続可能?
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第13回は、第11回と第12回で筆者が提案したAUTOSARに関するスキルや研修に関する取り組みの現状について報告する。マニュアルを基にした運用や外注の活用本当に問題はないのだろうか。 - AUTOSAR人材の育成に向けた提言(後編)「研修」の前提を一緒に見直しませんか?
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第11回では、AUTOSARの人材育成に関わる「研修」の現状について取り上げる。