Vector Journal Vol... DaVinci/MICROSARを使用したAUTOSAR ECUの開発プロセスCover Story Vector Journal Vol.4 05 ⑤ECUソフトウェア詳細設計 ECUソフトウェア詳細設計では、ECUのデ

Vector Journal Vol.4 01

DaVinci/MICROSARを使用したAUTOSAR ECUの開発プロセス

AUTOSAR

　近年、自動車に搭載される車載コンピュータ（ECU）と機能の増加に伴いソフトウェアの実装量が増大してきている。このような中、欧州を中心として発足されたAUTOSARが注目を浴びている。AUTOSARはマイコンのデバイスドライバやAPI、また、CAN通信などのECUに実装される基本的な機能のソフトウェア仕様を標準化していくことを目指した活動である。

AUTOSAR導入の準備

　自動車OEMやサプライヤが持つ既存のECU開発プロセスや開発環境への影響が明確で

02 Vector Journal Vol.4

　近年、自動車電子部品（ECU）のソフトウェアプラットフォーム

標準化団体であるAUTOSARの活動が活発化してきている。今

回、三菱自動車工業株式会社では、サプライヤの三菱電機株式会社

と共同でAUTOSARをECUへ実装する評価プロジェクトを実施

した。この評価プロジェクトの過程にて開発プロセスの確認、及び

AUTOSAR導入時の課題であるツールチェーンの検証を実施した

ので紹介する。

Cover Story

ない状態で、安易にAUTOSARを導入するのは開発側の混乱を招きかねない。このため、今回ECUサプライヤの三菱電機株式会社とベクター・ジャパン株式会社と共同で、AUTOSARのECU開発プロセス確認と開発環境（ツール類）の検証を実施しAUTOSAR導入の準備を行った。更に合わせてAUTOSARを使用した場合のソフトウェア再利用性についても検証を行ったので報告する。

AUTOSAR評価概要

　今回の評価では電気自動車i-MiEVに搭載しているメイン制御ECUのEV-ECUを対象として評価を行った。

　三菱自動車でモデルベースにて開発したソフトウェアをEV-ECUから一部の機能を抜き出して使用することとした。評価では抜き出したソフトウェアを分割し、マイコン評価ボードから成る2つのECUにそれぞれ適切に割り当てて実装した（図1）。今回作成したAUTOSAR ECUとEV-ECUとでローカルのCAN通信ネットワークを構成し、EV-ECU単体で実現していた機能を、複数のAUTOSAR ECUで実現する構成をとった。　再利用性の検証については、2つのAUTOSARECUに割り当てた片方のソフトウェアを更に分割して別のAUTOSAR ECUに実装する。この実装工程と従来のソフトウェア再利用時の実装工程とを比較し、再利用性の検証を行った。

ECU開発プロセス確認

　AUTOSARを使用したECU開発を進める中で、重点を置いて確認した内容を下記する。

従来のECU開発プロセスとの相違点の確認自動車OEMとサプライヤの役割分担ツールチェーンデータ定義ファイル形式の確認

　　今回の評価プロジェクトで実施したプロセス概要を以下に示す。また、それぞれのプロセスにおける実施内容と確認項目に対する結果も詳述する。今回の評価に使用した開発環境・実装環境を表1にまとめた。

① 車両システム設計② 車両ネットワーク設計③ ECUアプリケーションソフトウェア設計④ ECUソフトウェアシステム設計⑤ ECUソフトウェア詳細設計⑥ コーディング・実装

①車両システム設計

　今回はEV-ECUと抜き出したソフトウェアの連携制御部分に限定してシステム設計を行った。検討項目としては、各ECUへの機能割付けやネットワーク構成、使用するAUTOSAR BSWの決定等が挙げられる。この検討結果をシステム要求仕様書としてまとめた。ECUへの機能割付けは、AUTOSAR手法でのSoftware Component（以後SW-Cと呼ぶ）の割付けに当る。


www.vector-japan.co.jp

　車両システム設計の段階でSW-C構成及びBSW構成まで決定するかはOEM/プロジェクト次第だが、今回の対象システムが小規模であったことと使用するソフトウェアベンダーも明確であったため、この段階で実施した。　車両システム設計は車両全体を考慮した設計となるため、OEMで実施される内容である。

②車両ネットワーク設計

　i-MiEVの車両ネットワーク上でEV-ECUが配置されていた箇所にゲートウェイECUを設け、EV-ECUとAUTOSAR ECUでローカルのCAN通信ネットワークを構築した（図2）。　CAN通信ネットワーク設計にはNetworkDesigner™を使用した（図3）。CAN通信情報はARXML形式の“System Description”ファイルとして出力した。このファイルの記述フォーマットは、AUTOSARにて仕様が決まっているが、ツールベンダーに依存する項目もある。今回使用したNetwork Designer™では、シグナルの詳細情報（データ値の範囲、分解能等）が設定可能であるが、AUTOSARで定義されている

図3：Network Designer™表1：評価に使用した開発環境と実装環境

図1：ECU分割イメージ図図2：車両ネットワーク構成の概要図

④ECUソフトウェアシステム設計

　ECUソフトウェアシステム設計では、SW-CのECU割付けとECUの入出力情報の設計を行う。DaVinci Developer™を使用してこの設計を行った（図5）。　まず、S imul ink ®より出力した“ S W - CDescription”ファイルをDaVinci Developer™にインポートし、SW-Cを各ECUへ割付けた。次に、ネットワーク設計で出力した“SystemDescription”ファイルをインポートし、CAN通信データとSW-Cの入出力データとのマッピングを実施。DaVinci Developer™では、自動でデータをマッピングできる機能があり、通信情報量が多いケースにおいて、このような機能は非常に有用である。　DaVinci Developer™で設定した情報はECU毎に、ARXML形式の“ECU Extract of


項目ではないため、次のツールへと引き継がれない場合がある。次のプロセスにて異なるベンダーのツールを使用する場合は、事前にツール依存の設定項目を洗い出す必要がある。　通信ネットワーク設計としては、ツール及びデータ交換のファイル形式以外は現在の設計方法と変わらない。Network Designer™ではARXML形式以外にDBC形式、FIBEX形式と多種のファイル形式に対応しているため、提供先の都合に合わせファイル形式を選択できる。　ネットワーク設計も車両全体を考慮した設計となるため、OEMで実施されるプロセスである。

③ECUアプリケーションソフトウェア設計

　E V-ECUから抜き出したソフトウェアはSimulink®を用いて編集した。編集内容としては、ソフトウェアモデルの入出力に対してAUTOSARインターフェイスの設定作業と、AUTOSARの実行関数であるRunnableEntityを定義した程度である。　ソフトウェア再利用性に関する注意点として、SW-Cの入出力ポートとデータの構成が挙げられる。十分な検討無しで適当にデータを纏めポートを構成した場合、SW-C再利用時に他のSW-Cと接続するポートのデータ構成が異なると、ポート構成の変更を余儀なくされる（図4）。逆に各データに対して各々のポートを作成することは、SW-Cの構成を複雑とするため推奨しない。再利用が考えられるSW-Cのポート構成に関しては十分な事前検討が求められる。　ツール間連携における注意点として、DaVinciDeveloper™などで作成したARXML形式の“Software Component description”ファイル（以降SW-C Descriptionと呼ぶ）をSimulink®

に読み込む場合、Runnable Entityの情報が、Simulink®により上書きされることが挙げられる（Simulink®側仕様による）。　モデルのソフトウェアソースコードと“SW-CDescription”ファイルは、Real-Time Workshop®

Embedded Coder™を使用して自動生成した。　ECUアプリケーション設計は三菱自動車で実施したが、プロセス分担はプロジェクトに応じて異なるため、設計前に分担を協議して決めておく必要がある。

System Configuration”ファイルとして出力した。　ECU開発過程においてネットワーク設計は幾度となく更新されるため、RTE設計ツールは“System Description”の更新容易性と更新内容の検証容易性が高いことが望まれる。　ECUソフトウェアシステム設計は三菱自動車で実施した。小規模の開発プロジェクト（ECU単体で閉じたプロジェクト等）では、サプライヤで実施するのが効率的な場合もあるが、OEMで部分的にソフトウェアを設計する場合や複数ECUによる連携制御を設計する場合は、OEMでの実施が好ましい。また、通信データとSW-CのデータマッピングをあらかじめOEMで実施することは、データの整合性検証も兼ねられるため、データ不整合によるOEM・サプライヤ間の手戻りを減らせるメリットもある。

図4：SW-Cの再利用性における注意点

図5：DaVinci Developer™


Cover StoryDaVinci/MICROSARを使用したAUTOSAR ECUの開発プロセス


⑤ECUソフトウェア詳細設計

　ECUソフトウェア詳細設計では、ECUのデバイスドライバの設定やOS、ECUの基本機能（CAN通信、故障診断機能等）の設計を行う。前項で生成したARXML形式の“ECU Extractof System Configuration”ファイルを用いて設計を行う。　具体的な設計内容としては、RunnableEnt i t yのOS Taskへの割付や、使用するBS Wのパラメータ設定等である。今回はDaVinci Developer™とGENy™及びDaVinciConfigurator Pro™を使用して設定を行った。各ツール間ではAR XML形式の“ECUConfiguration Description”ファイルを共用しながら設計を行う。　ECUソフトウェア詳細設計は、ハードウェアに依存する設定があるためサプライヤでの実施となる。

⑥コーディング・実装

　ソフトウェアのソースコードはDaVinc iConfigurator Pro™及びGENy™から自動生成した。生成したコードから実行コードを生成し、生成した実行コードをROMに書込む作業を行った。コンパイラにはIARのコンパイラを使用した。　従来ではハンドコーディングによりコード作成されていたが、AUTOSARではツールによる設定と自動コード生成によってコーディングが可能となる。　コーディング・実装は従来手法と同様にサプライヤでの実施となる。

動作確認試験

　作成したAUTOSAR ECUをi-MiEVに搭載し実車試験を実施した（図6）。ECU単体で処理していた機能が分散されたため、ECU間の通信による遅延は生じたが、AUTOSAR ECUにより車両が正常に制御されることを確認できた。

再利用性の確認

　次にSW-Cの再利用性について検証を行った。開発プロセス確認で2つのECUに割り当てられていたSW-Cを、ECU数を1つ増やし割り当

てパターンを変更した（図7）。これによりSW-Cの移植のプロセス確認と移植に要する工数を見積もり、AUTOSARを用いた場合と従来方法で設計した場合との比較を行った。　SW-Cを移植する際に必要となったタスクを以下に示す。

　ネットワークの再設計　 SW-CのECU割付　 ECUソフトウェアの詳細設計

　ネットワークの再設計は従来手法とAUTOSAR手法の両方にて必要なタスクで、作業工数も殆ど変わらない。

　SW-Cの移植においてアプリケーションソフトウェアの修正、及び、SW-Cのインターフェイス修正も不要であった。SW-CのECU割付け、CAN通信情報とのデータマッピングはツール上の簡単な作業で実施できた。従来であればアプリケーションソフトウェアのインターフェイスの合わせ込みに大きな工数を割いていた。　また、ECUソフトウェアの詳細設計に関しては、移植前の設定内容を引き継げる場合には、設定項目を減らすことが出来る。　結果的には、インターフェイスの合わせ込み作業とミドルウェア設計に要していた工数を大幅に削減可能であった。AUTOSARによる再利用性の向上は期待できる。

図6：実車試験の様子

図7：再利用性・移植容易性の評価方法


ツールチェーン評価

　ツールチェーンはソフトウェアの品質に大きく影響するため、サプライヤを含めて十分検討する必要がある。ツール依存の問題を考慮すると開発プロセス全体を通し、同一ベンダーのツールを使用することが好ましい。今回の評価プロジェクトで実施したツールチェーンを図8、図9に示す。ピンク背景色の箇所はOEMでの作業、水色背景の箇所はサプライヤでの作業を示している。　ベクター社ではネットワーク設計から、AUTOSAR RTE /BSW/OSの詳細設計及びコード生成まで一連のプロセスを網羅するツールを提供しており、既にツールチェーンとして確立しているため、プロセス全体を通してデータの整合性・一貫性が保て、高い信頼性のもと開発を行えると評価した。　ツールへの要望として、想定される他社ツールとの連携において受け渡されるデータの互換性検証の実施を挙げさせて頂きたい。特にAUTOSARとモデルベース開発の連携は、有効な開発手法であると考えているため優先的な検証実施を期待する。　また、GUIによるソフトウェア設計は設計時においては効率的であるが、設計情報の比較・確認作業には不向きであるため、各ツールで設計した情報を表形式等で出力する機能の追加が望まれる。特にネットワーク情報については、通信シグナルの設定パラメータや送受信の関係を確認する作業が非常に大変であった。表形式で出力できると確認作業も効率化されると考える。

図9：AUTOSARによるECU開発プロセス2

図8：AUTOSARによるECU開発プロセス



まとめ

　AUTOSARを使用したECU開発プロセスの確認を通し、プロセスフローとプロセス分担を把握することができた。また、OEM/サプライヤ間で分担の協議が必要なプロセスも明確化できた。AUTOSARでは、従来サプライヤが実施していた設計をOEMで実施することも可能となる。また、OEMとサプライヤ間でオーバーラップするプロセスもあり（ECUソフトウェアシステム設計）、今後考えられるプロセスパターンに対して柔軟に適応できる体制を整えていく必要がある。　再利用性の検証については、従来手法に比べ比較的容易に行えることを確認できた。ただし、今回はSW-Cの入出力にSender-Receiverのポート形式のみを使用していたが、Server-Clientのポート形式を使用した場合の再利用性検証は別途必要である。　今回の評価プロジェクトを通して技術面に関しては、ある程度目処がつけられた。今後はサプライヤ、ツール・ソフトウェアベンダーとの意見・情報交換を積極的に持ちながら三菱自動車としての導入体制構築と、導入プロセスの検討を行い、導入計画を立てていく。

あとがき

　今回の評価プロジェクトには他社の方々より多くの協力を頂きました。コンパイラを提供頂いたアイエーアール・システムズ株式会社様、マイコンの評価ボードを提供頂いたルネサスエレクトロニクス株式会社様、今回の評価への採用には至りませんでしたが、協力のご提案を頂いた富士通セミコンダクター株式会社様。ECUへのAUTOSAR適用を共同で実施頂いた三菱電機株式会社様。ツール・ソフトウェアをご提供頂いたベクター・ジャパン株式会社様。この場をお借りし厚く御礼申し上げます。

執筆者三菱自動車工業株式会社開発本部　電子技術部　電子開発亀井雄一氏

提供元見出し画像 /表1/図1～9：三菱自動車工業株式会社

Cover StoryDaVinci/MICROSARを使用したAUTOSAR ECUの開発プロセス

T echnical Ar t ic le 1

電気/ハイブリッド自動車のECUテスト

開発やテスト時に使用する電気自動車のテストシステムにおいて特に課題となるのは、ECUが効率的に電力を消費している事を評価することです。そのためには、ECUの消費電力をソフトウェアの状態の関数として測定することが必要であり、求められるエネルギー効率を達成するにはこれ以外に方法はありません。


～動的な消費電力をインテリジェントに測定～




Technical Article 1 2 3 4 5

　各自動車メーカーやサプライヤーの先行開発 /生産開発部門で行われている研究を見れば、電気自動車と関連するモビリティーの概念に多くの力が注がれていることが分かります。一部の製品はすでに実験段階を過ぎ、他の製品も次々と後に続こうとしているなかで、各社テスト部門の目が車両エレクトロニクスの体系的テストに向けられています。開発の対象が電動パワートレインや新機能であっても、初期の構想およびプロトタイプのフェーズでは、従来車両の既存コンポーネントを使用することは少なくありません。しかし今、初期段階にある電気 /ハイブリッド自動車の生産開発に必要なのは、この数十年に及ぶE/Eアーキテクチャーの検証に関する重要な知見を新しい電気自動車に盛り込むことなのです。　電気自動車のエレクトロニクステストは、いったい何が違うのでしょうか。すでに確立されているテスト手法には、どのような修正や補足、差し替えが必要となるのでしょうか。

電気自動車の新たな課題

　オンボードの電子部品に見られる最大の変化は、電気駆動コンポーネントとバッテリー用の新しいECUです（図1）。純粋な電気自動車では、エンジンコントローラーが電気モーター駆

動用のコントローラーに置き換わります。トランスミッションECUはなくなりますが、新たにバッテリー管理システムが電池に関わるあらゆる機能に対応します。また、オンボード充電器では「燃料補給」に対応します。テスト部門は、これらのECUに従来のテスト方法を流用することができます。そして特に、バッテリーや電気モーターに関していえば、適切な環境シミュレーションをテストベンチに組み込む必要があります。詳しく調査したところ、電気モーターには高電圧が必要なため、テストベンチの機器が大きな影響を受けることから、これを実現するのはかなり困難であると分かりました。第一の課題は、こうした状況のなかで、新しいシステムに対するテストを既知の電子部品と同程度の細かさと自動化レベルで実施できるようにすることです。　充電に関しては、新しい通信用インターフェイス、つまり充電ステーションと車両間の通信を担当するインターフェイスも車両にとって重要な地位を占めます。実際の充電プロセスを制御・検証するだけならば、2、3の単純な電気信号だけで通信をまかなうことができます。しかし、さらに高度な機能、たとえば、充電料金の自動決済や、インフラストラクチャーに一時的に接続する車両の充電コストを最適化する仕組み「スマートグリッド」への対応を求めるのであれば、複雑な通信が必要となります。これらの課題に、

世界各地のさまざまな開発グループや標準化委員会が取り組んでいます。なかでも中心的な役割を果たすのがISO 15118で、これはAC電源でのインテリジェントな充電について記述した規格です。通信は電力線を介した IP（InternetProtocol）を使って行われ（電力線通信：PLC）、TCP/UDP、DHCP、XML、JSONといった一般的なインターネット技術が基盤となります。これらの技術はたいてい、どのPCにも用いられるほど幅広く利用されています。しかし、リソースが限られる自動車ECUへの導入は新たな試みです。テスト担当者はこれらのプロトコルを解析し、適切なテスト環境を用意するという新しい課題に直面しています。　また以前は、車両内の通信は既知のECU間で行われていましたが、現在では車両とさまざまなインフラストラクチャーの間で、複雑な通信が行われるようになっています。フィールドでの円滑な運用のためには、広範囲に及ぶ車両インターフェイスのテストが欠かせません。充電ステーションについても同じことがいえます。将来的には統一されたテスト内容（適合試験）が整備されることでしょう。標準化においては、まだいくつか流動的な面がありますが、現行の車両プロジェクトのために十分なテストの整備が必要であることは言うまでもありません。　電気自動車の開発で重要な役割を果たすの

図1：電気自動車に新たに電動パワートレイン関連のECUが搭載され、あらゆるレベルで省電力の手法を使用することが求められる

Communication withcharging infrastructure

Electric drivecontrol

Power savingtechnologies in the network

Battery managementsystem

power saving technologies in the ECUs

Onboard charger

が、省電力技術です。航続距離、利用可能なバッテリー技術、システムコストはどれも優先度が拮抗しており、それらに使用される電気エネルギーは極めて希少な資源となっています。「しかし、省エネシステムは内燃エンジンの搭載車両でも検討されているのでは？」と思われるかもしれませんが、こちらには二酸化炭素排出量の削減という目標とコミットメントがあります。ですから、それぞれの車両がECUやネットワークレベルで可能な限り消費エネルギーを抑えるべきなのです。

ECU、ネットワークレベルでの省エネルギー

　現在、ECUやネットワークの開発では多彩なアイデアが追求されています。そのすべてが新しいアプローチというわけではありませんが、これらは最近、優先課題として取り上げられ、AUTOSARなどの標準化に組み入れられつつあります。>パーシャルネットワーキング（Par t ial

Networking）では、物理ネットワークに準拠した論理ネットワークを作り、その論理的なパーシャルネットワーク上で、エネルギーを節約するためのスリープ状態を定義します。こうすることで、スリープ状態から復帰させるECUの数を多くの動作状況下で減らすことができ、より効率的な実装が可能になります。

>プリテンディッドネットワーキング（Pretended

Networking）では、ECU同士が通信ネットワーク上で互いにアクティブに見えても、それらは実際には内部的にスリープモードに入れるように構成されています。これは実際のECU機能が必要ない時に使われます。ECUハードウェアの拡張によって、定期的なメッセージが継続して送信され、ECUコアは一定の条件下でスリープから復帰します。

> ECUデグレデーション（ECU Degradation）

は、ECUの不要な部分を非アクティブ化する手段の総称です。ドライバーステージのスイッチを切ることからチップ内部の論理ユニットのきめ細かな管理までを含みます。

>異なる機能を少数のECUに統合すれば、必要

なエネルギーを全体的に減らせるだけでなく、ハードウェアコストの削減も期待できます。その実用的な展望に基づいて、AUTOSARではすでにこのアプローチをメソドロジーに採用しています。また、高性能のマルチコアプロセッサーも、専用のECUに搭載される同レベルの個別のプロセッサーに比べてエネルギー効率が優れています。

>開発がさらに進めば、複数の論理ECUを、仮

想化レイヤーを使って1つの物理ECUに一体化することも可能になるかもしれません。ただし、このエネルギー節約方法には、仮想

ECU間における未知のインタラクションによるリスクが発生する可能性が伴います。

　省エネルギーを目的とした込み入った手法は、ECUやネットワークをより複雑にします。そのため、体系的なテストを開発フェーズの早い段階で導入することが、これまでになく重要になっています。

他とは一線を画す消費電力のテスト

　テストの鍵を握るのはECUの消費電力です。以前であれば、消費電力は全体の電力消費量の平均として求めるか、「スリープモード」などの比較的静的な動作モードごとに求められていました。しかし、電力消費を最適化するシステムでは、ECUのソフトウェアの状態に関連付けて、消費電力を動的に測定しなければなりません。エネルギーの節約は一つ一つの最適化を数多く積み重ねることで実現するのです。そこで、テスト担当者は消費電力がECUの状態に応じた期待値を満たしているかを細かく調べなければなりません。開発においても同様に、開発者は消費電力をその時々のソフトウェアの状態に照らして評価できなければなりません。

　ベクターのVTシステム（図2）をはじめとする


図2：VTシステムの電源モジュールは、高い測定精度と時間分解能でDUTの消費電力を測定



Technical Article 1 2 3 4 5


ションのシミュレーションを行うことも、またその逆を行うことも可能です。　テストや解析では、多様なシグナルを使ってECUとネットワークの状態を判定することが求められます。バスやハードウェアのシグナル、あるいは診断 /キャリブレーション用のインターフェイスを介してECUから読み出された情報などがそうです。たとえば、ECU内部のRAM値をXCP経由で読み出せば、そのECU内部の状態に関する情報が得られます。ここで大切なのは、CANoeですべての値を直接、しかも同じタイムベースで入手できることです。適切なツールのサポートがあれば、簡単にECUの動作を評価することができます（図3）。このことは開発フェーズおよびデバッグの際、特に必要となります。使用する基礎的アプローチが同じであれば、テスト用プログラムの考案やテストの自動化もしやすくなります。近年、テストの自動化は検証戦略の重要な構成要素であることが実証されており、電気自動車についても、テストを行う部門で同じようにハイレベルな自動化の実現が可能です。

提供元

見出し画像 /図1～3：Vector Informatik GmbH

関連リンクVTシステムhttp://www.vector.com/vj_vt_system_overview_jp.html

高性能のテストシステムは、テスト中のECUの消費電力を正確に把握し、システムの状態との相関付けができるようになっています。モジュール型のテスト用ハードウェアであるVTシステムは、センサーおよび負荷のシミュレーション、入力のシミュレーションと出力信号の測定、短絡や断線などの電気系統の障害の生成を行うほか、内部でシミュレーションしているセンサーおよび負荷と、外部に接続されているセンサーおよび負荷との切り替えも行うことができます。さらに、VTシステムは供給電圧を制御して、その電力消費量を測定します。レンジの高速自動切り替えによって、負荷動作中に大電流を確保できるだけでなく、省エネモードやスリープモードでは最小限の電流に対応し、それを高い分解能で測定することができます。　このソフトウェアは、他のネットワークノードのシミュレーション（残りのバスのシミュレーション）を並行して行い、ECUへのソフトウェアアクセスを可能にします。さらに、包括的な解析機能も備えているため、開発者はこのシステムを使ってテストやデバッグを行うことができます。CANoeは、ECUとネットワークの解析、シミュレーション、テストに特化して開発されたソフトウェアであるため、多様な充電ステーションのインターフェイスに対する通信相手として動作します。充電用ECUのテストにおいて、充電ステー

Stefan KraußVector Informatik GmbHのグループリーダーであり、VTシステムのプロダクトマネージャーも担当。

執筆者

図3：CANoeでは電力の消費とECUの状態が分かりやすく表示され、解析も簡単


AUTOSARは、将来にわたって利用することを考えた、ECUソフトウェアを開発するためのリファレンスアーキテクチャーです。AUTOSAR仕様には、明確に定義されたモジュール間のインターフェイス、ソフトウェアの振る舞いの標準化、XMLベースのデータによる仕様の定義という大きな特徴があります。AUTOSARではDCM（通信）とDEM（フォールトメモリー）の両モジュールで診断が処理されます。本稿ではまず、AUTOSARを使用した診断と、それに関連するデータ形式について説明します。診断ソフトウェアの設定においてAUTOSARを補完する、ODX（OpenDiagnostic data eXchange）形式のデータについては、別稿の「標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発－PART 2：AUTOSAR開発プロセスへのODXの導入」で詳しく取り上げます。

標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発

：AUTOSARによる診断Part1


www.vector-japan.co.jpwww.vector-japan.co.jp


　標準化はカーエレクトロニクス開発における大きなトレンドです。オープンアーキテクチャーや構成可能コンポーネントを採用する目的は、開発プロセスにおいて、開発者が革新的で差別化の図れる面にさらに注力できるようにすることです。さらに、標準化をコスト削減の原動力とする狙いもあります。以前は車載ECUのソフトウェアアーキテクチャーが標準化されておらず、サプライヤーは自動車メーカー独自の多様なソフトウェアアーキテクチャー、つまり異なる開発プロセスや開発ツール、データ交換形式に合わせることが求められました。AUTOSAR（AUTomotive Open SystemARchitecture）は、オープンかつ共通の車両ソフトウェアアーキテクチャー標準を策定するという目標を掲げています。このAUTOSARアーキテクチャーには、主に以下の目的があります。

>ハードウェアの抽象化>インターフェイス規定の明確化>ベーシックソフトウェア動作の標準化>自動車メーカーとサプライヤー間のデータ交換形式の標準化

>ソフトウェア開発のための統一的なメソドロジーの定義

>モデルベースでの機能開発の支援

>すべてのECUおよび車両クラスにおけるスケーラビリティー

> ISO 26262に準拠した安全性要件の考慮

　AUTOSARは現在、ECUソフトウェアのリファレンスアーキテクチャーとなっています。近い将来、完全なAUTOSARソフトウェアを搭載した初めての量産車が世に出ることでしょう。また、AUTOSARメソドロジーを用いた開発プロジェクトも着実に数を増やし続けています。　AUTOSARコンソーシアムは現在、バージョン3.2および4.xの策定に入っています。これより前にリリースされたバージョン2.x、3.x、4.0は、車両プロジェクトの実装基盤としてすでに使われています。今日では、大部分の自動車メーカーが3.xまでのバージョンを利用しています。　エレクトロニクス開発において、機能指向の考え方は、ますます重要になってきています。AUTOSARは、個々のコンポーネントや車両機能の記述とシステム全体の記述を、いわゆるSystem Configuration Descriptionの形で標準化しており、また、車両の機能をECUに分配するメソドロジーも標準化しています。そのため、開発した機能を他の車両プロジェクトでそのまま再利用することが可能なのです。　図1の例で説明しましょう。「機能ライブラリー」にある車両機能の「照明」は、3つのサブ

機能に分かれています。車両Aではこれらのサブ機能が2個のネットワークECUに分配されていますが、車両Bではそれらがそのまま、変更なしで3個のECUに分配されています。サブ機能同士の通信はSystem ConfigurationDescriptionで定義されています。　AUTOSARではECUごとにECU Extract ofSystem Configurationが存在し、それがそのECUに関わるシステム内容と、サプライヤーに関連する内容も合わせてカバーします。

　ECUソフトウェアのAUTOSARアーキテクチャーは、以下の基本要素から構成されています。

>アプリケーションソフトウェア（SWC）>ランタイム環境（RTE）>ベーシックソフトウェア（BSW)

　アプリケーションソフトウェアが高いレベルで再利用できるのは、VFB（Virtual Function Bus）による通信の抽象化のおかげです。アプリケーションの開発とテストは、基盤となる通信メカニズムを知らなくても行うことができます。通信の場がECU内であるのか、ネットワーク上（CAN、FlexRayなど）であるのかも問われません。ランタイム環境（RTE：Run-Time-Environment）はアプ

図1：AUTOSARにおける機能の分配

Technical Article 21 3 4 5

標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発 Part1

リケーションソフトウェアの実行環境であり、特定のECUのためのVFBを実装しています。また、ベーシックソフトウェアはコンポーネントキットとして開発され、既製ソフトウェアとして市販されています。これには基本的なシステム機能が含まれており、ハードウェアからアプリケーションソフトウェアを抽象化します。基本的なシステム機能の領域は、以下の3つに分かれています（図2）。

>「サービスレイヤー」は、アプリケーションソフトウェアやその他のベーシックソフトウェアのモジュールに基本的なサービスを提供します。

>「ECUアブストラクションレイヤー」は、ECUハードウェアから、より高いレイヤーを抽象化します。

>「マイクロコントローラーアブストラクションレイヤー」は、特定のマイクロコントローラー装置から、より高いレイヤーを抽象化します。

　ECU Configuration Descriptionは、ベーシックソフトウェアとRTEの構成に用いられます。まず、この構成はECU Extract of SystemConfiguration（ネットワーク経由の通信など）から生成されます。ECU ConfigurationDescriptionはECUソフトウェア全体の動作を決定するのに中心的な役割を果たし、開発の進行とともに段階的に拡張･調整されていきます。

AUTOSARによる診断

　AUTOSARの診断ソフトウェアはDCM、DEM、FIMの3つのモジュールから構成されます。DCM（Diagnostic CommunicationManager）は、ISO 14229-1（UDS）とSAEJ1979（OBD-Ⅱ）による、診断のための通信機能を実装します。すべての診断リクエストは、最初にDCMが受け取ります。無効な診断リクエストの大半は、DCMが自身で処理します。DCMは、有効なリクエストについても、大部分を完全に処理できるようになっています。残りの自身で処理できないリクエストだけが、アプリケーションソフトウェアに渡されます。DCMがカバーする範囲は、AUTOSARのリリースごとに拡大してきました。これに伴い、アプリケーションソフトウェアでの対応が必要な部分は減ってきています。この経過は、DIDの処理（図3）によく表れています。バージョン3までは、アプリケーションソフトウェアがメッセージ内のデータの構造を解決しなければなりませんでしたが、バージョン4ではDCMで処理できるようになっています。　DCMはECU Configuration Descriptionによって設定されます。これにはサービスID、サブファンクション、データID（およびメッセージ内のデータ構造）、ルーチンID（およびパラメーターリスト）の定義が含まれています。さらに、ECUの

ステータス（セッションやセキュリティーレベル）による診断サービスの実行可否も、ここに設定できます。　DEM（Diagnostic Event Manager）は故障情報を記録する機能を実装します。この機能の詳細仕様が自動車メーカーによって異なるため、AUTOSAR バージョン 3.x以前のDEMでは枠組みのみが規定されていました。バージョン4では、自動車メーカーに依存しない形での標準化が検討され、これによりAUTOSARでの定義が可能になっています。

　DEMは主に、以下のタスクを処理します。

> DTCステータスビットの管理> NVRAMなどでの故障データの管理>スナップショット（フリーズフレーム）データの管理

>エクステンデッドデータレコードの管理>故障情報の自己クリア機能への対応> DCMから故障情報を読み出すためのインターフェイスの提供

　DEMの標準化されたインターフェイスと、いくつか設けられた、故障の確定判定に用いる標準アルゴリズムにより、自動車メーカーの統一仕様に基づいたアプリケーションソフトウェア

図2：ベーシックソフトウェア（BSW）の構造


図3：AUTOSARのバージョンごとの、DCMの処理範囲




の開発が可能になっています。DEMでは1つ、もしくは複数の故障判定条件をDTC（DiagnosticTrouble Code）にマッピングできます。DEMもECU Configuration Descriptionによって設定されます。これには故障判定条件、DTCコード、故障関連情報（スナップショットデータとエクステンデッドデータレコード）のデータ構造に関する情報が含まれます。　FIM（Function Inhibition Manager）は、故障を検出した場合に、一部の制御を禁止したりバックアップ制御を始めたりする機能を実装します。これにより故障の影響を抑え、また二次的な故障の発生を防ぎます。FIMもECUConfiguration Descriptionによって設定されます。

AUTOSARによる診断のためのBSWモジュール

　ベクターのMICROSARは、RTEとBSWモジュールから成るAUTOSAR仕様のＥCUソフトウェアにソリューションを提供し、AUTOSAR標準の領域全体をカバーしています。AUTOSARのBSWモジュールはそれぞれ、1つのMICROSARパッケージに割り当てられています。診断専用にMICROSAR DIAGパッケージが用意され、AUTOSARアーキテクチャーの

3つのBSWモジュール、すなわち、DCM、DEM、FIMが含まれています。MICROSAR DIAGは診断ソフトウェアとして、AUTOSAR準拠のUDSプロトコル、ISO 14229-1:2006の実装を提供します。

提供元


参考文献

[1] AUTOSAR specifications: www.autosar.org

[2] Pascale Morizur, Matthias Wernicke, Justus Maier:

Neue Wege zur Steuergeräte-Software Teil 1, Elektronik

automotive 11.2009

[3] Pascale Morizur, Matthias Wernicke, Justus Maier:

Neue Wege zur Steuergeräte-Software Teil 2, Elektronik

automotive 12.2009

[4] ISO 14229: Road vehicles - Unified diagnostic services(UDS)

[5] ISO 26262: Road vehicles - Functional safety

[6] ISO 22901: Road vehicles - Open diagnostic data exchange(ODX)

[7] Klaus Beiter, Oliver Garnatz, Christoph Rätz: Gesetzliche

On-Board-Diagnose und ODX, Diagnose in mechatronischen

Fahrzeugsystemen III S. 44 ff., Expert-Verlag 2010

Klaus Beiter

Vector Informatik GmbHの診断システム部で、開発チームのマネージャーを務めています。ASAMとISOのODXワーキンググループにも参加しています。

執筆者

Oliver Garnatz（Dipl Ing. FH）

Vector Informatik GmbHの組込ソフト部で、プロダクトマネージャーを務めています。ISOおよびAUTOSARの、診断分野のワーキンググループにもメンバーとして参加しています。

Christoph Rätz（Dipl-Ing. BA）

University of Cooperative Educationシュトゥットガルト校のコンピューター･サイエンス科を卒業。Vector Informatik GmbHで、診断システム部のグローバルプロダクトラインマネージャーを務めています。


3T echnical Ar t ic le

ODX（Open Diagnostic data eXchange）は、自動車の診断の仕様をデータ化するために開発されたXMLベースのデータフォーマットです。自動車メーカー同士、あるいは自動車メーカーとサプライヤーの間で診断の仕様をやり取りするために、オープンなフォーマットとして開発されました。AUTOSARは、将来にわたって利用することを考えた、ECUソフトウェアを開発するためのリファレンスアーキテクチャーです。AUTOSAR仕様には、明確に定義されたモジュール間のインターフェイス、ソフトウェアの振る舞いの標準化、XMLベースのデータによる仕様の定義という大きな特徴があります。本稿は、「標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発」の後編として、ODXそのものと、AUTOSARの開発にODXデータを組み入れて活用する可能性について考察します。

標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発

：AUTOSAR開発プロセスへのODXの導入Part2




　ODXは、ASAMおよびISOのワーキンググループによって標準化されました。2003年にASAMが開発を始め、後にISOがこれを引き継いでいます。ODXが開発されたのは、当時ユーザーに広く受け入れられる、診断仕様をデータ化するための標準が存在しなかったためです。このため、会社やプロジェクトの垣根を越えて診断仕様データをやり取りしようとすると、多大な工数が必要になっていました。ODX規格制定の最大の目的は、データの再利用です。異なる部門で異なるツールを使っていても同じデータを利用し、さらに処理できるようにしようという考え方です。　バージョン2.2.0のODXデータモデルは、7つのサブモデルから成ります（図1）。ODX開発時に、データを読み込ませる対象として考えられていたのは、診断テスターでした。そのため、図1の下側3つのサブモデル－診断サービスを定義するODX-D、通信パラメーターを定義するODX-C、車両でのアクセス方法を示すODX-V －が規格の中心になっています。これらは同時に、データの解釈を含めて、診断テスターが1つ以上のECUと通信するために必要なデータセットの基本形となります。　図1の上側4つは、フラッシュコンテナを定義するODX-F、ECUの設定に利用するODX-E、ECUの機能と診断データを関連付けるODX-

FD、複数のECUを対象とする診断処理（ジョブ）を定義するODX-Mのサブモデルです。これらは、先に示した3つのサブモデルと比べて扱える範囲が狭く、ODXの本来の目的からすると重要度も高くはありません。　AUTOSARでの利用を考えると、ODX-DとODX-FDの2つのカテゴリーが主な検討対象となります。このため本稿では、これらの2つに絞って議論を進めていきます。

　ODX-Dでは、診断リクエストとそれに対応するレスポンスや、この中でやり取りされるデータの解釈といった、診断サービスの仕様が規定されます。ODX-FDはODX-Dを拡張するものです。これを使って、車両の機能から見た診断の仕様を定義できます。ODX-FDでは、車両の各機能に入出力パラメーターや、DTC、DIDといった診断データを割り当てられます。各機能を、階層構造を持たせて定義したり、任意の基準でグループ分けして定義したりすることもできます。ODX-FDでの定義は、固有の値を割り当ててODX-Dデータを参照させることで、診断サービスとひもづけられます。本質的にはODX-FDは、車両の機能の面から診断の仕様をデータ化するものです。ODX-FDデータを使うことで、車両の機能に異常が生じたときに、故障原因となり得る部品（ECU本体、センサー、アクチュエー

ターなど）を簡単に調べられるようになります。　最新のODX仕様はバージョン2.2.0で、ISO22901-1として2008年に公開されています。最新バージョンのベースであるバージョン2.0は、ASAMが開発し2004年に公開しています。この最初のバージョンからISO版の公開までの間に、仕様の改善や記述の追加、それに不具合修正を含む2つのバージョンがASAMからリリースされています（図2）。

ODXとECUソフトウェア

　ODX規格に基づいてデータを作成する場合、その構造に関しては大きな自由度があり、1つの振る舞いをさまざまな形で記述できます。これは、利用するテストシステムに対して最適な構造のデータを作成できるようにするためです。しかし、ODXデータを処理するツールの側からすれば、自由度が高過ぎると、すべてのバリエーションに対応するのが困難になってしまいます。このため、現実のテストツールは限られた記述形式にのみ対応するようになっています。異なる利用環境間でODXデータをやり取りするためには、当該データで用いられているデータ構造に双方が対応していなければなりません。この状況に対処するために広く用いられているのが、データ形式や仕様の範囲を制限するため

図1：ODXのカテゴリー図2：：ODXの歴史



の追加規定であるオーサリングガイドラインです。共通のオーサリングガイドラインを適用することにより、他の部門や社外とのデータ交換が可能になります。今日この手法は広く利用されており、自動車メーカー間でのデータ交換を可能にするための標準オーサリングガイドライン（ODX-RS：Recommended Style）も定められています。　ODXの開発は、データを読み込んで動作するテストシステムのパラメーター設定方法を標準化するために始められました。データ構造の要件や、どこまで細かい仕様定義が必要かという度合いは、データの利用目的によって異なります。このため、診断仕様データを異なる用途で共用できるのは限られた場合だけになります。汎用の診断テスターには、できるだけ多様な車両の構成やECUの設定に対応することが求められます。柔軟にテスターを設定するためには、複数の並立した仕様や多義的な仕様を定義できると便利です。ODXでは、たとえば1つの診断サービスについて複数のレスポンスを規定できます。ソフトウェア実行時には、実際に受信したレスポンスを分析し、適切な定義を選んで診断データを解釈します。このような定義方法は、ECUで実行されているソフトウェアが特定できていない場合、非常に役に立ちます。しかしODXデータからソースコードを生成する場合は、これとは逆

に、一義的かつ厳密な仕様定義が必要不可欠になります。ECUは診断リクエストに対して、一義的に（定義されたとおりに）反応しなければなりません。複数のレスポンスが定義されたデータは、ソフトウェアの生成には利用できません。この例から、用途が異なれば診断データ（の品質）に求められる要件も異なること、そして時にはそれらが相反することが分かります。　したがって、ODXデータから診断ソフトウェアのコンポーネントを生成するのであれば、ベースとなるODXデータは上述した要件（仕様品質）を完全に満たさなければなりません。　以下に、求められる仕様特性を満たさないためソフトウェア生成には使えないデータ構成の例を示します。

> 1つの診断リクエストに対する複数のレスポンス定義（上述）。

> UDS仕様のECUにKWPの診断サービスを追加するなど、ベースとなる診断プロトコルに規定されていない診断サービスの利用。

>根幹部分（SID/DIDなど）が同一の診断メッセージが、複数の診断サービスで定義されているデータ。この場合も、ECUの振る舞いを一意に決定できません。

> DTCスナップショットデータやDTC拡張データなどエラーメモリーでの、前後のデータに

依存するような特殊な仕様の規定。ODXの仕様は、エラーメモリーの内容を詳しく規定するようにはできていません。DTCを補足する情報を規定することは可能ですが、ここで利用できるのはSDGという要素だけです。このSDGでは、名前と値の組み合わせを規定できるだけで、データの意味づけがなされません。したがって、SDGを利用してエラーメモリーデータを単一の手順で自動処理することはできません。

>今日広く利用されているODX 2.0.1には、セッションやセキュリティーの状態による診断サービスの実行可否を規定する仕組みがありません。ODXデータだけでは、実行可否を確認するテストや、ネガティブレスポンスを送信するソフトウェアを生成させることができません。これらは別のアプリケーションで処理する必要があります。ODX 2.2.0ではこの問題が解決されており、セッションやセキュリティー状態に関する仕様を、定められた形式で規定できます。

　このリストから分かるとおり、ソフトウェアコンポーネントを生成することを考えると、ODX規格に準拠することは必要条件でしかなく、追加規定が必要不可欠です。ODX規格にはチェッカールールが定められていますが、これで確認できる





のは規格への準拠だけです。ODXデータを診断テスターに読み込ませるためにはこれで十分かもしれませんが、ソフトウェア生成のためにデータ品質を確保しようとすると、多数のチェック項目を追加して前述のような不適切なデータが混ざり込まないようにする必要があります。　要約すれば、ODXはもともとテストシステムのパラメーターを設定するために設計されたものであり（図3の左側）、ソフトウェアコンポーネントの生成に用いるためには、その自由度を必要なところまで制限する必要があるということになります（図3の右側）。この制限は、オーサリングガイドラインを使って実現できます。

AUTOSARでのODXの利用

　ODXは車両やECUの診断仕様をデータ化するための規格として、またAUTOSARはECUソフトウェア開発のための標準として、それぞれの地位を確立しています。したがって、AUTOSARの枠組みの中でECUの診断機能を実現するソフトウェアモジュール（DCM/DEM）を開発するプロセスには、すでに広く利用されているODX形式のデータを組み入れるのが理にかなっています。　AU TOS A Rの開発は、非常に機能指向です（別稿「標準規格の組み合わせで実現：AUTOSARとODXによる診断機能の開発 -

PART 1：AUTOSARによる診断」をご覧ください）。開発の初期段階で作成されるのは、機能の仕様とその規定になります。ODXデータは、本来は診断テスターで利用するためのものです。ODX-FDは、診断メッセージやその中のデータとECUの機能とを結びつけます。このため、診断仕様の詳細がODX-D形式のデータとして完成していなくても、AUTOSARで規定された機能のODX形式での構造と分類を反映したODX-FDデータを導き出すことができます（図4のステップ1）。ODX-Dデータとのリンク（各機能と実際の診断データとのマッピング）は、この時点ではまだ不可能です。　前述のとおり、ソフトウェアコンポーネントの生成に必要な情報は、本来ODX-Dデータに規定されています。AUTOSARでは、ECUの仕様はECU Configuration Descriptionファイルに規定され、ここからECUソフトウェアを生成します。したがって、もしODX-Dデータがすでに存在するのであれば、これを変換してECUConfiguration Descriptionファイルに反映し、AUTOSARの開発プロセスで利用できそうです。ODX-Dデータが存在するのか、また存在したとして、どこまでの範囲をカバーしているのかは、自動車メーカーとサプライヤーでの開発形態によって異なります。極端なケースとしては、ECUを「ゼロから」完全に新規開発する場合が

挙げられます（図4のステップ2a）。この場合、診断仕様の大半はあらかじめ自動車メーカーによって規定されます。これとは逆の極端なケースとして、既存のECUを別の新規開発車両に組み込む場合が考えられます（図4のステップ2b）。この場合、診断仕様を変更しようとすると多大な工数が必要になってしまうため、本来要求される仕様よりも、すでに実装されているソフトウェアをそのまま使うことが優先されてしまいます。　実際には、このような極端なケースがそのまま当てはまることはなく、診断の仕様はさまざまな側面から決定されます。自動車メーカーとサプライヤーが協力して、ECUの機能要件と既存のソフトウェアの両面から、またこれら以外の点も考慮して要求仕様を定め、そこから当該ECUのODX-Dデータを作成するのが一般的です。　ODX-Dデータが完成したら、ODX-FDデータとリンクさせます（図4のステップ3）。このODX-DデータからECU ConfigurationDescriptionを生成し、これに基づいてソフトウェアコンポーネントを生成します（図4のステップ4～5）。さらに、同じODX-FDデータとODX-Dデータをベースにして、テスターのランタイム形式のデータを作成します（図4のステップ7）。ソフトウェアコンポーネントの生成とテスターのパラメーター設定を共通のODXデータに基づいて行うことで、仮にECUと診断テスターの開発レベ

図3：（左）テストシステムのパラメーター設定を行う場合の仕様の範囲　（右）ソフトウェア生成のために、オーサリングガイドラインを適用して自由度を制限した仕様の範囲


ルが異なっていたとしても、これらの仕様を正確に一致させることが可能になります。　ここで、1つの疑問が湧きます。逆に、ECUConfiguration DescriptionファイルからODX-Dデータを生成することも可能なのでしょうか。その答えは、利用するAUTOSARのバージョンによって異なります。バージョン3.xまでのAUTOSARフォーマットは機能が限られており、テスターのパラメーター設定に必要不可欠な情報（たとえば、送受信データを物理値に変換するための公式）を記述できませんでした。AUTOSAR 4は仕様が拡充されており、送受信データの変換公式を規定することもできます。とはいえ、このような情報はECUソフトウェアの生成には不要なものなので、実際のECU Configuration Descriptionデータに変換公式が含まれることは期待できません。　さらに言えば、機能指向のアプローチは、本稿で説明してきたような、診断仕様を異なる車型間で統一することを妨げる方向に働きます。したがって、診断仕様データの利用フローが将来どうなるかについて、現時点で正確に予測することはできません。しかし、これまで説明してきたような手法がそのまま主流となることはなく、実際の開発業務に応じて手直しをしたり、複数の手法を組み合わせて利用したりされていくものと考えられます。

開発プロセスの統合

　AUTOSARやODXといった新技術を導入する際に、最大の課題の1つとなるのは、さまざまなインターフェイス（プロセス間の入出力の仕様やデータフォーマット）を持った種々のサブプロセスを統合することです。これまでの経験から、このような新しい技術を導入する場合は、実績あるソリューションをベースにすることが最も効率的であることが分かっています。ベクターは、AUTOSARとODXに対応した、開発工程を広くカバーするツールチェーンをご提供しています。これらの詳細につきましては、http://www.vector.com/vj_autosar_solutions_jp.html

およびhttp://www.vector.com/vj_odx_jp.htmlをご覧ください。

提供元


参考文献

[1] AUTOSARの仕様：www.autosar.org

[2] Pascale Morizur, Matthias Wernicke, Justus Maier：Neue Wege zur Steuergeräte-Software Teil 1, Elektronik

automotive 11.2009

[3] Pascale Morizur, Matthias Wernicke, Justus Maier：Neue Wege zur Steuergeräte-Software Teil 2, Elektronik

automotive 12.2009

[4] ISO 14229：Road vehicles - Unified diagnostic services（UDS）[5] ISO 26262：Road vehicles - Functional safety[6] ISO 22901：Road vehicles - Open diagnostic data exchange（ODX）[7] Klaus Beiter, Oliver Garnatz, Christoph Rätz：Gesetzliche

On-Board-Diagnose und ODX, Diagnose in mechatronischen

Fahrzeugsystemen III S.44 ff., Expert-Verlag 2010

Klaus Beiter

Vector Informatik GmbHの診断システム部で、開発チームのマネージャーを務めています。ASAMとISOのODXワーキンググループにも参加しています。

執筆者

Oliver Garnatz（Dipl Ing. FH）

Vector Informatik GmbHの組込ソフト部で、プロダクトマネージャーを務めています。ISOおよびAUTOSARの、診断分野のワーキンググループにもメンバーとして参加しています。

Christoph Rätz（Dipl-Ing. BA）

University of CooperativeEducationシュトゥットガルト校のコンピューター･サイエンス科を卒業。VectorInformatik GmbHで、診断システム部のグローバルプロダクトラインマネージャーを務めています。

図4：AUTOSARとODXの組み合わせによる　　開発プロセス







ISOBUS準拠のデバイスは組み合わされるシステム/OEM間で互換性を持ち、製造元が異なっていても、農家が任意の組み合わせでトラクターと作業機を接続できるようになっています。使用する側から見れば簡単な仕組みのようですが、デバイスを開発する側がこれを実現するためには、特にテストフェーズにおいて相当なリソースが必要です。これから紹介するJohn Deere社の例は、業界で従来から行われている電子部品のテスト方法が、今や少なからず限界に達していることを示しています。群を抜くスピードで、より効率的に目的を達成する手段の1つが、シミュレーションした実装環境での自動テストシーケンスです。

ISOBUSタスクコントローラーのテストに新しい道を開く～柔軟性に乏しく、時間のかかるテスト方法からシミュレーションへの移行～

　多種多様な作業機に対応できる点で、トラクターはまさに多機能の農業機械であるといえるでしょう。トラクターがけん引や動力の提供のみを行い、作業機との間に他の相互関係がないのであれば、両者の動作はさほど複雑ではありません。ただし、単純な制御でしかないので効率も上がりません。しかも現代の農業には、播種量の調節や圃場で行った作業の記録といった機能を支えてくれる、インテリジェントで自動化されたソリューションが求められています。　しかし、求めに応じて農業技術が複雑化し、導入されるインテリジェント機能が増加するなか、これまでどおりの手軽さで農家が運転･操作を行えるようにするには、一層の努力が必要です。始動の工程に時間を取られるのは非生産的であり、現代のユーザーに受け入れられるものではありません。トラクターに時期に応じて多彩な作業機を接続した際に、トラクター側の制御装置につながれた作業機のことをスピーディーかつ正確に「理解」させなければならないのです。

ISOBUSへの準拠と互換性を最優先に

　ここで鍵を握るのがISOBUSのアプリケーションです。ISOBUSはトラクター、作業機、オペレーター用端末の相互通信とデータ交換を目的として策定されました。技術的な詳細はISO

標準規格11783シリーズで定義されており、そこではISO参照モデルから診断、ファイルサーバーに至るあらゆるトピックが網羅されています。製造元が異なるデバイス間で円滑な相互運用を実現するには、トラクターメーカーと作業機メーカーの両者が広範なテストを実施することが不可欠です。開発部門では必要とされる適合性試験以外にも、膨大なテストシナリオを実行しなければなりません。これに加えて、これらメーカーは定期的に開催される「プラグフェスト」に参加し、自社製品の機能が他社製品と現場でそのまま連携できるかを検証しています。　John Deere社は長い伝統を誇る、現代の農業技術の先駆的企業の1つです。同社はトラクターからスプレイヤー、ベーラー、そして播種機、収穫機、飼料裁断機に至る幅広い製品を製造しています。また、農業機械に留まらず、建設機械や林業機械、電気 /ガス /水道工事用機器、さらには芝生、住居、ゴルフコースなどの保守用機械も開発しています。同社はアメリカの農業機械専門企業として、ツヴァイブリュッケン、マンハイム、ブルフザルのドイツ子会社に加えて、2010年初頭にはカイザースラウテルンに新たな営業所を設置しました。新設された ETIC（EuropeanTechnology and Innovation Center）の社員は、他の拠点の開発部門と共同で、新技術の研究と、本番生産に向けた関連製品の仕上げ作業

に携わります。カイザースラウテルンで業務の中心となるのは、機械と農業用電子機器の知能化で精密農業を実現させることです。

農業用コンピューターから作業機の自動個別運用機能まで

　「精密農業」の概念には現在の農業技術のトレンドが反映され、それらに主眼が置かれています。精密農業の目標は、機械、貯蔵している種、肥料、燃料、時間などのあらゆる保有資源の最大活用により、収量と経済性を可能な限り最大化することです。農家はメモリーカードやUSBスティック、将来的には無線LANを通じて、予定している圃場作業のパラメーターを農作業用コンピューターからトラクター内のオペレーター用端末にアップロードします。　テレマティックスや衛星ナビゲーションも、ステアリングや進路誘導システム、さらには作業機の個別運用機能との組み合わせにより、重要な役割を果たします。これによって散布の場所を誤ることなく、播種と施肥をシームレスに行えるようになります。同時に、この技術によって楔形の圃場での領域の重なりを最小限に抑え、耕作区画の境界で原材料を停止させることができます。個別運用機能を持つ作業機は複数の機能ブロックがつなぎ合わされた構造をしてお


www.vector-japan.co.jpwww.vector-japan.co.jpwww.vector-japan.co.jp


り、それぞれを個別にオン/オフできます。すべての動作が記録されているため、トラクターの動きに応じて作業機が圃場の境界からはみ出したり、作業済みの箇所を再び通過した際には、対応する作業機の一部のブロックが自動的にオフになります。

デバイス制御のインターフェイスとなるタスクコントローラー

　こうした機能はすなわち、トラクターの電子部品に、その作業機の技術データと機能に関する正確な情報を与える必要があることを意味しています。トラクターの電子機器に組み込まれているISOBUSのオペレーター端末は、単なるユーザー用の制御･表示システムではなく、複数のアプリケーションを同時に実行するミニコンピューターである場合がほとんどです。タスクコントローラーはそうしたアプリケーションの1つで、ISO 11783の第10章に記述されています。これをうまく活用することで、TaskData.xmlファイルを介して農業経営システムとの仲立ちを行い、記録と制御を同時に行うシステムとして機能させることができます。John Deere社のGreenStar 2630ディスプレイでは、タスクコントローラーがJohn Deere社のドキュメンテーションシステムとISOBUS作業機とのインター

フェイスとなっています。タスクコントローラーは作業機との最初の接続時に、その作業機のジョブコンピューターから「デバイス記述ファイル」を読み込みます。このデバイス記述ファイルには一般に、作業機の作業幅やトラクターへのマウント方式、そして個別運用機能のある作業機であれば、制御対象機能ブロックの数とそれに関連する要素番号のように、タスクコントローラーが必要とするすべての情報が含まれています。こうすることで作業機はトラクターのオペレーター端末を通じて操作できるようになります（図1）。　タスクコントローラーは作業機で考えられるすべてのデバイス構成にシームレスに対応しなければなりません。それが可能であってこそ、ISOBUSオペレーター端末とそのアプリケーションは、市場のあらゆるISOBUS作業機と正しく連動するようになるのです。しかし、作業機はどれも動作が異なり、使用するタスクコントローラーの機能の組み合わせも異なります。そのためメーカー間ではテスト用として、自社の作業機製品に搭載する電子部品の機能を再現した、専用の互換性テスト用ECUを相互に提供しています。ただ残念ながら、このECUにはハードウェアとソフトウェア以外に、テスト技術者がデバイスロジックの包括的機能テストに必要とするコンポーネントは、ほとんど搭載されてきませんでした。

より効率的なテスト方法を求めて

　John Deere社のカイザースラウテルンでも、タスクコントローラーの機能と互換性のテストは作業機メーカーのテスト用ECUと実物のデバイスを使って行っていました。農用作業機と外部企業の多さを考えれば、これは非常に煩雑で時間のかかる作業です。理論的には、播種 /植え付け用、施肥用、薬剤散布用をはじめ、すべてのISOBUS装置をタスクコントローラーの全バージョンと突き合せてテストする必要があります。しかも、テスト用ECUのレイアウトや操作は標準化されていません。製造元はそれぞれ異なった操作指針に従っており、完全にシミュレーション型のECUもあれば、大部分が実際の電子部品と同じというECUもあります。テスト担当者はさまざまなユーザーマニュアルを調べ、数々の仮想のコントロール要素と機能を理解してからでなければ、実際の作業を行うことはできません。　こうした方法は、この業界ではごく一般的ではあるものの柔軟性に乏しく、満足のいくものとはいえません。そのためJohn Deere社は、より効率的なテスト方法の追求のために立ち上がりました。その結果、テスト技術者たちが見つけた解決策が、ISOBUSの要件にきめ細かく対応した開発、テスト、シミュレーション用ツールである、ベクターのCANoe.ISO11783です。

図1：John Deere社のISOBUSオペレーター端末とKverneland社の肥料散布機用操作インターフェイス


ISOBUSタスクコントローラーのテストに新しい道を開く

図2：CANoe.ISO11783でのトラクターと　　肥料散布機のシミュレーション

CANoe.ISO11783は製品開発の初期フェーズからテストフェーズ、保守に至る全体で、ISOBUSに適合した開発を約束します。ISOBUSの複雑な通信構造も幅広い方法で分析、視覚化、加工できます。「バーチャルターミナル」や「インタラクティブタスクコントローラー」といった機能を使えば、開発者のISO 11783の作業も簡素化します。たとえば、CANoe上でエミュレートされるターミナルは実際の端末とは違い、ディスプレイのタイプ、解像度、白黒設定などをさまざまに設定してシミュレーションに利用できます。「インタラクティブタスクコントローラー」では、そのターミナルを使って任意のISOBUSの実機からデバイス記述を読み込むことや、テストの前にシミュレーターを検証することができます。

より短い期間でより幅広いテストを

　John Deere社のテスト技術者たちは、タスクコントローラーのテストを作業機メーカーから独立して実施できるよう、特にこのツールのシミュレーション機能を活用しています（図2）。CANoeでは個別のECUだけでなく、ネットワーク全体のシミュレーションも可能です。開発工程の後半では、デバイスが全部存在するか、足りないデバイスをシミュレーションで置き換えることをしない限り、合理的かつ現実的なテストは

できません。タスクコントローラーを使えば、多岐にわたる作業機のバリエーションを幅広くシミュレーションできます。たとえばJohn Deere社では、外部メーカーとはまったく別個に作業を行えるようになり、もはや物理的なテスト用ECUに依存する必要はありません。自動テストや反復テストの実現に役立つのが、CANoeに組み込まれている「テスト機能セット」ツールです。システムをテストマスターとして動作させることも、また既存のテスト環境に挿入することもできます。COMや.NETなどのインターフェイスが用意されており、他のツールの制御や通信に利用できます。　作業機の個別運用機能の例でも分かるように、シミュレーションの柔軟性はJohn Deere社の負担を大幅に軽減しています。シミュレーションでは、工作機械のタイプとサイズを手間なく変更し、たとえばタスクコントローラーが8分割の機能ブロック構成ではなく16分割構成であるかをチェックすることや、制御対象の機能ブロック同士が隣接しておらず、前後にずれている作業機を定義することもできます。CANoe.ISO11783は標準化されたプロトコルを包括的に網羅しているため、同社はより短い期間で、より広い範囲のテストを実施することができるのです。特に、テスト用ECUでまったくサポートされていない、または一部しかサポートされていな

いアプリケーションについても同じことがいえます。たとえば運転速度のインテリジェントな制御のテストやハンドシェイクが正しいかのチェック、作業機から個別運用機能の準備完了が通知されないなどのエラーのシミュレーションがそうです。　 John Deere社のE T ICでは、CANoe.ISO11783は社外で製造された工作機械のシミュレーションだけでなく、ECUの社内開発にも使われています。テストではトラクターの実物のハードウェアを使用することも、それをシミュレーションすることも可能です。タスクコントローラーに複数のバージョンが存在し、それぞれにテストが必要な場合もありますが、ユーザーは実行するバリエーションを素早く切り替えることができます。CANoeは異なる拠点間での分散開発体制においても威力を発揮します。シミュレーション構成を部門間で手軽に交換できるだけでなく、それらを社内イントラネットや電子メールでアメリカの社員に送ることもできるのです。




将来の要件に対応する

　現在では、複雑なISOBUSと市場の多様な作業機に、古い、従来からの開発 /テスト方法で対処できると考えるには無理があります。それらの方法に替わるのが、標準に対する互換性をすべての製造フェーズで最大限に発揮する、CANoe.ISO11783などの開発、テスト、シミュレーション用ツールです。CANoe.ISO11783のマルチバス機能を使えば、ISOBUSとJ1939のメッセージを問題なくトレースWindowに表示し、解釈できます。また、このツールはISOBUSの全機能をカバーするほか、常に最新のリビジョンに対応しているため、John Deere社では時間面や人材面のコストを抑えつつ、より適切なテスト範囲を確保できます。同時に、農業機械を専門とする同社は、拡大するタスクコントローラー機能をテストする力を手に入れただけでなく、相手側のデバイスを随時シミュレーションし、今後策定されるISOBUS標準にも対応できるようになっています。　ここで注目したいのは、ISOBUS MultipleProduct Implementシミュレーター（図3）です。Multiple Product Implementに対応する多機能作業機の一例として、トウモロコシの施肥播種機を挙げることができます。これは種蒔きと固形肥料の散布を同時に実行できる装置

で、時間を短縮するだけでなく、トラクターが圃場を通過するのが1回で済むため、土壌侵食を抑えられるという利点があります。2011年初頭の時点で、こういったISOBUS装置を市場投入している作業機メーカーはまだありませんでした。そのため、こうした装置をタスクコントローラーでサポートするにはシミュレーションが唯一の方法でした。タスクコントローラーの基本的な動作を実現するだけのアプリケーションであれば、CANoeのシミュレーション機能をすべて理解している必要はありません。JohnDeere社の社員にとっては、高コストで柔軟性がなく、再現の難しいブラックボックスではなく、CANoeシミュレーションを作業機メーカーと交換できた方が嬉しいことでしょう。コンパイル済みのシミュレーションをソースなしで共有すれば社内のノウハウは簡単に保護できるため、それらが流出するのでないかという懸念も無用です。

提供元

見出し画像 /図1～3：John Deere社

関連リンク

.ISO11783バージョン7.6（CANoe用）

http://www.vector.com/vj_canoe_iso11783_jp.html

図3：シミュレーションを使ったタスクコントローラーの　　　　 ISOBUS Multiple Product Implementのサポート

Alexander Ostermüller（Graduate Engineer）カイザースラウテルンにあるJohn Deere社のETIC（European Technology and InnovationCenter）に勤務するテスト技術者。

執筆者

Peter Fellmeth（Graduate Engineer）

Vector Informatik GmbHのグループリーダーおよびプロダクトマネージャーとして、ISOBUS、J1939、イーサネット、Car2xに関連した製品の開発と顧客固有のプロジェクトを担当。ISO 11783（TC23/SC19/WG1）および SAE J1939の標準化に関わるさまざまなワーキングコミッティーに積極的に参加しています。

Technical Article 4

ISOBUSタスクコントローラーのテストに新しい道を開く



ECUをネットワーク接続した環境でデバッグする場合、特にエラーが散発的またはテスト車両でのみ発生するケースでは、デバッガーが有効でないことが少なくありません。そのような場合に役立つのが、実績ある測定/キャリブレーションプロトコルであるXCPのサービスです。本稿では、XCPを使ってAUTOSARベーシックソフトウェア（BSW）とソフトウェアコンポーネント（SWC）のプロセスをモニターする方法を説明します。こうした測定を行うには、ベーシックソフトウェアに一定の機能を追加しなければなりませんが、解析ツール専用の拡張機能を使えば、効率的なデバッグと手軽な評価が可能になります。

XCPによるAUTOSAR ECUソフトウェアの解析～AUTOSARベーシックソフトウェアの拡張でデバッグを便利に～



　現行のテストツールの多くは、レストバスシミュレーションを使って個別のECUをテストする方法に対応しています。このようなツールを使えば、ECUネットワークに依存せずに早い段階から必要な機能を検証し、ソフトウェア開発の初期から極めて高い品質を実現することができます。ただし、ECUがテストベンチ/テスト車両に設置されている場合や、機能がネットワーク内の複数のECUにまたがる場合、テストを徹底できず、エラーの発生場所を特定するのが難しくなります。これには以下のような原因があります。

> ECUがアクセスしにくい方法で設置されている>デバッグに使える接続端子が残っていない>異なるECU用のデバッガー間で、データに対する条件設定を共通で行うことができない

>テストツールを車両内に設置できない

　車両内でのデバッグが制限される物理的な条件に加えて、散発的にしか発生しないエラーがあることも原因の1つです。散発的なエラーの原因を実験室で特定するのは、容易なことではありません。

デバッグの要件

　エラーの原因を探す際、一般的には多様なソ


XCPによるAUTOSAR ECUソフトウェアの解析

フトウェア変数の値がチェックされます。また、トリガーポイントを基準にして、同時に複数のソフトウェアモジュールの変数を調べることも大切です。これにより、モジュール間での一貫性の状態をモニターすることができます。主な例として挙げられるのは、AUTOSARのBus State ManagerやCommunication Manager（ComM）などの、ステートマシンが相互に依存している「マネージャーモジュール」です。また、テスト技術者は、どのアプリケーション要求でECUがその測定された状態に入ったのかも判断しなければなりません。モジュールの境界を越えた因果関係の観察、たとえばシグナルの経路をバスレベルからアプリケーションレベルまで追跡するなどの操作も必要です。さらに、解析時にエラー履歴を再構築するためのタイムスタンプも必要となります。

AUTOSAR 3.xプロジェクトにおけるXCP

　AUTOSAR 3.x規格には、リモートデバッグのメカニズムに関する仕様は一切ありません。しかし、ここ数年、車両開発におけるECUの測定/キャリブレーションにXCP（Universal Measurementand Calibration Protocol）が広く使われるようになり、上記の要件を問題なく満たしています。XCPには、バスシステム経由で変数を読み書きするメカニズムが用意されています。DAQ（Data

Acquisition）リストを利用すれば、共通のタイムスタンプを使って、複数の変数を一貫して測定することができます。また、ダイナミックDAQリストを使えば、読み出すデータレコードを測定中に再構成することが可能です。これらによって、通信バスで利用可能な帯域幅を最大限に活用する手段を得ることができるのです。　XCPでの測定には通常、1つまたは複数のA2Lファイルが使われます。A2LファイルにはECU内の関連する測定オブジ�

Documents

Vector Journal Vol... DaVinci/MICROSARを使用したAUTOSAR ECUの開発プロセスCover Story Vector Journal Vol.4 05 ⑤ECUソフトウェア詳細設計 ECUソフトウェア詳細設計では、ECUのデ