　ベクターでは、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］。

［1］財団法人自動車検査登録情報協会：わが国の自動車保有動向 http://www.airia.or.jp/number/index2.html（last access：20110124）、社団法人電子情報技術産業協会：自動車用半導体補給部品供給の円滑化に向けて http://semicon.jeita.or.jp/news/docs/050328.pdf（last access：20110124）など。

［2］Offene Systeme und deren Schnittstellen fuer die Elektronik im Kraftfahrzeug. http://www.osek-vdx.org/（last access：20110124）

［3］Herstellerinitiative Software. http://www.automotive-his.de/（last access：20110124）

［4］AUTomotive Open System ARchitecture. http://www.autosar.org/（last access：20110120）

［5］AUTOSAR Release 3.1 Technical Overview 仕様書 sec. 1.4

［6］量産での採用実績に関しては、ベクターのダウンロードセンター http://www.vector.com/vj_downloadcenter_jp.htmlから入手可能な各種プレスリリースなどをご覧いただきたい

技術面の概要

　AUTOSARでのECUソフトウェアは、大きく分けて、3つの部分から構成される。その構造を図1に示す。

図1　AUTOSAR ECUソフトウェアの構造
※画像提供：ベクター・ジャパン

　一番下の、AUTOSARベーシックソフトウェア（Basic Software：BSW／詳細は図2）は、簡単に表現するならば、「どの自動車メーカー向けの、どのECUサプライヤーが作った、どの種類のECUにでも入っている、土台部分の基本ソフトウェア」であり、OS、通信スタック（CAN、LIN、FlexRay、Ethernetなど）、不揮発性メモリスタック、診断、入出力、モード管理などの各種機能を提供するソフトウェアモジュール群から構成される。

　なお、ソフトウェアアーキテクチャ上、ハードウェア依存となるものは、マイコンに固有のMCAL（Microcontroller Abstraction Layer／図2のGPTドライバからPORTドライバまでのBSWの一群）、OSおよびComplex Driverと、マイコンに外部接続されるデバイス用のドライバのみである。これ以外はハードウェア非依存であるため、ハードウェア変更に伴う影響を局所化することができる。

図2　AUTOSAR ECUソフトウェアの構造（BSW詳細）
※画像提供：ベクター・ジャパン

　一番上の、個別の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に示す。

図3　AUTOSAR Runtime Environment（RTE）－SW-Cの割り付け例（1）
※ベクター・ジャパンの資料を基に作成

図4　AUTOSAR Runtime Environment（RTE）－SW-Cの割り付け例（2）
※ベクター・ジャパンの資料を基に作成

　なお、BSW／RTEともに、実装依存の部分は少なくなく、また、実用面あるいは特定用途の要求に合わせるための仕様拡張もしばしば行われている。従って、同じ仕様に基づく製品であっても、品質や実装方法だけではなく、機能面でも相違がある可能性があることに、注意が必要である。

　また、AUTOSARでは、上記のようなソフトウェアアーキテクチャだけではなく、データ交換形式の標準化も行っている。これは、設計資産の利用可能期間をできるだけ長くしたり、インテグレーション作業の自動化の範囲を広げたりするうえで、非常に重要なものである。AUTOSARではXMLを利用した標準データ交換形式を規定しており、そのうち、特に重要なものを以下に示す。

・System Description：

車両システム全体の設計情報。

・ECU Extract of System Description（EcuEx）：

System Descriptionのうち、特定ECUに関係する情報のみを抽出したものであり、自動車メーカーとECUサプライヤーの間の設計情報授受の媒体として使用される。なお、従来、CANネットワークに接続されるECUの開発では、DBCファイルがその媒体として一般的に使用されてきた。EcuExは、それを置き換え、さらに、多くの情報が記述可能なものである。

・ECU Configuration Description（EcuC）：

ECU上のSW-Cの情報や、RTEやBSWの設定情報などが含まれる。

・Software Component Description（SW-C Description）：

SW-Cに関する設計情報。PortやRunnable Entityに関する情報や、どのBSWのどの機能を利用するか、などが含まれる。

・Basic Software Module Description（BSWMD）：

各BSWの設定項目などの情報。

　　　　　　 1|2 次のページへ