AUTOSAR導入初期段階における試作評価の適切な進め方：AUTOSAR〜はじめの一歩、そしてその未来（4）（4/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導入」の進め方については、次回以降にご期待いただきたい。なお、「評価の際に必要なもの、有用なもの」として挙げたものは、量産開発においても同様に必要または有用となるものである。