What is “AUTOSAR”／AUTOSARとは？：AUTOSARとは？（1）（1/2 ページ）
車載ソフトウェアの標準仕様「AUTOSAR」への移行・適用に当たって、実際に理解しておくべきポイントやヒントを整理して詳しく紹介する
はじめに
車載組み込みソフトウェア開発に携わる方の多くにとっては、「AUTOSAR」の名前は、すでに親しみのあるものか、あるいは、少なくとも一度は耳にしたことがあるものではないだろうか？
実際に、おととしから昨年にかけて、量産開発の現場でAUTOSARが利用される機会は大幅に増え、筆者が所属するベクター・ジャパン（以下、ベクター）でも、多くのお問い合わせと実際のビジネスの機会をいただいている（まさに、うれしい悲鳴を上げている状態である）。
⇒「AUTOSARとは？／What is AUTOSAR？−2015年版−」はこちら
しかし、その導入に当たっての、お客さま側での事前の予想と現実には“大きなギャップ”があるようで、
予想以上に、準備が大変だった。
単にモジュールを入れ替えるくらいだと思っていたが、実際には大違いだった。
などの声が多く寄せられている。その結果、特に、納期に間に合わせるためのサポートでは、お客さまと一緒につらい悲鳴を上げざるを得なくなる場合も少なくない。
また、これからAUTOSARを導入しようとするお客さまからは、
仕様書の内容を、本当に全部やらなければならないの？
そもそも、仕様書を読んだだけでは、どんな準備が必要なのかを想像しようがない。
という不安をぶつけられることも多い。今後も、日本国内でのAUTOSARの本格的な利用がますます増えると予想されるが、つらい悲鳴や不安はできるだけ減らしていきたいものである。
ベクターでは、AUTOSAR導入に当たって必要となる準備の内容などに関する情報を、これまでにも、2007年ごろから各種セミナー／トレーニングや配布資料などの形で提供してきたが、今回、幸いにして＠IT MONOistでの執筆の機会をいただくことができた。本連載では、「実際にAUTOSARへ移行（migration）するに当たって理解しておくべきこと」に関するヒントを中心に、全3回に分けてあらためて整理していきたい。
| 関連記事： | |
|---|---|
| ⇒ | AUTOSAR適用の「現実解」を提供するベクターの役割 |
背景および課題
たとえ同じ仕様書に基づく同一機能であったとしても、アプリケーション部分のソフトウェアの「実装」は、開発を手掛けるECUサプライヤーごとに、それぞれ別なものになってしまう（これは特に珍しいことではない）。
こうした場合、実装と評価の作業（場合によっては、さらに仕様詳細の擦り合わせ作業）の重複が発生してしまう。もちろん、それを防ぐために、仕様書だけでなく、自動生成のためのモデルやソフトウェアのコードをセットで配布することも実際に行われている。
しかし、マイコン性能に応じた対処や、ソフトウェアプラットフォーム（あるいは土台部分）とのインターフェイスの合わせ込みのためのコード書き換えなどの理由により、ECUサプライヤー側での組み込み作業工数が当初予想よりも多く掛かることも少なくはない。
そもそも、ECUの構造は自動車業界全体で共通の認識が存在しているとはいい難い。
ソフトウェアの土台部分についても、自動車メーカー側から指定されたものを使用するというケースがすでに一般的であるが、ECUサプライヤー各社が独自に用意し、各自動車メーカー向けに合わせ込みを行うケースもまた一般的である。
そのため、さまざまなモジュールを統合して正しく動作させるためのいわゆる「インテグレーション」の作業では、自動車メーカーにより指定される土台部分の相違などによって、アプリケーション部分と土台部分との関係（接続方法や機能的な分担など）に関する予想外の重複や隙間への対処が必要となってしまうこともある。当然、当初から想定している事態ではないため、対処のためにごく限られた時間しか割くことができないということもあり得る。このことは、たとえ、モデルベース開発がすでに一般的であって、かつ、その都度ソフトウェアを新規開発するよりも、各種パラメーターの適合などを行う比率が高いというような分野であっても、同様である。
また、構造や土台における相違は、複数の自動車メーカー向けにECUを供給しようとする場合の障害の1つにもなっている。もちろん、いくら汎用のものであったとしても、最終的には個別の要求に合わせ込まなければならない。そして、いうまでもなく、広い範囲で使うことができるという汎用性と、それを利用するうえで必要とされる資源やコストとの間には、一般にトレードオフの関係があるため、個別のケースでの利用可能な資源やコストに関する要求が厳しい自動車分野では、「いかなるケースにも適用可能な汎用品」が常に利用可能であると期待することはできない。
そもそも、「個別の要求への合わせ込み」は、汎用製品を利用あるいは提供し続けていくうえでの永遠の課題でもある。構造や土台における相違は、その上に載せるものにいかに広い汎用性を持たせるか、ということを考えるうえで、「周囲の状況として想定すべきもの」を特定しにくい状況を生み出している。
量産後も、新機能追加、あるいは、より安価な電子部品への切り替えといったことも、「ソフトウェア」に関連する「制約（実装内容の変更や再インテグレーションの工数など）」により、さほど自由に行うことができるわけではない。
このように、ソフトウェアの開発においては、実装やインテグレーション、評価など多くの段階で多数の課題が存在している。
さらに、自動車に搭載される機能は年々高度になり、それを実現するためのECUの数やそれぞれの複雑さ、開発規模が大幅に増大している。さらに、マイコンなどの電子部品の世代交代サイクルが短くなる中で、車両のライフサイクルがさまざまな要因によってむしろ長くなる傾向が見られるなど、開発を取り巻く環境においても、対処が必要な課題は多く存在する［1］。
これらの例を含む現在の自動車業界の技術面の課題に対しては、企業単位でのさまざまな取り組みだけではなく、OSEK/VDX［2］やHIS［3］などの団体によるソフトウェア関連の標準化が進められ、多くの成果を残してきた。
そして、2003年に設立された開発パートナーシップであるAUTOSAR［4］では、従来の成果を利用しつつ、
Cooperate on standards, compete on implementation
（標準化においては協力、実装／利用にて競争）
のスローガン［5］の下で、自動車業界全体にさらに範囲を広げて標準化に取り組んでいる。この活動には、自動車分野にかかわる世界各国の多数の企業など（自動車メーカー、ECUサプライヤー、マイコンベンダ、ツールベンダ、ソフトウェアベンダや研究機関ほか）が、さまざまな形で参加している。
AUTOSARの仕様書は、2005年発行のRelease 1.0からすでに多くの版を重ねており、2011年1月現在での最新はRelease 4.0である。また、Release 3.0から急速に量産車開発への適用が進んでおり、現在はRelease 3.x（Release 3.1など）が主に利用されている［6］。
技術面の概要
AUTOSARでのECUソフトウェアは、大きく分けて、3つの部分から構成される。その構造を図1に示す。
一番下の、AUTOSARベーシックソフトウェア（Basic Software：BSW／詳細は図2）は、簡単に表現するならば、「どの自動車メーカー向けの、どのECUサプライヤーが作った、どの種類のECUにでも入っている、土台部分の基本ソフトウェア」であり、OS、通信スタック（CAN、LIN、FlexRay、Ethernetなど）、不揮発性メモリスタック、診断、入出力、モード管理などの各種機能を提供するソフトウェアモジュール群から構成される。
なお、ソフトウェアアーキテクチャ上、ハードウェア依存となるものは、マイコンに固有のMCAL（Microcontroller Abstraction Layer／図2のGPTドライバからPORTドライバまでのBSWの一群）、OSおよびComplex Driverと、マイコンに外部接続されるデバイス用のドライバのみである。これ以外はハードウェア非依存であるため、ハードウェア変更に伴う影響を局所化することができる。
一番上の、個別のECUの機能を実現するためのアプリケーションレイヤの部分は、通常複数のソフトウェアコンポーネント（Software Component：SW-C）から構成される。
ある機能を実現するために、車両内の複数のECUが関係することはすでに珍しくないが、車両を1つのシステムと見たとき、センサを監視する入力部分、アクチュエータを操作する出力部分、そして、その間の演算部分の3つの部分に分けることができる。そして、それぞれに対応するSW-Cの間は、「Port」により接続される（注：ここでのPortは、入出力ポートや、BSWのPORTドライバとは異なる）。
SW-Cは、機能を実現するために必要なセンサ、アクチュエータ、ROM／RAMなどの資源と、時間制約を考慮したうえで、それぞれのECUに割り付けられる。この割り付けにより、Port間の通信がCAN通信用BSWなどを利用したECU間通信になるのか、あるいは、ECU内通信になるのかが決まる。その際に、SW-Cそのものには一切手を加える必要がないように、あたかも電話交換機のようにつなぎ替えてくれるのが、RTE（Runtime Environment）の主な役割の1つである。このことにより、アプリケーションレイヤのトップダウン型開発が、従来よりも容易となる。
また、SW-Cの実際の処理は、周期イベントなどの各種イベント発生時に実行される処理である「Runnable Entity」により実現される。このRunnable EntityをOSのタスクとして構成するのも、RTEの役割である。RTEの概要を図3、4に示す。
なお、BSW／RTEともに、実装依存の部分は少なくなく、また、実用面あるいは特定用途の要求に合わせるための仕様拡張もしばしば行われている。従って、同じ仕様に基づく製品であっても、品質や実装方法だけではなく、機能面でも相違がある可能性があることに、注意が必要である。
また、AUTOSARでは、上記のようなソフトウェアアーキテクチャだけではなく、データ交換形式の標準化も行っている。これは、設計資産の利用可能期間をできるだけ長くしたり、インテグレーション作業の自動化の範囲を広げたりするうえで、非常に重要なものである。AUTOSARではXMLを利用した標準データ交換形式を規定しており、そのうち、特に重要なものを以下に示す。
Copyright © ITmedia, Inc. All Rights Reserved.