ISO 13400-2:2019 道路車両—インターネットプロトコル(DoIP)を介した診断通信—パート2:トランスポートプロトコルとネットワーク層サービス | ページ 3

※一部、英文及び仏文を自動翻訳した日本語訳を使用しています。

導入

車両診断通信は、最初に法制化された排出ガス関連診断の導入から開発され、長年にわたって進化し、現在では排出ガス関連診断から、校正や電子部品ソフトウェアのアップデートなどの車両メーカー固有のアプリケーションに至るまで、さまざまなユースケースをカバーしています。 。

新しい車載ネットワーク通信技術の導入に伴い、車両のサーバーとクライアント DoIP エンティティの間のインターフェイスは、最適化されたデータ リンク層定義とトランスポート プロトコル開発を必要とする新しいネットワーク通信技術それぞれの固有の特性に対処するために何度か調整されてきました。新しい車載ネットワークを診断通信に使用できるようにするためです。

サーバーのメモリ サイズの増加、ソフトウェアの更新需要の増加、およびこれらの制御ユニットによって提供される機能の増加に伴い、接続ネットワークとバスの技術は、コンピュータ ネットワークと同様の複雑さと速度のレベルにまで引き上げられています。さまざまなアプリケーション (X-by-Wire, インフォテインメント) には高帯域幅のリアルタイム ネットワーク (FlexRay, MOST など) が必要ですが、車両に直接インターフェイスを提供するように適合させることはできません。これには、車載ネットワークとクライアント DoIP エンティティへの車両インターフェイスの間でメッセージをルーティングおよび変換するゲートウェイが必要です。

ISO 13400 のすべての部分は、IP 通信ネットワーク上に実装された車両診断システムに適用できます。

ISO 13400 シリーズは、IP 通信リンク上で実装される車両診断システムの共通要件を定義するために確立されました。

ISO 13400 は主に診断システムを目的としていますが、トランスポート プロトコルとネットワーク層サービスを必要とする他の IP ベースのシステムの要件にも適合するように開発されました。

ISO 13400 シリーズの目的は、標準化された車両インターフェイスを記述することです。

  • 車載ネットワーク技術をクライアントの DoIP エンティティ車両インターフェース要件から分離し、長期安定した外部車両通信インターフェースを実現します。
  • 既存の業界標準を利用して、法定の診断通信やメーカー固有のユースケースに使用できる長期安定した最先端の通信標準を定義します。
  • 既存のアダプテーション層を使用することで、有線および無線接続を含む新しい物理層およびデータリンク層に簡単に適応できます。
  • 車両内部および車両外部の DoIP エンティティの接続を可能にします。

これを実現するために、ISO/IEC 7498-1 および ISO/IEC 10731 [ 1] で規定されている Open Systems Interconnection (OSI) 基本参照モデルに基づいており、通信システムを 7 つの層に構造化しています。

図 1 は、関連規格を含む、この文書の範囲を超える通信フレームワークの概要を示しています。

  • ISO 14229-1 [ 3] 、ISO 14229-2 [ 4] 、および ISO 14229-5 [ 5] で構成される車両診断通信フレームワーク。
  • プレゼンテーション層の標準。たとえば、自動車メーカー (VM) 固有または ISO 22901 ODX [ 6]
  • ISO 13400-3 と ISO 13400-4 で構成される OSI 下位層フレームワーク[ 2]

ISO 13400 シリーズと ISO 14229-5 [ 5] 、すべてのレイヤーと診断サービスに適用されるため、OSI サービス規約 (ISO/IEC 10731) [ 1] で指定された規約に基づいています。

図 1 — OSI モデルに従った DoIP ドキュメントのリファレンス

図1

図 2 は、機能の観点から車両ネットワーク アーキテクチャの概略図を示しています。

図2 —車両ネットワークアーキテクチャの概略図(機能図)

図_2

このプロトコル標準は、車両のネットワーク アーキテクチャに応じて、1 つ以上の DoIP エンティティによって実装されます。図 2 は、DoIP エッジ ノードに接続されているクライアント 1 (外部クライアント) と車両の内部ネットワーク内のクライアント 2 (内部クライアント) を示しています。特に明記されていない限り、DoIP クライアント エンティティは、接続されているネットワークに関係なく同じように動作すると想定されます。

必要に応じて、この文書では要件またはステートメントを適用するために「内部クライアント」と「外部クライアント」を区別します。

この文書では、要件には「 X.DoIP-yyy 」形式の一意の番号が割り当てられ、要件の追跡と参照が容易になります。

  • X = OSI レイヤ番号。そして
  • DoIP-yyy = 要件番号;そして
  • xL = x = OSI 層の略称 [8 = APP, 7 = AL, 6 = PL, 5 = SL, 4 = TL, 3 = NL, 2 = DLL, 1 = PHY, 0 = SPP

注:文書の作成中に個々の要件の順序が変更されたため、この文書の要件には連続した番号が付けられていません。

「車両は…を実装しなければならない」として定式化された要件は、特に明記されていない限り、これがすべての DoIP エンティティが必要な機能を実装するための要件であることを意味します。車両ネットワーク上に複数の DoIP エンティティが存在する場合、クライアント DoIP エンティティがこのプロトコル標準をサポートする個々の DoIP ゲートウェイを識別できるように、実装の詳細が各 DoIP エンティティで若干異なる場合があります (識別目的など)

RFC 文書への参照が行われる場合、これらの文書では要件を表現するために「しなければならない/してはならない」という形式が使用されていることに注意してください。

Introduction

Vehicle diagnostic communication has been developed starting with the introduction of the first legislated emissions-related diagnostics and has evolved over the years, now covering various use cases ranging from emission-related diagnostics to vehicle-manufacturer-specific applications like calibration or electronic component software updates.

With the introduction of new in-vehicle network communication technologies, the interface between the vehicle's servers and the client DoIP entity has been adapted several times to address the specific characteristics of each new network communication technology requiring optimized data link layer definitions and transport protocol developments in order to make the new in-vehicle networks usable for diagnostic communication.

With increasing memory size of servers, the demand to update this increasing amount of software and an increasing number of functions provided by these control units, technology of the connecting network and buses has been driven to a level of complexity and speed similar to computer networks. Various applications (x-by-wire, infotainment) require high band-width and real-time networks (like FlexRay, MOST), which cannot be adapted to provide the direct interface to a vehicle. This requires gateways to route and convert messages between the in-vehicle networks and the vehicle interface to client DoIP entity.

All parts of ISO 13400 are applicable to vehicle diagnostic systems implemented on an IP communication network.

The ISO 13400 series has been established in order to define common requirements for vehicle diagnostic systems implemented on an IP communication link.

Although primarily intended for diagnostic systems, ISO 13400 has been developed to also meet requirements from other IP-based systems needing a transport protocol and network layer services.

The intent of the ISO 13400 series is to describe a standardized vehicle interface which

  • separates in-vehicle network technology from the client DoIP entity vehicle interface requirements to allow for a long-term stable external vehicle communication interface,
  • utilizes existing industry standards to define a long-term stable state-of-the-art communication standard usable for legislated diagnostic communication as well as for manufacturer-specific use cases,
  • can easily be adapted to new physical and data link layers, including wired and wireless connections, by using existing adaptation layers, and
  • allows connections of vehicle-internal and vehicle-external DoIP entities.

To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in ISO/IEC 7498-1 and ISO/IEC 10731[1], which structures communication systems into seven layers.

Figure 1 illustrates an overview of communication frameworks beyond the scope of this document including related standards:

  • Vehicle diagnostic communication framework, which is composed of ISO 14229-1[3], ISO 14229-2[4], and ISO 14229-5[5].
  • Presentation layer standards, for example vehicle manufacturer- (VM-) specific or ISO 22901 ODX[6].
  • OSI lower layers framework, which is composed of ISO 13400-3 and ISO 13400-4[2].

The ISO 13400 series and ISO 14229-5[5] are based on the conventions specified in the OSI Service Conventions (ISO/IEC 10731)[1] as they apply for all layers and the diagnostic services.

Figure 1 — DoIP document reference according to OSI model

Figure_1

Figure 2 illustrates vehicle network architecture schematics from a functional viewpoint.

Figure 2 — Vehicle network architecture schematics (functional view)

Figure_2

This protocol standard is implemented by one or more DoIP entities, depending on the vehicle’s network architecture. Figure 2 illustrates a client 1 (external client), which is connected to the DoIP edge node and a client 2 (internal client) in the vehicle's internal network. If not stated otherwise, the DoIP client entities are assumed to behave the same regardless to which network they are connected.

If necessary, this document distinguishes between an “internal client” and “external client” to apply a requirement or statement.

In this document, the requirements are assigned a unique number of the form" X.DoIP-yyy ", allowing for easier requirement tracking and reference.

  • X = OSI layer number; and
  • DoIP-yyy = requirement number; and
  • xL = x = OSI layer abbrevation[8 = APP, 7 = AL, 6 = PL, 5 = SL, 4 = TL, 3 = NL, 2 = DLL, 1 = PHY, 0 = SPP].

NOTE Requirements in this document are not numbered sequentially because the order of individual requirements changed during document development.

Requirements formulated as “The vehicle shall implement …” imply that this is a requirement for all DoIP entities to implement the required functionality if not explicitly stated otherwise. If multiple DoIP entities are present on a vehicle network, implementation details may differ slightly for each DoIP entity (e.g. for identification purposes), so that the client DoIP entity is able to identify the individual DoIP gateways that support this protocol standard.

Where reference is made to RFC documents, note that the forms “shall/shall not” are used to express requirements in these documents.