はじめてのAUTOSAR導入で陥りやすい罠：AUTOSAR～はじめの一歩、そしてその未来（3）（2/3 ページ）

国内企業でAUTOSARを初めて導入する際の典型的パターンは2つある。「AUTOSAR導入準備の初期段階としての試作評価実施」と「量産開発を通じてのAUTOSAR導入」だ。今回は、これら2つのパターンの詳細と、それぞれどういった結末が起こり得るかについての考察を示す。

[櫻井剛（イータス RTAソリューションシニア・コンサルタント），MONOist] PC用表示関連情報

LINE

Hatena

前のページへ | 次のページへ

考察：これらのパターンの結末は

　これらのパターンの結末はさまざまである。通常は途中で問題に気が付くと、何らかの対処が行われるためである。ここでは、前述の通り、内容についての考察は行うが、評価は行わない。初めて体験される方がおいでであれば、以下の項目について、考える時間を少し確保していただきたい。なお、網羅的なチェックリストではないことにもご留意いただきたい^※1）。また、既にいずれかの体験をされた方々は、初体験の方に考える時間を与えていただきたい。

スケジュール見積もり

そもそも、AUTOSARでの開発は初めてなのだから「どんな検討や作業が必要で、それぞれにどのくらいの時間がかかるのか、そこでの不確実性はどの程度か」ということを事前に予測することは難しいのではないか
そのような状態で、プロジェクトにおけるリスクマネジメントの観点での「リスクの特定」^※2）は可能なのだろうか
評価版ライセンスの有効期間内で、果たして必要な評価や準備を全て行うことができるのだろうか
AUTOSARの会員加入手続きと会費は考慮されているだろうか
最初から、完成度の高い（長い寿命を期待した）成果物が要求されていないだろうか。それを作り上げるには、試行的な運用が不可欠ではないだろうか

マイコン評価ボード、コンパイラおよびデバッガ

これらの価格面での節約により、他に影響は出てこないだろうか
決めやすいところから決めてしまうというやり方は、決めにくいところを後で決めるときの選択の自由を奪ってしまわないだろうか

マイコン／コンパイラ選定

マイコンやコンパイラ（およびそのバージョン／オプション）に依存性の高い部分のBSW（MCAL、Os）は、選択しようとするマイコン／コンパイラの組み合わせに対応済みの製品がないのであれば、移植（ポーティング：porting）または新規開発が必要となる
コンパイラ依存性は見落とされがちだが、特にOsにおいてその影響が大きい（前述の通り）。MCALにおいても、細かなタイミングなどの問題から、Compiler Abstractionによりコンパイラ依存性を完全に解消することができるとは限らない
なお、新規開発であれば費用アップ（または割引率ダウン）となるのは当然予想できる。また、BSWベンダーの開発リソースは一般に高稼働率であるため、試作評価用途（＝量産開発用ライセンスの販売見込みが低い）場合には、新規開発を尻込みされてしまっても不思議ではないのではなかろうか

AUTOSAR組み込みソフトウェア製品（RTE／BSW）

MCALとそれ以外を分けて購入したとき、問題の切り分け（MCAL or not）は誰が行うべきであろうか。自身で行わなければならないのではないだろうか
そもそも、MCALは自身のユースケースに合致するのだろうか。「MCALあります」をうのみにしてよいのか
切り分け問題は、ハードウェア設計やマイコンそのもの、コンパイラそのもの、各種ツールそのもの、あるいはAUTOSAR規格そのものなど、多くの要素に関係する。そのような切り分けにおいては、その組み合わせに登場する全てのものを持つ自身が最も良い環境にあるのではないだろうか
ISO 26262では「ASIL D」という情報だけをもとに安全ライフサイクルを回していけるのであっただろうか。ましてや、それだけを要求事項としてBSWベンダーに与えた場合、果たして自身が必要なものを得られるのだろうか

AUTOSAR開発ツール製品（AAT）

AUTOSAR規格により各社ツール間の互換性はある程度確保される。そうなると、重要なのは互換性ではなく、各社のツールの特色が自身のユースケースに合っているか否かではないだろうか
経験上、ユースケースは各社／各開発現場で異なる。そうであれば、自身で多くを試してみる必要はないだろうか
特に量産開発においては「時間」（正確には「残された時間」）が最も高い価値を持つのだが、価値の公式（Value＝Function／Cost）から考えると、最小限のツールを利用することでCostを下げValueを高めるというやり方だけではなく、CostとFunctionの双方に何かを足すことによりやれることを増やして、結果的に価値を高められる^※3）部分もあるのではないだろうか
厳格な予算計画は、よく知っているものを使うときには成り立つかもしれない。なぜなら、排除しきれない予測困難な部分に対しても一定の「カン」(ここでは、主に経験的知識を再利用することによりある程度の精度が保証された予測）が機能するからである。しかし、よく知らないものを使おうとするときに、果たしてそれは機能するのだろうか。また、後にありがたみがわかるものもあるのではないだろうか

AUTOSAR教育／トレーニング

前述の通り、各社／各開発現場で運用が異なる部分は多い。初歩的な内容は定型トレーニングで得られたとしても、実際の運用に関しては議論が必要なのではないだろうか
日本人の性質も考慮に入れる必要はないだろうか。事実として、ダウンロード型のトレーニングの後にQ＆Aが活発となることはごくまれである
ましてや、これだけ複雑かつ大規模なものに対する概要を扱うダウンロード型トレーニングを一度受講しただけで、「受講したのだから、次は周囲に対して教育を」というのは少々無理がないだろうか
規格そのものに対する理解だけであれば、もしかしたら自習でも済むかもしれない。しかし、規格には書かれていない運用面は自習で学べるのだろうか

AUTOSAR開発支援

上記パターンにはいわゆる技術サポートや導入支援などは全く登場していない。実際に、それらを初期に提案したとしても、「今の時点では不要」とされがちだが、その場合は実際に必要になった時（緊急時）に大慌てで追加予算確保に奔走することになるのはほぼ確実である。困った時に手を動かす（いわゆる消火活動）だけではなく、事前にさまざまなアドバイスを求めること（いわゆる防火活動）に対する検討の必要性はないだろうか
導入準備において、「そもそもどのような準備（進め方）が必要か」という初期検討の段階からアドバイスを得ることができたとしたら、より効率的に資源を運用できるのではないだろうか
パターンAでのゴールは、「ASW／RTE／BSWのインテグレーション作業をできるようになる」というように表現することもできるのだが、それ以外にも、重要な準備はたくさんあるのではないだろうか（プロセス整備、プロセステーラリング、各種手順の自動化など）

注釈

※1）JIS Q31010：2012 リスクマネジメント－リスクアセスメント技法においては、チェックリストに対して「リスクの特定において、想像力を妨げる傾向がある」という弱点が指摘されている（B.4.6）。ここであえて意図的に書き出していないものが多数あるのは、このような背景があるからである（本来は箇条書きにもしたくはなかった）。なお、JIS規格は日本工業標準調査会（JISC）のWebサイト（http://www.jisc.go.jp）で閲覧可能（ただし国内からのアクセスに限定）。また、JIS Q31010：2012は、IEC/ISO 31010：2009 Risk management - Risk assessment techniquesと一致する。全般に、JIS規格の内容は、国際規格（ISOおよびIEC）の内容に一致するように改定が進められている（WTO／TBT協定による）。

※2）JIS Q31000：2010 リスクマネジメント－原則及び指針参照。なお、JIS Q31000：2010は、ISO 31000：2009 Risk management - Principles and guidelinesと一致する。

※3）必要最低限のものと、より良くするためのものは異なる。なお、価値の公式V＝F/Cにおいて、FとCの瞬時値だけでVを評価するのであれば、時間をかけて回収するような性質のものに価値はないことになってしまう。これではソフトウェアの再利用の効果を議論することはできない（再利用の効果は、再利用機会を得ることで確保される）。従って、FもCも時間積分で考えるべきであり、それを示すためにV＝∫f（t）dt/∫c（t）dtとし、かつ寿命や期限も考慮して積分区間を明示すべきであろう。とはいうものの、そんなことは百も承知で「待つ余裕はない」と言わざるを得ない方々のお立場も良く分かるのだが……。