01

他の診断データ形式とDEXTの比較

DEXTはAUTOSAR 4.2.1ではじめて公開されました。当初標準化されたのはUDSを使用して伝送されるデータの記述と故障情報です。AUTOSAR 4.3.0になるとOBD-II、WWH-OBD、FIM (AUTOSAR Function Inhibition Manager)、SAE J1939に対応する拡張が追加され、結果としてDEXTは、AUTOSARでサポートされるすべての診断用ベーシックソフトウェアモジュールの設定を、これらの内容のレベルでカバーするようになりました。DEXTは各プロトコルで伝送されるデータを記述できるだけでなく、 ECUアプリケーションソフトウェア内のデータの送信元も記述 できます。これらの両方のタイプの情報が揃わなければ診断用 ベーシックソフトウェアの完全な設定はできません。診断

プロトコルと、特に、診断サービスおよびネットワーク上のデータ転送は記述されません。これらの要求は、UDSとOBD-IIの両標準規格から参照されます。一方、ODXは汎用診断テスターのための診断情報の記述形式 としての地位を確立しています。ODXはECUとテスターの間で 伝送されるデータ、そして診断テスターでのそのデータの解釈 方法に加え、診断プロトコルも記述します。テスターでデータを 処理する際はECUのデータソースは不要なため、ODXでは指定されません。それにもかかわらず、ODXは主にECUソフトの設定のための、初期設定の入力に使用される場合があります。ただし、その診断データは、手作業か、または専用のプロセスのステップによってECUアプリケーションとリンクしなければなりません。ODXとECUソフトウェアの間に発生するこのような情報のギャップは、

AUTOSARで診断開発 –自動車メーカー／サプライヤーの利点

車両の診断機能の開発に際して自動車メーカーやTier 1サプライヤーが使用するプロセスは多岐にわたります。そこでは多様な仕様 フォーマットが使用され、実装されるツールは一般に各社固有のプロセスに合わせてカスタマイズされています。そのため、いざ開発 パートナーと診断仕様のやりとりをするとき、相手のツールチェーンで使用するとなると問題が発生し、たとえ情報を取りこぼさずに データを共有できるとしても、毎回かなりの時間を取られることになります。この診断機能開発にまったく新しい可能性を広げてくれるのがAUTOSAR Diagnostic Extract Template (DEXT) です。診断に関係するベーシックソフトウェアモジュールを、たとえば 自動車メーカーとTier 1サプライヤーの間で、あるいは自動車メーカー間の提携の際に、企業の枠を越えて統一的に設定できます。 従来であればTier 1サプライヤーのインテグレーターが行っていた作業も、DEXTを使用すれば分散して行うことが可能になります。

02

Technical Article: Diagnostic Development with AUTOSAR – the Benefits for Vehicle Manufacturers and Suppliers - 9/2018

ただし、DIDの読取り、書込み、上書きには、やはりベーシックソフトウェアとアプリケーションとのマッピングが必要です。そのためDEXTには追加のエレメントであるマッピング情報が含まれて います。これはルーチン、DIDデータ、イベントなどのベーシック ソフトウェアに含まれる診断エレメントと、アプリケーション レイヤーのソフトウェアコンポーネント（SWC）の間の接続を記述するものですが、そのためには、ソフトウェアコンポーネントの インターフェイスを、AUTOSARで定義されているモデリングの パターンに沿った方法で適切にモデル化しなければなりません。 通信パターンには、クライアント／サーバーインターフェイスに 対する関数呼出しにアクセスしたり、送信者／受信者インター フェイスを介してデータを読出し／書込みしたりするための さまざまなものが存在します。以前であれば、ベーシックソフト ウェアとアプリケーションソフトウェアのポートを結ぶ、数千に およぶこういった関係をインテグレーターが手動で設定し なければなりませんでした。DEXTを使用すれば、この作業を 自動化し、自動車メーカー／Tier 1サプライヤーが実施できます。インテグレーターはこのようなマッピングを行うことで、膨大な 数のさまざまな接続を手作業で生成しなくても済みます。これに よって誤りの恐れが減る一方、時間を節約し、品質を高めることができます。

診断の分散開発におけるシナリオと役割

今日使用されている診断開発プロセスは、今のところそれぞれの間にかなりの違いがあります。ツールとその仕様情報の交換形式だけでなく、自動車メーカーとTier 1の関与のレベルが大きく違うのです。実際の現場では、自動車メーカーが最初から最後まで 設計するケースから、自動車メーカーとTier 1サプライヤーが 分担して診断開発を行うケース、そしてTier 1サプライヤーが単独で開発を完成させるケースにいたるまで、あらゆるバリエーションに直面します。表1は一般的な診断プロセスの概要です。DEXTを使用すれば、これら3つのプロセスのバリエーションの すべてに対応できます。AUTOSAR arxml形式の例にもれず、 DEXTでもエレメントのほぼすべてがオプションです。プロセスの各ステップでは、DEXTを最初に作成して内容を追加していくことも、あるいはプロセスの最後にDEXTを拡張することもできます。作成されたデータは常に本質的に有効で、交換が可能です。どのデータをどのプロセスのステップで追加するかは重要ではなく、 適用するプロセスで定義するだけで済みます。

フォールトメモリーの記述で特に顕著です。たとえば、エラー検出に使用されるデバウンスや置換のアルゴリズムはベーシックソフトウェアにとって根本的に重要なものですが、ODXにはこの情報がまったくありません。さらに、自動車メーカーのODXオーサリングガイドライン(AGL)はそれぞれ大きく異なっており、これがECU 設定の交換を複雑化する一因ともなっています。AUTOSAR-ECUC形式をプロセスのデータ交換とベーシック ソフトウェア設定の最初の入力データに使用しても、実際のところ その目的はほとんど達成できません。ECUC形式は頻繁に変更 されており、AUTOSAR仕様の新バージョンが出るたびにそれへの適合が行われます。この形式は主に組込ソフトウェアのコード ジェネレーターの入力形式として設計されているのです。また、 ECUCではメーカー固有の拡張が許容されるため、中立的な交換形式には不向きです。

AUTOSAR DEXTはベーシックソフトウェアの入力データに関する要求を満足するよう設計されています。主なエレメントには以下のものがあります（図1）。

> UDS、OBD、WWH-OBD、J1939に対応する各種の診断サービスとそれに関連するサブサービス >故障経路と故障に関する付帯情報 >各診断データと、それに関する付帯情報 >各診断データエレメントのアプリケーションソフトウェアへの マッピング > Function-inhibition (FiM)

以下の例でデータ識別子（D I D）に基づいたAUTOSAR Diagnostic Extractの優位性を紹介します。DIDをどのように モデル化するかは、AUTOSARメタモデルにより形式的に定義 されます。ODXとは異なり、そこに解釈の余地はなく、したがってツール間の仕様情報交換時に誤解が生じるリスクもありま せん。DIDの存在はDiagnosticDataIdentifierのインスタンス によって指示されます。このインスタンスにはDIDを表す16ビット数が含まれていますが、これはUDSに必要となります。さらに、 このインスタンスには1つ以上のデータエレメントがまとめられており、DIDデータの名前と型が定義されています。AUTOSARでは、データ型のモデリングに既存のSystem Templateメタモデルが再利用されます。DID自体は、サービスインスタンスである DiagnosticReadDataByIdentifier、DiagnosticWriteData-ByIdentifier、DiagnosticIOControlにより、Diagnostic-DataIdentifierを参照する形で診断サービスに使用できます。 診断用ベーシックソフトウェア（BSW）でDIDの設定を定義するには、このほかに必要なものはありません。

図1： AUTOSAR Diagnostic Extractのエレメント

表1： 自動車メーカーとTier 1サプライヤーの間の一般的な診断プロセス

03

Technical Article: Diagnostic Development with AUTOSAR – the Benefits for Vehicle Manufacturers and Suppliers - 9/2018

これらの要求から、System Extractのソフトウェアコンポーネントインターフェイスがarxml形式で導出されます。これらのソフト ウェアコンポーネントインターフェイスは、診断オブジェクトのパラメーターも定義します。油温センサーの例でいえば、ソフトウェアコンポーネントのポートが現在の温度値を提供し、そのポートの インターフェイスが、測定値が16ビット値／32ビット値のいずれであるかと、その変換式、そして使用する単位を定義します。この 情報を使用して、このワークフロー専用に開発されたCANdela Studioのソフトウェアコンポーネント同期機能が、以下の診断 エレメント用の適切な診断データを自動的に生成します。

>読込み、書込み、入出力制御用の診断データ識別子（DID） >ルーチン制御識別子（RID） >イベントとDTC

この例では、診断担当者はCANdelaStudioに「ReadDataBy-Identifier」という診断サービスを作成しており、これには符号なし16ビット値、分解能0.1ケルビンの「Temperature」というデータ エレメント、同じデータエレメントを持つ入出力サービス、センサーの故障を表すDTCが含まれています。診断担当者はまた、診断 通信で油温にアクセスする際に使用される識別子も定義して います。さらに、CANdelaStudioにはソフトウェアコンポーネントが温度を提供するポートと、そのポートからデータを読み込む診断サービスが保存されています。この情報を使用することにより、CANdela StudioはDEXT形式をマッピング情報も含めてエクスポートできます。DaVinci Configurator ProはDEXT形式を読み込み、診断用ベーシックソフトウェアモジュールの設定をそれから導出し ます。そして、AUTOSAR DEXTのマッピング情報との互換性を 保ちながら、診断用ベーシックソフトウェアモジュール用のソフト ウェアコンポーネントインターフェイスを生成し、それをアプリ ケーションソフトウェアコンポーネントのポートに接続します。

まとめと展望

AUTOSAR Diagnostic Extractによって、診断開発の分野に新たな可能性が開かれました。ベーシックソフトウェアの設定を考慮 したデータの正確な記述から、自動車メーカーとTier 1サプライ ヤーによる診断の分散開発、そしてECUへの診断機能の自動統合に対するトップダウンのアプローチにいたる全体で、ベクターの ツールチェーンはこれらの機能を活用しつつ、ODXとDEXTの データの一貫性を保証します。AUTOSAR DEXTはAUTOSAR ClassicとAUTOSAR Adaptiveの両方のAUTOSARプラットフォームで使用できます。AUTOSAR DEXTは当初はAUTOSAR Classic用に開発されたものであり、 またAUTOSAR Adaptiveでは唯一の診断記述形式でもあり ます。そのため、紹介した方法はAUTOSAR Adaptiveプラット フォームを基盤とする開発でも使用可能です。

これらのプロセスをサポートするツールチェーンへの要求

診断開発のプロセスに用いられるツールチェーンは、先に述べたシナリオへの適合が可能でなければなりません。プロセスの開始時には要求管理システム（RMS）で診断要求を定義する必要が あり、この診断要求からアプリケーションソフトウェアに対する要求とそれに関連する診断サービスの要求を導出できます。要求は 一般に、ソフトウェアコンポーネントと適切なベーシックソフト ウェア設定の2種類の形でそれぞれ異なる役割によって実装 され、ECU統合の際にインテグレーターによって統合されます。 先に述べたDEXTのソフトウェアコンポーネントとベーシックソフトウェア間のマッピング情報がここで威力を発揮します。プロセスの全容を図2に示します。トップダウンのプロセスでは、診断用アプリケーションソフトウェアを最初に開発するか、あるいは既存のソフトウェアを再利用して、アプリケーションソフトウェアの要求とインターフェイス記述から診断用の入力データを導出します。既存の多くのプロセスでは、 要求やアプリケーションソフトウェアに診断データを適合する方法が取られますが、それに比べると、これには大きな優位性があり ます。既存の方法は、時間のかかる、手動での調整作業になることが多いのです。DEXT形式の作成と並行してODXデータも作成しなければなりません。共通のデータソースからODXとDEXTのデータを生成すれば、診断テスターの挙動がECUの診断ソフトウェアと確実に一致するようになります。

ツールチェーンを基にした例

図3に、ベクターのツールを使用した、これらの要求を満たす診断開発用のツールチェーンの例を示します。このツールチェーンは 要求およびシステム設計用のPREEvision、診断仕様開発ツールのCANdelaStudio、ベーシックソフトウェアの設定用のDaVinci Configurator Proの各ツールから構成されています。診断要求は開発の早い段階でPREEvisionで定義します。これが油温セン サーに対する要求だとすると、油温を読み込むサービス、入出力 制御によってセンサー値を上書きするサービス、そして、油温センサーの異常を伝える、発生しうる1つ以上のDTCのサポートがこのセンサーの診断機能に含まれていなければなりません。

図2： 自動車メーカーとTier 1サプライヤーの間で行われる診断プロセス

04

Technical Article: Diagnostic Development with AUTOSAR – the Benefits for Vehicle Manufacturers and Suppliers - 9/2018

図3： ベクターのツールチェーンを例とした診断ワークフロー

Wigbert Knape (Dipl.-Ing.)ベクター（シュツットガルト）の組込ソフトウェアおよび組込システムプロダクトラインでプロダクトマネージャーを務める。

本稿は、ドイツで発行された『Hanser Automotivemagazine, issue 9/2018』に掲載された記事内容を和訳したものです。

画像提供元：Vector Informatik

■ 本件に関するお問い合わせ先ベクター・ジャパン株式会社 営業部E-Mail: sales@jp.vector.com

Matthias Wernicke (Dipl.-Ing. (FH))ベクター（シュツットガルト）の組込ソフトウェアおよび組込システムプロダクトラインでAUTOSARツールのプロダクトマネージャーを務める。

Klaus Beiter博士ベクター（シュツットガルト）の診断プロダクトラインで開発チームの責任者を務める。

執筆者：