LoginSignup
1
0

More than 1 year has passed since last update.

ISO 13400-2:2019 Road vehicles - Diagnostic communication over Internet Protocol (DoIP) - Part 2: Transport protocol and network layer services

Last updated at Posted at 2022-02-01

ISO 13400-2:2019 Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 2: Transport protocol and network layer services

2 Normative references

ISO/IEC 7498-1:1994, Information processing systems — Open systems interconnection — Basic reference model
ISO 13400-3, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 3: Wired vehicle interface based on IEEE 802.3
ISO/IEC/IEEE 8802-3, Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Standard for Ethernet
IETF RFC 768, User Datagram Protocol
IETF RFC 791:1981, Internet Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 792, Internet Control Message Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 793, Transmission Control Protocol — DARPA Internet Program — Protocol Specification
IETF RFC 826, An Ethernet Address Resolution Protocol
IETF RFC 1122, Requirements for Internet Hosts — Communication Layers
IETF RFC 2131, Dynamic Host Configuration Protocol
IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) — Specification
IETF RFC 2375, IPv6 Multicast Address Assignments
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6)
IETF RFC 3927, Dynamic Configuration of IPv4 Link-Local Addresses
IETF RFC 4291, IP Version 6 Addressing Architecture
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol Version 6 (IPv6) Specification
IETF RFC 4492, Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
IETF RFC 4702, The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2
IETF RFC 8446:2018, The Transport Layer Security (TLS) Protocol Version 1.3

content

Contents Page
Foreword
Introduction
1 Scope
2 Normative references

3 Terms and definitions
4 Symbols and abbreviated terms.
4 4.1 Symbols
4 4.2 Abbreviated terms
5 Conformance.
6 DoIP introduction
6.1 General information
6.2 Connection establishment and vehicle discovery.
6.2.1 Direct connection scenario
6.2.2 Network connection scenario.
6.2.3 Internal tester scenario (optional).

6.2.4 Unsecured DoIP session

6.2.5 Secured (TLS) DoIP session.
6.3 Vehicle network integration
6.3.1 Vehicle identification.
6.3.2 Multiple vehicles in a single network
6.4 Communication examples using message sequence charts
6.5 IP-based vehicle communication protocol — General information.
7 Application (APP) requirements
7.1 APP implementation of DoIP requirements
7.2 APP data transmission order.
7.3 APP DoIP entity synchronization of a vehicle's GID.
7.4 APP vehicle identification and announcement request message.
7.5 APP diagnostic power mode information request and response.
7.6 APP DoIP entity status information request and response.
7.7 APP timing and communication parameters.
7.8 APP logical addressing

7.9 APP communication environments and recommended timings

7.10 APP DoIP entity functional requirements

8 Service interface
8.1 General

8.2 Service primitive parameters (SPP)

8.2.1 SPP data type definitions.

8.2.2 SPP DoIP_AI, address information.
8.2.3 SPP Length, length of PDU

8.2.4 SPP PDU, protocol data unit

8.2.5 SPP DoIP_Result.
8.3 SPP DoIP layer service interface
8.3.1 SPP DoIP_Data.request

8.3.2 SPP DoIP_Data.confirm

8.3.3 SPP DoIP_Data.indication
9 Application layer (AL)
9.1 AL dynamic host control protocol (DHCP).
9.1.1 AL general.
9.1.2 AL IP address assignment.
9.1.3 AL IP address validity and renewal

9.2 AL generic DoIP protocol message structure

9.3 AL handling of UDP packets and TCP data.
9.4 AL supported payload types over TCP and UDP ports

9.5 AL diagnostic message and diagnostic message acknowledgement.
9.6 AL alive check request and alive check response.
10 Transport layer security (TLS)
10.1 TLS secure diagnostic communication
10.2 TLS DoIP application profile

10.2.1 TLS general

10.2.2 TLS accepted TLS versions for DoIP

10.2.3 TLS accepted cipher suites.
10.2.4 TLS accepted TLS extensions
11 Transport layer (TL)
11.1 TL transmission control protocol (TCP)

11.2 TL user datagram protocol (UDP)
11.3 TL handling of UDP messages.
12 Network layer (NL)
12.1 NL internet protocol (IP).

12.2 NL IPv4 address resolution protocol (ARP)

12.3 NL IPv6 neighbour discovery protocol (NDP)

12.4 NL internet control message protocol (ICMP)

12.5 NL IP-based vehicle communication protocol

12.6 NL socket handling
12.6.1 NL connection states
12.6.2 NL general inactivity timer

12.6.3 NL initial inactivity timer

12.6.4 NL socket handler and alive check

13 Data link layer (DLL)
13.1 DLL general
13.2 DLL MAC-layer
Bibliography

3 Terms and definitions

For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/

3.1 diagnostic power mode

abstract vehicle internal power supply state, which affects the diagnostic capabilities of all servers on the in-vehicle networks and which identifies the state of all servers of all gateway sub-networks that allow diagnostic communication
Note 1 to entry: The intent is to provide information to the client DoIP entity about whether diagnostics can be performed on the connected vehicle or whether the vehicle needs to be put into a different diagnostic power mode (i.e. technician interaction required). In this document, the following states are relevant: Not Ready (not all servers accessible via DoIP can communicate), Ready (all servers accessible via DoIP can communicate) and Not Supported (the Diagnostic Information Power Mode Information Request message is not supported).

3.2 DoIP edge node

host (3.4) inside the vehicle, where an Ethernet activation line in accordance with ISO 13400-3 is terminated and where the link from the first node/host in the external network is terminated
[SOURCE:ISO 13400‑3:2011, 3.1.2, modified — definition editorially revised.]

3.3 DoIP entity certificate

certificate issued by an intermediate CA (3.5)to the DoIP entity presented during the TLS handshake to the client DoIP entity to verify the authenticity of this DoIP entity

3.4 host

node connected to the IP-based network

3.5 intermediate certificate authority

intermediate CA
authority, which issues subordinal certificates to another intermediate CA or DoIP entities

3.6 intermediate certificate

certificate either stored in the client DoIP entity or is presented during authentication together with the end node certificate to complete the chain of trust

3.7 invalid source address

address outside the reserved range for client(s) DoIP entity

3.8 logical address

address identifying a diagnostic application layer entity

3.9 network node

device connected to the IP-based network (e.g. Ethernet) and which communicates using Internet protocol but does not implement the DoIP protocol
Note 1 to entry: Some network nodes might also be connected to a vehicle sub-network (3.14), but they are not DoIP gateways as they don’t implement the DoIP protocol. Consequently, these network nodes do not interact with (e.g. respond to) DoIP-compliant client DoIP entity.

3.10 root certificate authority

authority, which acts as the root of trust
Note 1 to entry: Typically issues intermediate certificates (3.6) to allow an intermediate CA (3.5) to further submit certificates.

3.11 root certificate

certificate created by the root certificate authority (3.10) and used as the trust anchor
Note 1 to entry: It is securely stored and used by all entities that wants to validate end node certificates (e.g. from the DoIP entity) together with all necessary intermediate certificates (3.6) in the chain of trust.

3.12 socket

unique identification, as defined in IETF RFC 147, to or from which information is transmitted in the network

3.13 unknown source address

address not listed in the connection table entry

3.14 vehicle sub-network

network not directly connected to the IP-based network
Note 1 to entry: Data can only be sent to and from a vehicle sub-network through the connecting DoIP gateway.

Bibliography

[1] ISO/IEC 10731:1994, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[2] ISO 13400-4, Road vehicles — Diagnostic communication over Internet Protocol (DoIP) — Part 4: Ethernet-based high-speed data link connector
[3] ISO 14229-1, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer
[4] ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services
[5] ISO 14229-5, Road vehicles — Unified diagnostic services (UDS) — Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP)
[6] ISO 20730-1, Road vehicles — Vehicles roadworthiness interface for electronic Periodical Technical Inspection (ePTI) — Part 1: Communication requirements
[7] ISO 22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification
[8] ISO 27145-1, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 1: General information and use case definition
[9] ISO 27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 3: Common message dictionary
[10] IANA Ports, Port Numbers, IANA. Available at: http://www.iana.org/assignments/port-numbers (last updated 29 November 2011)
[11] IANA Protocols, Protocol Numbers, IANA. Available at: http://www.iana.org/assignments/protocol-numbers (last updated 1 November 2011)
[12] IEEE EUI-48, Guidelines, Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48TM). Available at: http://standards.ieee.org/develop/regauth/tut/eui48.pdf
[13] IETF RFC 147, The Definition of a Socket
[14] IETF RFC 3942, Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options
[15] IETF RFC 4213, Basic Transition Mechanisms for IPv6 Hosts and Routers
[16] IETF RFC 5220, Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules
[17] IETF RFC 5735, Special Use IPv4 Addresses
[18] IETF RFC 6298, Computing TCP’s Retransmission Timer
[19] ISO 3779, Road vehicles — Vehicle identification number (VIN) — Content and structure

参考資料

Diagnostics over Internet Protocol

@kazuo_reve AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理

自己参照

@kazuo_reve「AUTOSARのClassic PlatformとAdaptive PlatformにおけるDiagnosticsの違いを整理」で慌てて

ISO Road vehicles Diagnostics 規格調査中 100規格、100記事をめざして。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0