当然のことであるが、開発すべきものは、本質的にはどのようなものか? どのようなことが重要なのか?という判断が随所で必要となる。
その過程においては、ある目的のためにこれまで取ってきた手段を、AUTOSARではそのまま実現できない可能性もある。そのため「これまではこのようにやってきたから、AUTOSARでも同様にする」というような、“手段”に相当するものを基本に置いた考え方ではなく、“目的”のためにAUTOSARの何が利用可能か、そして、何が不足かということを一歩引いて見渡していくことも時には重要である。特に、従来可能だった手段がAUTOSARでは提供されない場合、代替手段を探さずに拡張し続けるとAUTOSARの標準規格としての利点を得にくくなってしまう恐れもあるので注意されたい(対応するAUTOSARのWork Packageに機能追加の提案を行うことが可能な間に、それを行うのが最もきれいな形である)。
また、開発すべきものと、そこで利用するもののそれぞれが、本質的にどのようなものか? そして、どのように利用していくか? という問いに対する答えを出す体制を早く整える必要がある。例えば、製品提供者は製品知識、応用開発者は応用知識を持ち寄るような体制とすることも効果的である。特に、前回述べたように、AUTOSARは汎用性は高いが万能ではないため、カバーされない範囲の制約に対する対処を考える上では必須といってもよい。
AUTOSARには、多くの期待が寄せられている。しかし、いつかは実現されるものであっても現時点では残念ながら「適切とは限らない理解や期待」にとどまっているものも少なくはない。
しかし、「適切な期待」は確かに存在する。そのすべてをここで解説することは、紙幅の都合で不可能ではあるが、例として、「開発期間の短縮」を取り上げ、その具体的な内容について幾つか紹介する。
以上、3回にわたって「実際にAUTOSARに移行(migration)していくに当たって理解しておくべきこと」に関するヒントをお届けした。
冒頭でも述べたが、残念ながら万能な解は存在せず、具体的な対処は、個別の要件、つまり、使用する製品や規格そのものに関するものと、応用に関するものの両方を考慮しながら決めていくこととなる。もちろん、実際の個別の応用に関しては、言うまでもなく、皆さんの方が圧倒的に多くの知識をお持ちであるが、AUTOSARそのものについての知識も必要となる。AUTOSARの規格自体を1人ですべて把握することは、非常に困難だが、既に、大規模なものに取り組む際には、外部リソースを利用することが一般的になっている。外部の知識を「プラグイン」として組み合わせ利用していくことで、「あなたにとってのAUTOSARとは?」の確立が容易となるだろう。
今回紹介した内容は、ごくわずかなヒントでしかないが、AUTOSARの導入に当たっての苦労を減らし、期待したものを早期に得るための一助となり、最終的に、「早く家に帰れるようになる」ということにつながれば幸いである。(連載完)
関連リンク: | |
---|---|
⇒ | AUTOSAR適用の「現実解」を提供するベクターの役割 |
Copyright © ITmedia, Inc. All Rights Reserved.