1April 2014

Technical Article

専用のソフトウェアツールで AUTOSAR ECU の設定をスムーズに

「単純なCAN ECU」があったのは過去の話です。今日では1つのECUがAUTOSARベーシックソフトウェアの機能を多数利用し、複雑なタスクを実行するのが一般的です。ただし、機能が多ければ設定のプロセスはそれだけ難しく、その範囲も大きくなります。ツールの助けがなければ、開発者は窮地に陥るかもしれません。

ソフトウェアツールはどう役立つのか

AUTOSAR仕様は非常にダイナミックな進化を続けています。新リリースには毎回、既存のBSWモジュールの機能変更や新モジュールの定義といった変更が加えられ、それらのモジュールのそれぞれに、独自の設定パラメーターが存在します。しかし、AUTOSARの設定では、モジュール構造とパラメーターを形式的に記述するアプローチが取られるため、このようなダイナミックな進化にも根本的に対応でき、その結果、供給するBSWに含めるBSWMD (Basic Software Module Descriptions) をスピーディーに、そして容易に定義することが可能になります。この形式に従う方法は一見、ツールにとっては魅力あるアプローチのように思えます。ツールメーカーはそこそこの手間をかけて汎用的なツールを開発し、後はすべてのパラメーター、すなわち現時点における既知のパラメーターと、将来登場するパラメーターの全部を個別に設定できるようにすればよいのです。ただし、そこから先をサポートしてくれないエディターでは、必要になる何千というパラメーターを設定する気にはなれません。

専用エディターと支援機能

この作業を省力化してくれるソフトウェアツールを開発するには

ECUの設定は、次の3つの因子が関与することで複雑化しています。

> 標準化の拡大現在では、ECUソフトウェアの大半がAUTOSARによるベーシック

ソフトウェアの形で標準化されています。ただし、「実装ではなく設定で」というAUTOSARの原則により、開発者にはスタートの段階から一貫性のある全体的な構成を作ることが求められます。ベーシックソフトウェアのコードに直接修正を加えることはできません。

> 機能の増加複数のコアとメモリー保護機能を持つ新しいマイクロコント

ローラーと、Ethernetをはじめとする新しいネットワークが登場したことで、ベーシックソフトウェアのスコープが広がり、設定のニーズも増加しています。

> 新しい協力モデルAUTOSARの手法では、開発プロセスにおける新たな役割分担が推

奨されています(図1)。ここにはAUTOSARベーシックソフトウェアのサプライヤー (TIER2-BSW) の他に、アプリケーションソフトウェアのコンポーネントのサプライヤー (TIER2-SWC) と、ハードウェアに関連するマイクロコントローラー抽象レイヤーモジュールのサプライヤー (TIER2-MCAL) が存在します。これは、設定プロセスの最初の段階で、関係者の連携に一層の努力が必要になることを意味します。

2April 2014

Technical Article

さまざまなアプローチがあります。専用に開発されたエディターでは、パラメーター同士の関係の表示や、バルク操作などによる設定プロセスの簡素化が可能です。さらに、そういったエディターでは、別モジュールのパラメーターも含めて、パラメーターをテーマ別にグループ化できます。また、エディターのグラフィック表示機能により、複雑な設定もより簡単に理解できます。このようなツールは、通信、モード管理、診断、メモリー管理、入出力といったベーシックソフトウェアのすべてのドメインに役立ち、またすべてのドメインで必要です。たとえばメモリーのドメインでは、開発者はエディターを使用して、単純にメモリーブロックを挿入することで、それを不揮発性RAMマネージャー (NvM：non-volatile RAM manager) だけでなく、フラッシュEEPROMエミュレーション (Fee：flash EEPROM emulation) でも首尾一貫して設定できます。また、グラフィック画面に表示されるユーザーデータとブロックサイズの比率を見れば、オーバーヘッドを見積もるのも非常に簡単です (図2)。ツールの支援機能は設定プロセスでも有用です。あるパラメー

ターを開発者が変更すれば、それに依存する他のパラメーターも、ルールシステムによって自動的に修正されます。支援機能はもっと複雑なタスク、たとえば Runnable Entity をオペレーティングシステムのタスクにマッピングするといったタスクでも活躍します。開発者はSWCからトリガー条件が似た Runnable Entity を選択し、タスクを割り当てて、最後にはタスク内での実行シーケンスを定義できるのです。モード管理ドメインからも例を挙げましょう。AUTOSAR 4のBswM

モジュールでは、他のBSWモジュールのモード変化への対応や、モード変化そのもののリクエストを目的として、調停規則、論理式、アクションの設定を完全にユーザーが定義できるようになっています。現在では支援機能を用いてBswMを設定し、それを比較的操作しや

すいAUTOSAR 3の ECU State Manager (EcuM) と同様に動作させることが可能です。

System Description からのパラメーターの導出

CAN、LIN、FlexRay、Ethernet用の通信モジュールの設定は、自動車メーカーから出される System Description に適合しなければなりません。AUTOSARでは、ECU固有の System Description を抽出した内容 (System Extract) から、モジュールの基本設定 (Base EcuC) を導出できます。ただし、実際の状況はもう少し複雑です (図3)。AUTOSARでは System Description の標準フォーマットが定義されています。しかし、自動車メーカーはこのフォーマットのほか、DBC、LDF、FIBEXといった従来のフォーマットも使用します。さらに、TIER1サプライヤーが、たとえばECU内のプライベートのCANバスや、センサーとECUを接続するLINバスなどに、独自の System Description を使用している可能性もあります。そのためソフトウェアツールは、考えられるあらゆる種類の入力データを識別し、従来のフォーマットを適切な前処理方法で変換したうえで、ECU独自の System Extract を生成しなければなりません。また、それぞれ異なる複数のSystem Extractを1つの共通の記述にマージする機能も求められます。これらが揃って初めて、Base EcuC の生成が可能になります。診断モジュールについても同様の配慮が必要です。モジュール

の設定はECUのODX仕様に適合しなければなりません。そのため、ODXファイルも Base EcuC に含めなければなりません。

TIER1に自社プロジェクト用の標準の設定があり、それがEcuCフォーマットで直接利用できる場合は、これらの設定要素も、Base EcuCに含めなければなりません。ツールが設定のチェックに必要とするBSWMDファイルの提供元がさまざまで、TIER2-BSWサプライヤーから提供されたり、マイクロコントローラーの製造元から、MCALモジュールに合わせて供給されたりする場合もあります。

図1： AUTOSAR開発プロジェクトにおける役割 図2： 詳細な表示により、ECUの設定が簡素化

3April 2014

Technical Article

図3： DaVinci Configurator Pro from Vectorの例を基にしたECU設定の作成と更新のワークフロー

そして最後に、自動車メーカーがサプライヤーに提供する System Extract に、SWCが含まれる場合もあります。AUTOSAR 4の手法ではまず、System Extract を使用して ECU Extract を生成しますが、それらの SWC もそこから一様に把握することができます。その後、たとえば外部サプライヤー (TIER2-SWC) などから提供

される他のSWCを組み込んで、その ECU Extract を拡張します。 この ECU Extract と Base EcuC を使用して、ECU開発者はBSW

と RTE (Runtime Environment) 全体のコンフィギュレーションを作成します。ここでは、このツールは Base EcuC から取得したパラメーターを書き込み保護して扱い、System Extract からの逸脱が生じないようにする必要があります。

プロジェクトの更新

プロジェクトの期間中、開発者の元には更新版の入力データが頻繁に届きます。これらの更新は一般に、届く頻度もタイミングもばらばらです。自動車メーカーが車両開発の特定のマイルストーンに従って新しい System Descr iption を配布する一方で、診断の記述はそれよりはるかに頻繁に更新されるのが普通です。System Description を受け取ってから ECU を納入するまでの期間が非常に短いことも少なくありません。したがって、新たな入力データによる設定更新を可能な限り自動処理できる能力もツールには求められます。これは、プロジェクト更新機能

があれば、新しい Base EcuC を生成し、実際の設定をその新しい Base EcuC に合わせて更新することで実行できます。

しかし、System Description にエラーがあった場合はどうなるのでしょうか。自動車メーカー側で問題が特定されたとしても、修正版の System Description は通常、すぐには届きません。そういった場合は、ECU開発者側で、導出されたパラメーターを意図的に無視したり、他の値で上書きしたりするという手段があります。この方法により、ECU設定内でエラーを直接修正できます。こういった逸脱はいずれも極めて重要であるため、ツールではECU開発者がパラメーターのステータスを明示的に「ユーザー定義」に設定できなければなりません。パラメーターのステータスがこの状態の場合、プロジェクトを更新する際にツールがその値を上書きすることは許されません。ECU開発者が「ユーザー定義」のステータスを解除すれば、パラメーターには導出された値が入ります。

また、上書きしたパラメーターのレポートを生成すれば、このツールはECU開発者と自動車メーカーの間の連携にも貢献できます。

複数の開発者での並行作業を可能にする「マージ」機能

比較的小規模のECUプロジェクトであっても、複数の開発者が同時進行で作業するのが普通です。「XY氏が常にオペレーティングシステムを担当する」というように、権限の範囲が明確に規定されているのであれば、同一のモジュール、あるいは同一の

4April 2014

Technical Article

図6： 同じECU設定の並行作業

SWCに同時に変更を加えることは回避できます。しかし、開発者は多くの場合、ECUソフトウェアの全アーキテクチャー層を垂直に貫いて動作するECU機能を、同時進行で開発しています(図4)。手作業でCをコーディングしていた時代であれば、インテグレーション担当者はそれぞれのコードのブランチをテキストレベルでマージするのですが、AUTOSARの場合は、何メガバイトものAUTOSARフォーマットのXMLファイルをマージすることになります。汎用的なXMLツールでは、AUTOSAR設定の比較やマージは事実上不可能といえます。ファイルの構造と、ファイル内に存在する多数の参照があまりに複雑なのです。ここで使えるのはおそらく、AUTOSARの設定の違いを分かりやすく表示し、マージの選択肢を与えてくれる AUTOSAR 用のツールしかありません (図5)。ユーザーにとっては、その設定を作成したものと同じエディターでそれらの違いを直接確認できれば理想的です。それができればユーザーは安心でき、また、データが見慣れない方法で表示される、別のツールで作業する必要もありません。

しかしながら、経験則から言えるのは、「マージすべき変更は、少ないほどよい」ということです。設定に大量の変更がある場合、

それはたとえば、新しい通信マトリクス (C-Matrix) に対するプロジェクトの更新で発生したものかもしれません。そのため、現実的な方法としてお勧めするのは以下の手順です。すなわち、インテグレーションのマイルストーンであるMS0を起点として、機能開発の担当者はそれぞれが異なるブランチ上で開発作業を行います (図6)。これらのブランチをメインブランチへ次々にマージしていくのです。この間にはいくつかのステップが入ることもあります (MS1からMS3)。これを行って初めて、インテグレーション担当者は新しい C-Matr ix に合わせてプロジェクトを更新できます (MS4)。その後で、新しい C-Matr ix に適合する新しいブランチや機能を追加できます。これらはすべて設定管理 (CM：Conf iguration Management) システムで対応できます。このシステムは、SWCの実装ファイルも管理します。

図4： 「垂直」方向のECU機能の開発

図5： DaVinci Conf igurator Proの比較/マージのサポート

5April 2014

Technical Article

Matthias Wernicke (Dipl.-Ing. (FH))

ドイツ・ウルムの University of Applied Science で産業電子工学を専攻後、同地の Daimler Research Center に4年間勤務。2000年代初めよりシュツットガルトの Vector Informatik GmbH に勤務し、車両用の分散電子機能の設計手法やツールの開発を担当。現在、DaVinci AUTOSARツールのプロダクトマネージメント責任者。

入手可能なツール

ベクターのツールである DaVinci Configurator Pro では、ここで説明した方法での作業がすでに可能となっています。DaVinci Conf igurator Pro での設定バリアントの作成も間もなく可能になる予定で、これによってECUの設定バリアントを動的に切り替えられるようになります。これらのバリアントは「Post-Build Selectableバリアント」と呼ばれることもあります。ここでも、現在用意されている AUTOSAR の概念を、ツールの機能にインテリジェントに実装することが大切です。それによって、AUTOSAR プロジェクトの開発に携わる開発者がさらに価値の高いサポートを受けられるようになるのです。

本稿は2014年4月にドイツで発行されたElektronik automotiveに掲載されたベクター執筆による記事を和訳したものです。

提供元：

見出し画像および図1～ 6：Vector Informatik GmbH

リンク：

ベクターのAUTOSARソリューションwww.vector-japan.co.jp/autosar-solutions

ベクター･ジャパンwww.vector-japan.co.jp

執筆者：

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社営業部 （組込ソフトウェア関連製品） TEL: 03-5769-7808E-Mail: EmbeddedSales@jp.vector.com