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