量産開発を通じてのAUTOSAR導入はどのように進めるべきか：AUTOSAR〜はじめの一歩、そしてその未来（5）（1/3 ページ）

AUTOSARを初めて導入する際の、もう1つの典型的パターンが「量産開発を通じてのAUTOSAR導入」になる。この「量産開発を通じてのAUTOSAR導入」は2つの部分に分けることができる。今回はそのうちの1つ、「量産開発プロジェクトを完了させる」について説明する。

[櫻井剛（イータス RTAソリューション シニア・コンサルタント），MONOist]

　今回は、連載第3回で説明したパターンB、つまり「量産開発を通じてのAUTOSAR導入」の進め方について説明する。まずここでは、具体的な活動や準備内容の詳細に踏み込む前に、「量産開発を通じてのAUTOSAR導入」という言葉について少し見ていきたい。

　この言葉は2つの部分に分けることができる。1つは「量産開発プロジェクトを完了させる」であり、もう1つは「AUTOSAR導入により、基本的な型や支援体制をどのように変えていくかの見極めと必要な活動の実施」である。

「量産開発プロジェクトを完了させる」

　これも多くの意味^※1）を持つが、ECUソフトウェアレベルのインテグレーション、つまり、与えられた設計情報（供給されるSW-Cや各種データなどを含む）を基に、ECUソフトウェアを構築するということは、その代表的な活動の1つであろう。

　その実施に関する議論も単純なものではない。そもそも、量産開発プロジェクトは、プロジェクトごとに全くの新規で開始されることはほとんどない。「基本的な型や支援体制」＋「プロジェクト固有のあわせこみ」^※2）により実現されるのが一般的だ。しかし、前者がAUTOSARに対応していないのであれば、これまではほとんど意識せずにいることができた、それによりもたらされる「当たり前のことを当たり前にできることのありがたさ」に頼ることができる部分は相対的に減り、かわりに後者すなわち「新たな状況への対応」の比率が増えることとなる。

　では、具体的にはどのような対応が必要になるのだろうか。また、AUTOSAR導入により肩代わりされることや、新たに行わなければならなくなることも特定していかなければならない。新たな状況への対応の比率が増えるのであれば事前に特定できるものばかりではない。しかし、失敗の許されない量産開発プロジェクトでリスクを抑えるためには、たとえ時間がかかったとしても、このような「特定」という作業が不可欠となる^※3）。

　ECUソフトウェアレベルのインテグレーション作業については、AUTOSAR TR Methodologyにて「Integrate Software for ECU」として記述されている。ここでは、その内容を見てみよう。

ECUソフトウェアレベルでのインテグレーション

　AUTOSARベースでのECU開発のワークフローは、AUTOSAR TR Methodologyと呼ばれる文書にて解説されており、SPEM^※4）と呼ばれる記法のサブセットを用いて記述されている。そのワークフロー概要を図1に示す。

図1　AUTOSAR Methodology概要−ワークフロー（クリックで拡大） 出典：AUTOSAR R4.2 Rev.1 TR Methodology, Figure 2.2相当, AUTOSAR_MMOD_MetaModel.eapより作成

　図1における最終段階が、ECUソフトウェアレベルでのインテグレーション作業「Integrate Software for ECU」である。その内容を図2および図3に示す。これがECUサプライヤーにおけるECU開発作業の中心な部分となるため、「導入準備」もここを中心に行うこととなるが、AUTOSAR規格に記述されている内容だけではなく、それ以外に必要となる作業も含めて検討すべきである^※5）。

図2　AUTOSAR Methodology - Integrate Software for ECU Overview（クリックで拡大） 出典：AUTOSAR R4.2 Rev.1 TR Methodology, Figure 2.34相当, AUTOSAR_MMOD_MetaModel.eapより作成）

図3　AUTOSAR Methodology - ECU Configuration Overview（クリックで拡大） 出典：AUTOSAR R4.2 Rev.1 TR Methodology, Figure 2.35相当, AUTOSAR_MMOD_MetaModel.eapより作成

　図3ではこのうち基本となる「Prepare ECU Configuration→Configure BSW and RTE→Generate BSW and RTE」という基本の流れが示されている。また、図2に含まれるが図3には登場しないModel ECU Timing （図4）は、Configure BSW and RTEを開始後に実施されるが、それにより生み出されるoutputであるECU Timingは、Configure BSW and RTEの中のConfigure OS、Configure RTE、Configure Watchdog Manager、および、Create Service Componentでも参照されることから、相互参照しながら進められる作業であることが分かる^※6）。

図4　AUTOSAR Methodology - Model ECU Timing（クリックで拡大） 出典：AUTOSAR R4.2 Rev.1 TR Methodology, Figure 2.39相当, AUTOSAR_MMOD_MetaModel.eapより作成

注釈

※1）当然ながら、開発のライフサイクルは量産開始で終わるのではない。品質や安全性の担保、必要に応じての変更への対応、最終的な収支など他にも考慮しなければならないことは、これまで通り多数存在する。しかし、ここではAUTOSAR特有の要因が多く含まれるECUソフトウェアレベルのインテグレーションを特に取り上げた。

※2）ISO/IEC 15504-2:2003/Cor.1:2004におけるプロセス面での議論に置き換えて考えると、Level3での要求事項の1つであるPA3.1の「standard process」が基本的な型や支援体制、「tailoring」がプロジェクト固有のあわせこみに対応する。

※3）リスクマネジメントの観点からも、まずは特定が重要である。JIS Q31000：2010 リスクマネジメント−原則及び指針参照。なお、JIS Q31000：2010は、ISO 31000：2009 Risk management - Principles and guidelinesと一致する。

※4）Software＆Systems Process Engineering Meta-Modelのこと。Object Management Group（OMG）により開発されたものである。http://www.omg.org/spec/SPEM/2.0/

※5）もちろん、「導入準備」という言葉が意味する具体的な内容は自動車メーカー側では異なるものとなるだろう。しかし、ECUサプライヤ側の準備内容を把握することは、自動車メーカー側でも有用である。

※6）なおAUTOSAR TR Methodologyにおいて一般に、このような前後関係は各Activity／Taskの定義表にて「Predecessor」として示されるが、実際には、示されていなくとも表のProducesで示されるoutputが、他のActivity／Taskのinput（表のConsumesで示されるもの）となっている場合も多数ある。この非常に入り組んだ前後関係は、AUTOSAR TR Methodologyを部分的に見ても判別しにくく、また、AUTOSAR_MMOD_MetaModel.eapにおいても十分にモデル化されていないことに注意が必要である。