欧州の車載ソフトウェア標準規格であるAUTOSARに準拠したリアルタイムOS（RTOS）「TOPPERS/ATK2」のマルチコアプロセッサ対応版が、2013年6月からTOPPERSプロジェクトを通じて一般公開されるという話だ。
そして、「TOPPERS/ATK2」を開発したATK2コンソーシアムでは、RTOS仕様の策定とそれに基づくATK2の開発に加えて、ATK2向け検証スイートの開発、要求タグを付与することで仕様のトレーサビリティを確保できる設計書の作成や、AUTOSAR仕様をベースとした通信ミドルウェアおよびRTE（Run-Time Environment）ジェネレータの開発も行っているという。
ソフトウェアに要求タグを付けて、要求からプログラムソースをトレースできるようにするというアイディは、かつてNASAのベテランソフトウェアエンジニアが行っていたテクニックであったと広島市立大学の大場充先生が言っていた。
それは非常のよいアイディアだと思う。要求に変更があったときに、そのタグを頼りにどの部分のプログラムを直せばよいのかが分かる。
また、「TOPPERS/ATK2」はAUTOSARの仕様に準拠したRTOSのテストスイートであるAKTSP（Automotive Kernel Test Suite Package）が用意されており、テストパターンに仕様の要求タグをつけて、実施するテストを選択できるようになっていると言う。
このように RTOS のようなソフトウェアシステムの心臓部に使われる OTS（Off The Shelf)ソフトウェアのテスト環境がRTOSのDistributor から供給されることは利用者側からも歓迎されることだ。
自分も Tech Village で『クリティカル・システムに使う市販ソフトウェアの検証方法』という記事を書いているので是非参考にして欲しい。
ところで、AUTOSAR の名前は知っていたが、詳しいことは分かっていなかったので、MONOist の記事『AUTOSARで変わる車載ソフトウエア開発』をじっくり読んでみた。2009年の記事なので今ではここに書いてある内容よりももっと進んでいるのだろう。
【『AUTOSARで変わる車載ソフトウエア開発』より引用】
自動車の電子化の進み具合は、いくつかの指標で表現することができる。その指標の1つとして用いられるのが、搭載されるECU（電子制御ユニット）の数である。
ECUの搭載が始まった1980年代初頭は2～3個程度だったが、現在は100個以上ものECUを搭載する高級車も存在する。基本的に、それらのECUは、ある1つの自動車システムを制御するために最適化されたハードウエアと車載ソフトウエアから構成されている。各ECUは、ほかのシステムを制御できるような汎用的な作りにはなっていない。例えば、エンジンの燃焼タイミングを制御するエンジンECUは、ステアリングやメーターなどほかのシステムの制御を行うことはできない。【引用終わり】
ようするに、専用のECUを汎用のベースプラットフォーム+アプリケーションソフトウェアという組合せに変えて行こうという取り組みだ。
ザイリンクスがARMベースのワンチップマイコンとFPGAを合体させて、１個のチップで何でも自分達の好きな形に SoC を作り替えることができる Zynq-7000 All Programmable SoC を提供している。AUTOSARの取り組みにはぴったりのプラットフォームだと言えるだろう。
ただ、この流れが進んだときに浮かび上がるリスクが自分には見える。
ハードウェアが汎用化され、外からはよく見えないソフトウェアが自動車の価値の多くを担うようになったときの落とし穴だ。
プロセッサの処理能力はどんどん上がり、ハードウェアで処理させたい機能はFPGAのIPにやらせればよいという選択ができるようになってきた。
そうなるとソフトウェアの複雑度と規模はますます上がり、安全に関するリスクの高いソフトウェアモジュールとそうでもないソフトウェアモジュールが混在することが当たり前になってくる。
機能ごとにECUが分かれていた時には、物理的にモジュールの分離ができていたが、今度はソフトウェアの世界でのモジュール分離が重要になってくる。
それ故に『AUTOSARで変わる車載ソフトウエア開発』の記事の中でも、アーキテクチャベース開発の重要性が書かれており、この流れ自体は望ましい。
しかし、『AUTOSARで変わる車載ソフトウエア開発』の記事の中にも触れられていないのは、自動車への要求の多様化がもたらすソフトウェアの安全性へのインパクトと、そのリスクを防ぐために必要なリスク分析や安全のためのアーキテクチャについてである。
AUTOSAR のようなプラットフォームの汎用化に伴い、アプリケーションソフトウェアの分離の重要性が増し、かつ、さらなる自動車ソフトウェアへの要求が多様化することによる Systematic Failure のリスクとその対策のことについてもっとよく考えた方がよいと思うのだ。
そのためには、ISO 26262 に象徴されるようなプロセスアプローチを前面に押し出すのではなく、アーキテクチャベース開発の前段階における 要求分析、リスク分析、リスクアセスメント、リスク対策にフォーカスしなければならない。（プロセスアプローチの重要性は変わらない）
ソフトウェア安全分析・設計セミナには、多数の自動車系サプライヤの皆さんに参加申込みしていただいているのだが、なぜが自動車OEM（メーカ）さんからの参加が少ない。自動車のエンドユーザーのリスクと直接向き合わなければいけない自動車OEM（メーカ）さんからも是非参加してもらい、要求の多様化に伴うソフトウェアリスクのインパクトについて一緒に考えて欲しい。
ちなみに、7/19の回では、自動車以外のドメインの方々の参加も増えてきている。（ほんとにいろいろだ）
セミナでは、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、暖房システムモデル、緊急操舵回避支援システムなどの具体例を使って、できる限り何をしなければいけないか、どんなスキルを身につけなければいけないのかを実感できるケーススタディをするつもりだ。
2012年のSESSAME Workshop 「次世代組み込みエンジニア活性化計画」～これからの10年を考える～の時だったと思う。「セーフティ・クリティカルな製品を開発する技術者は、安全の責任を負う必要がある。」という発言をしたところ、「人の命に関わる製品の仕事には絶対就きたくありません。」と会場にいた学生さんが言った。
そのとき、この人は人の命に貢献する製品を作ることができたときの喜びを想像できないのかもしれない、もったいないなと思った。
安全・安心を担保しながら人の役に立つ物を作って喜んでもらえたとき、技術者としてやってきて良かったと思う。
超えなければならないハードルも高いが、達成できたときの喜びも大きいのだ。脇道から行くのではなく、がっつり正面から組み合って結果を出す感じかなあ。
0 件のコメント:
コメントを投稿