AUTOSAR導入初期段階における試作評価の適切な進め方AUTOSAR〜はじめの一歩、そしてその未来(4)(4/4 ページ)

» 2015年10月01日 09時00分 公開
前のページへ 1|2|3|4       

組み込みソフトウェア

・スタートアップコード
 案外見落とされがちだが、この部分はAUTOSARではカバーされない範囲である。特に近年はマイコンが複雑になっており、bus/clock/電源/MPU設定などには相当な時間がかかる。私の感触では、10年前の数倍以上かかるようになったと感じている。

・ASW
 幾つかの自動車メーカーは、自社の車両電気電子プラットフォーム上のどのECUにでも共通な部分をSW-Cとして提供しているので、量産開発時にはその入手が必要となることもある。試作時に入手できるとは限らないが、それがなくとも開発ができる部分も多数存在する。最初から全てを用意しなければならないわけではない、という良い例である。

・RTE/BSW
 ETAS製品であれば、用途に応じて「RTA-BSW」(「RTA-OS」含む)や「RTA-RTE」、PC上のシミュレーションのための「ISOLAR-EVE」が該当する。自動車メーカー側から指定あるいは推奨リストが出てくることもあるが、それ以外を認めるか否かなどは各社で違いが大きい。また、再利用を前提とした組み込みソフトウェアの評価において、評価指標の選定は極めて難しい。例えば、ハードウェア依存性の有無により再利用機会は大きく変わるので、必要に応じて評価指標のセットを使い分ける必要も出てくるであろう。

・ハードウェア非依存
 動作を単体では評価することはできない。ハードウェア依存のものと組み合わせ、設定を行った上での動作となることに注意。言い換えれば、動作は他の構成要素に依存する。

・ハードウェア依存
 Os/MCALや外付けデバイス用ドライバ(EEPROMやCANトランシーバなど)。Compiler依存性に要注意。ISOLAR-EVEのような、PC用のOs/MCALも有用。「今用意できるもので着手できる作業を見つけ出す」「○○ありますという言葉の意味をきちんと確認する」ということが秘訣(ひけつ)である。

・Flash Bootloader
 RTE/BSWと同様。なお、Flash BootloaderはAUTOSARではカバーされない。

 また、十分に練られた計画は必須である。ゴール、評価したい内容、実現したい機能など(ここまでやる、可能であればさらにここまでやる)、計画見直しタイミング/条件、既存ソフトウェア/ツール資産(レガシー)の取り扱いなどの制約事項をはっきりさせなければ、その計画はすぐに見直さねばならなくなってしまうだろう。手戻りの発生を完全に防ぐことはできないが、少しでも抑えるためには、よきアドバイザー※10)に助けを求めることは、有用であろう。



 またもや字数が当初予定を大幅にオーバーしてしまったため、「パターンB」、つまり「量産開発を通じてのAUTOSAR導入」の進め方については、次回以降にご期待いただきたい。なお、「評価の際に必要なもの、有用なもの」として挙げたものは、量産開発においても同様に必要または有用となるものである。

注釈

※10)なお、レビューで妥当性の判断とその根拠の説明を行うことができることは、最低の必須条件であろう。一度や二度経験しただけでは、十分とはいえない。


お知らせ

 筆者が現在所属するイータスでは、AUTOSARをはじめ車載ソフトウェア開発に関する「よろず相談会」を随時開催しています(要事前予約、初回無料)。詳しくは、申し込み用Webサイトまで。


【筆者紹介】
櫻井 剛(さくらい・つよし) イータス株式会社 RTAソリューション シニア・コンサルタント
2014年よりイータス株式会社。ECU開発(1998年〜)やAUTOSAR導入支援(2006年〜)における経験を生かしし、2015年現在、AUTOSARに関する全般的な支援業務、および、機能安全を含むシステム安全に関する研究に従事。修士(工学)およびシステム安全修士(専門職)。
イータス株式会社
http://www.etas.com/ja/


前のページへ 1|2|3|4       

Copyright © ITmedia, Inc. All Rights Reserved.