ISO/TC 22/SC 31 - Data communication

This document specifies conformance tests in the form of an abstract test suite (ATS) for a system under test (SUT) that implements an electric-vehicle communication controller (EVCC) or a supply-equipment communication controller (SECC) for all common requirements specified in ISO 15118-20 that are independent of a particular charging type (AC, DC, ACD, WPT charging). These conformance tests specify the testing of capabilities and behaviours of an SUT, as well as checking what is observed against the conformance requirements specified in ISO 15118-20 and against what the implementer states the SUT implementation's capabilities are. The capability tests within the ATS check that the observable capabilities of the SUT are in accordance with the static conformance requirements specified in ISO 15118-20. The behaviour tests of the ATS examine an implementation as thoroughly as practical over the full range of dynamic conformance requirements specified in ISO 15118-20 and within the capabilities of the SUT. A test architecture is described in correspondence to the ATS. The abstract test cases in this document are described leveraging this test architecture and are specified in descriptive tabular format covering the ISO/OSI layer 3 to 7 (network to application layers). In terms of coverage, this document only covers normative sections and requirements in ISO 15118-20. This document additionally refers to specific tests for requirements on referenced standards (e.g. IETF RFCs, W3C Recommendation, etc.) if they are relevant in terms of conformance for implementations according to ISO 15118-20. However, it is explicitly not intended to widen the scope of this conformance specification to such external standards, if it is not technically necessary for the purpose of conformance testing for ISO 15118-20. Furthermore, the conformance tests specified in this document do not include the assessment of performance nor robustness or reliability of an implementation. They cannot provide judgments on the physical realization of abstract service primitives, how a system is implemented, how it provides any requested service, or the environment of the protocol implementation. Furthermore, the abstract test cases specified in this document only consider the communication protocol and the system's behaviour specified in ISO 15118-20. Power flow between the EVSE and the EV is no prerequisite for the test cases specified in this document.

This document specifies the Extensible SECC Discovery Protocol (ESDP) as well as the Event Notification Protocol (ENP) that are intended to be used in conjunction with other protocols as defined in ISO 15118-2 and ISO 15118-20 as well as documents from other organizations such as DIN or SAE (e.g. DIN/TS 70121 or SAE J2847/2). These protocols can be used in addition to the existing SECC Discovery Protocol defined by the aforementioned documents. They offer additional functionality that makes the digital communication for EV charging more robust and allows to better determine the reason of failures. In this document, the scope is limited to the already existing communication protocols. Thus, it is only an addition to already existing communication protocols. Basic requirements regarding for example IP communication, or the Vehicle-To-Grid Transport Protocol (V2GTP) are not needed, as they are already specified in the respective document of the used communication protocol.

This document specifies the LIN protocol including the signal management, frame transfer, schedule table handling, task behaviour, status management, and commander and responder node. It contains also OSI layer 5 properties according to ISO 14229-7 UDSonLIN-based node configuration and identification services (SID: B016 to B816) belonging to the core protocol specification. A node (normally a commander node) that is connected to more than one LIN network is handled by higher layers (i.e. the application) not within the scope of this document.

This document specifies the requirements for secured and unsecured diagnostic communication between a client DoIP entity and server(s) installed in the vehicle using Internet protocol (IP) as well as the transmission control protocol (TCP) and user datagram protocol (UDP). This includes the definition of vehicle gateway requirements (e.g. for integration into an existing computer network) and test equipment (client DoIP entity) requirements (e.g. to detect and establish communication with a vehicle). This document specifies features that are used to detect a vehicle in a network and enable communication with the vehicle gateway as well as with its subcomponents during the various vehicle states. These features are separated into two types: mandatory and optional. This document specifies the following mandatory features: — vehicle network integration (IP address assignment); — vehicle announcement and vehicle discovery; — vehicle basic status information retrieval (e.g. diagnostic power mode); — connection establishment (e.g. concurrent communication attempts), connection maintenance and vehicle gateway control; — data routing to and from the vehicle's sub-components; — error handling (e.g. physical network disconnects). This document specifies the following optional features: — DoIP entity status monitoring; — transport layer security (TLS); — DoIP entity firewall capabilities.

This document specifies a transport protocol and network layer services tailored to meet the requirements of LIN‑based vehicle network systems on local interconnect networks. The protocol specifies an unconfirmed communication. The LIN protocol supports the standardized service primitive interface as specified in ISO 14229-2. This document provides the transport protocol and network layer services to support different application layer implementations such as: — normal communication messages, and — diagnostic communication messages. The transport layer defines transportation of data that is contained in one or more frames. The transport layer messages are transported by diagnostic frames. A standardized API is specified for the transport layer. Use of the transport layer is targeting systems where diagnostics are performed on the backbone bus (e.g. CAN) and where the system builder wants to use the same diagnostic capabilities on the LIN sub-bus clusters. The messages are in fact identical to ones in ISO 15765-2 and the PDUs carrying the messages are very similar. The goals of the transport layer are: — to have low load on commander node, — to provide full (or a subset thereof) diagnostics directly on the responder nodes, and — to target clusters built with powerful LIN nodes (not the mainstream low cost).

This document specifies the 12 V and 24 V electrical physical layers (EPL) of the LIN communications system. The electrical physical layer for LIN is designed for low-cost networks with bit rates up to 20 kbit/s to connect automotive electronic control units (ECUs). The medium that is used is a single wire for each receiver and transmitter with reference to ground. Annex A provides recommendations on the LIN physical layer peripheral interface design of type UART and frame controller for commander and responder nodes. This document includes the definition of electrical characteristics of the transmission itself and also the documentation of basic functionality for bus driver devices. This document also provides the physical layer definitions for nodes with LIN AA capabilities according to one of the procedures C, D and E. All parameters in this document are defined for the ambient temperature range from −40 °C to 125 °C.

This document specifies the conformance test for the electrical physical layer (EPL) of the LIN communications system. The purpose of this document is to provide a standardised way to verify whether a LIN bus driver conforms to ISO 17987-4. The primary motivation is to ensure a level of interoperability of LIN bus drivers from different sources in a system environment. This document provides all the necessary technical information to ensure that test results are consistent even on different test systems, provided that the particular test suite and the test system are conformant to the content of this document.

This document gives an overview of the structure and the partitioning of the ISO 17987 series. In addition, it outlines the use cases where the ISO 17987 series is used. The terminology defined in this document is common for all LIN communication systems and is used throughout the ISO 17987 series. This document has been established to define the use cases for LIN.

This document specifies the LIN protocol conformance test. This test verifies the conformance of LIN communication controllers with respect to ISO 17987-2 and ISO 17987-3. This document provides all necessary technical information to ensure that test results are identical even on different test systems, provided that the particular test suite and the test system are compliant to the content of this document. Annex A, Annex B and Annex C specify the protocol conformance test plans for responder nodes supporting auto addressing procedures according procedure C, procedure D or procedure E, see ISO 17987-3:2025, Annex C.

This document defines the Open Test sequence eXchange (OTX) additional extension requirements and data model specifications. The requirements are derived from the use cases described in ISO 13209-1. They are listed in Clause 4. The data model specification aims at an exhaustive definition of all features of the OTX extensions which have been implemented to satisfy the requirements. This document establishes rules for the syntactical entities of each extension. Each of these syntactical entities is accompanied by semantic rules which determine how OTX documents containing extension features are interpreted. The syntax rules are provided by UML[2] class diagrams and XML schemas, whereas the semantics are given by UML activity diagrams and prose definitions.

This document specifies the controller area network (CAN) data link layer (DLL) and the physical coding sub-layer (PCS). The CAN DLL features data fields of up to 2048 byte when the CAN extended data field length (XL) frame format is used. This document divides the CAN DLL into the logical link control (LLC) and the medium access control (MAC) sub-layers. The DLL’s service data unit (SDU), which interfaces the LLC and the MAC, is implemented by means of the LLC frame. The LLC frame also features the service data unit type (SDT) and the virtual CAN channel identifier (VCID), which provide higher-layer protocol configuration and identification information. How the higher-layer functions are handled is not specified in this document. There are five implementation options: 1) support of the CAN classic frame format only, not tolerating the CAN flexible data rate (FD) frame format; 2) support of the CAN classic frame format and tolerating the CAN FD frame format; 3) support of the CAN classic frame format and the CAN FD frame format; 4) support of the CAN classic frame format, the CAN FD frame format and the CAN XL frame format; 5) support of the CAN FD frame format for CAN FD light responders (Annex A). NOTE Nodes of the first option can communicate with nodes of the third and fourth option when only the CAN classic frame format is used. Nodes of the first option cannot communicate with nodes of the fifth option: any attempt at communication generates error frames. Therefore, new designs implementing the fourth option can communicate with all other nodes.

This document specifies a transport and network layer protocol with transport and network layer services tailored to meet the requirements of CAN-based vehicle network systems on controller area networks as specified in ISO 11898-1. The diagnostic communication over controller area network (DoCAN) protocol supports the standardized abstract service primitive interface as specified in ISO 14229-2 (UDS). This document supports different application layer protocols such as: — enhanced vehicle diagnostics (emissions-related system diagnostics beyond legislated functionality, non-emissions-related system diagnostics); — emissions-related on-board diagnostics (OBD) as specified in the ISO 15031 series and SAE J1979 series; — world-wide harmonized on-board diagnostics (WWH-OBD) as specified in the ISO 27145 series; and — end of life activation of on-board pyrotechnic devices (the ISO 26021 series). The transport protocol specifies an unconfirmed communication. NOTE This document does not determine whether CAN CC, CAN FD or both are recommended or required to be implemented by other standards referencing this document.

This document specifies physical medium attachment (PMA) sublayers for the controller area network (CAN). This includes the high-speed (HS) PMA without and with low-power mode capability, without and with selective wake-up functionality. Additionally, this document specifies PMAs supporting the signal improvement capability (SIC) mode and the FAST mode in Annex A. The physical medium dependent (PMD) sublayer is not in the scope of this document.

This document specifies the OSI layers 4 to 1 (transport layer, network layer, data link layer and physical layer) requirements related to the connection between the external test equipment externally connected to the diagnostic link connector and the in-vehicle CAN network to successfully establish and maintain communication utilizing the communication parameters (communication profile) specified in (application-type) standards referencing this document. The SIC (signal improvement capability) transceiver options, as specified in ISO 11898-2, are out of scope in this document.

This document is applicable to road vehicles with automated driving functions. The document specifies the logical interface between in-vehicle environmental perception sensors (for example, radar, lidar, camera, ultrasonic) and the fusion unit which generates a surround model and interprets the scene around the vehicle based on the sensor data. The interface is described in a modular and semantic representation and provides information on object level (for example, potentially moving objects, road objects, static objects) as well as information on feature and detection levels based on sensor technology specific information. Further supportive information is available. This document does not provide electrical and mechanical interface specifications. Raw data interfaces are also excluded.

This document defines the requirements for the external test equipment as: — a means of establishing communications between a WWH-OBD-equipped vehicle and external test equipment; — a set of diagnostic services, including addressing methods, to be provided by the external test equipment in order to exercise the services defined in ISO 27145‑3. This document describes the minimum capabilities or functions in the external test equipment. Additional functionalities, for example, non WWH-OBD protocols or retrieval of repair and maintenance information, can be integrated into the external test equipment according to the test equipment manufacturer needs. The external test equipment designer ensures that no such capability or function can adversely affect either a WWH-OBD-equipped vehicle connected to the equipment, or the equipment itself. When the external test equipment implements functionality, which is not covered by ISO 27145‑3, this functionality is not linked to the timing requirements defined in this document.

This document specifies diagnostic application requirements and OSI-layer related communication profiles to ensure the interchange of digital information between towing and towed vehicles with a maximum authorized total mass greater than 3 500 kg. The conformance and interoperability test plans are not part of this document.

This document specifies the SAE J1939-based application layer, the payload of messages, and parameter groups for electronically controlled braking systems, including anti-lock braking systems (ABS), vehicle dynamics control systems (VDC), and running gears equipment, to ensure the interchange of digital information between road vehicles with a maximum authorized total mass greater than 3 500 kg and their towed vehicles, including communication between towed vehicles. Conformance and interoperability test plans are not part of this document.

This document references the latest publication of SAE J1962. On-board diagnostic (OBD) regulations require road vehicles to be equipped with a standardized connector for purposes of access to OBD information by external test equipment. This document describes the requirements for the physical connection and associated pin usage to allow for standard access to the OBD data. This document is technically equivalent to SAE J1962 with the exception of the specific requirements identified and the specification of additional requirements related to right hand driven (RHD) vehicles.

This document specifies conformance tests in the form of an abstract test suite (ATS) for a system under test (SUT) implementing an electric-vehicle or supply-equipment communication controller (EVCC or SECC) with support for WLAN-based high-level communication (HLC) according to ISO 15118‑8 and against the background of ISO 15118-1. These conformance tests specify the testing of capabilities and behaviours of an SUT, as well as checking what is observed against the conformance requirements specified in ISO 15118‑8 and against what the implementer states the SUT implementation's capabilities are. The capability tests within the ATS check that the observable capabilities of the SUT are in accordance with the static conformance requirements defined in ISO 15118‑8. The behaviour tests of the ATS examine an implementation as thoroughly as practical over the full range of dynamic conformance requirements defined in ISO 15118‑8 and within the capabilities of the SUT (see NOTE below). A test architecture is described in correspondence to the ATS. The abstract test cases in this document are described leveraging this test architecture and are specified in descriptive tabular format for the ISO/OSI physical and data link layers (layers 1 and 2). In terms of coverage, this document only covers normative sections and requirements in ISO 15118‑8. This document can additionally refer to specific tests for requirements on referenced standards (e.g. IEEE, or industry consortia standards, like WiFi Alliance) as long as they are relevant in terms of conformance for implementations according to ISO 15118‑8. However, it is explicitly not intended to widen the scope of this conformance specification to such external standards, if it is not technically necessary for the purpose of conformance testing for ISO 15118‑8. Furthermore, the conformance tests specified in this document do not include the assessment of performance nor robustness or reliability of an implementation. They cannot provide judgments on the physical realization of abstract service primitives, how a system is implemented, how it provides any requested service, nor the environment of the protocol implementation. Furthermore, the abstract test cases defined in this document only consider the communication protocol and the system's behaviour defined ISO 15118‑8. The power flow between the EVSE and the EV is not considered. NOTE Practical limitations make it impossible to define an exhaustive test suite, and economic considerations can restrict testing even further. Hence, the purpose of this document is to increase the probability that different implementations are able to interwork. This is achieved by verifying them by means of a protocol test suite, thereby increasing the confidence that each implementation conforms to the protocol specification. However, the specified protocol test suite cannot guarantee conformance to the specification since it detects errors rather than their absence. Thus, conformance to a test suite alone cannot guarantee interworking. Instead, it gives confidence that an implementation has the required capabilities and that its behaviour conforms consistently in representative instances of communication.

This document specifies the conformance test plan for the communication requirements stated in ISO 20730-1 of road vehicles' ePTI-relevant systems and associated measurement and control data as specified in ISO 20730-3, which are subject to the usage of the electronic vehicle interface during the periodic technical inspection (ePTI). The conformance test plan specifies test requirements and expected response behaviour of the system under test (SUT) to verify conformance of a vehicle with respect to ISO 20730-1 and ISO 20730‑3 requirements. This document provides technical information that test results are identical even on different test systems, if the particular test suite and the test system are compliant to the content of this document.

This document defines the OTX core requirements and data model specifications. The requirements are derived from the use cases described in ISO 13209-1. They are listed in the requirements section. The data model specification aims at an exhaustive definition of all OTX core features implemented to satisfy the core requirements. Since OTX is designed for describing test sequences, which themselves represent a kind of program, the core data model follows the basic concepts common to most programming languages. Thus, this document establishes rules for syntactical entities like parameterised procedures, constant and variable declarations, data types, basic arithmetic, logic and string operations, flow control statements like loop, branch or return, simple statements like assignment or procedure call as well as exception handling mechanisms. Each of these syntactical entities is accompanied by semantic rules which determine how OTX documents are interpreted. The syntax rules are provided by UML class diagrams and XML schemas, whereas the semantics are given by UML activity diagrams and prose definitions. With respect to documentation use cases, special attention is paid to defining a specification/realisation concept (which allows for “hybrid” test sequences: human readable test sequences that are at the same time machine-readable) and so-called floating comments (which can refer to more than one node of the sequence). The core data model does not define any statements, expressions or data types that are dependent on a specific area of application. For the convenience of the user, the ISO 13209-2 OTX XML schema definition file (XSD) is published alongside this document.

This document defines the Open Test sequence eXchange (OTX) extension requirements and data model specifications. The requirements are derived from the use cases described in ISO 13209-1. They are listed in Clause 4. The data model specification aims at an exhaustive definition of all features of the OTX extensions which have been implemented to satisfy the requirements. This document establishes rules for the syntactical entities of each extension. Each of these syntactical entities is accompanied by semantic rules which determine how OTX documents containing extension features are to be interpreted. The syntax rules are provided by UML class diagrams and XML schemas, whereas the semantics are given by UML activity diagrams and prose definitions.

This document specifies the diagnostic protocol data unit application programming interface (D‑PDU API) as a modular vehicle communication interface (MVCI) protocol module software interface and common basis for diagnostic and reprogramming software applications. This document covers the descriptions of the application programming interface (API) functions and the abstraction of diagnostic protocols, as well as the handling and description of MVCI protocol module features. Sample MVCI module description files accompany this document. The purpose of this document is to ensure that diagnostic and reprogramming applications from any vehicle or tool manufacturer can operate on a common software interface and can easily exchange MVCI protocol module implementations.

This document specifies all end-of-life activation of in-vehicle pyrotechnical devices identifiers, data identifiers, routine identifiers, data types, computations, and units. This document is based on: — new safety-relevant system technology designed into the vehicles, — new or more effective end-of-life activation of in-vehicle pyrotechnical devices, which requires additional test data, and routine controls. This document describes the end-of-life activation of in-vehicle pyrotechnical devices data definitions and associated technical requirements. This document specifies: — identifiers for end-of-life activation of in-vehicle pyrotechnical devices data definitions and associated technical requirements, — data identifiers applicable to end-of-life activation of in-vehicle pyrotechnical devices data definitions and associated technical requirements, — routine identifiers applicable to end-of-life activation of in-vehicle pyrotechnical devices data definitions and associated technical requirements.

This document specifies the communication interface between motion sensor and recording equipment. This includes the mechanical, electrical and logical requirements.

This document specifies the parameters used on the service interface of the recording equipment. Some of them are specified in detail in this document, while others are given in the ISO 14299 series.

This document specifies the CAN-based and the K-Line communication between the recording equipment and service tools for software download and calibrating purposes. The provided requirements and recommendations cover physical, data link, network, session, and application layers according to the OSI reference model as well as the unified diagnostics services.

This document specifies the communication between the electric vehicle (EV), including battery electric vehicle (BEV) and plug-in hybrid electric vehicle (PHEV), and the electric vehicle supply equipment (EVSE). The application layer messages defined in this document are designed to support the electricity power transfer between an EV and an EVSE. This document defines the communication messages and sequence requirements for bidirectional power transfer. This document furthermore defines requirements of wireless communication for both conductive charging and wireless charging as well as communication requirements for automatic connection device and information services about charging and control status. The purpose of this document is to detail the communication between an electric vehicle communication controller (EVCC) and a supply equipment communication controller (SECC). Aspects are specified to detect a vehicle in a communication network and enable an Internet Protocol (IP) based communication between the EVCC and the SECC.

This document specifies an application profile for the implementation of unified diagnostic services (UDS) Internet Protocol (IP) in road vehicles (UDSonIP). UDSonIP references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of the diagnostic services to be used for diagnostic communication on Internet Protocol. This document includes — additional requirements specific to the implementation of UDS on the Ethernet network, and — specific restrictions in the implementation of UDS on the Ethernet network.

This document specifies an application profile for the implementation of unified diagnostic services (UDS) local interconnect network (LIN) in road vehicles (UDSonLIN). UDSonLIN references ISO 14229‑1 and ISO 14229‑2 and specifies implementation requirements of the diagnostic services to be used for diagnostic communication on Local Interconnect Network. This document includes: — additional requirements specific to the implementation of UDS on local interconnect network; and — specific restrictions in the implementation of UDS on local interconnect network.

This document specifies the electrical interfaces of the data and the service interfaces. The electrical interfaces to the CAN-based in-vehicle networks are not in the scope of this document.

This document specifies an application profile for the implementation of unified diagnostic services (UDS) on controller area network (CAN) in road vehicles. UDSonCAN references ISO 14229-1 and ISO 14229-2 and specifies implementation requirements of the diagnostic services to be used for diagnostic communication on CAN. This document specifies — additional requirements specific to the implementation of UDS on the CAN network, and; — specific restrictions in the implementation of UDS on the CAN network.

This document specifies the mechanical dimensions of mandatory connectors and optional connectors used by the recording equipment for the data and the service interfaces. This includes, in particular, the connection to the CAN-based in-vehicle networks.

This document specifies the CAN-based data communication between the display unit and other devices connected to an SAE J1939-based in-vehicle network. The provided requirements and recommendations cover physical, data link, network, and application layers according to the OSI reference model. Additionally, it specifies the parameter groups, which are supported.

This document is applicable to road vehicles, where the electronic vehicle interface of the diagnostic link connector (DLC) is used to perform an end-of-life (EoL) activation of in-vehicle pyrotechnic devices. Apart from actual removal, this is the method to assure that no pyrotechnic substances are left in an EoL vehicle. On-board activation is an effective and safe method. This document describes use cases and specifies technical requirements in order to support the end-of-life activation of in-vehicle pyrotechnic devices via the electronic communication interface. This document references the ISO 14229 series unified diagnostic services implemented on diagnostic communication over controller area network (DoCAN) and Internet Protocol (DoIP) along with the required provision of data definitions. This document comprises: — terminology definitions; — definition of end-of-life activation of in-vehicle pyrotechnic devices relevant use cases; — requirements for the establishment of communication between the pyrotechnic device deployment tool (PDT) and the vehicle's pyrotechnic control unit(s) (PCU(s)); — requirements for the optional usage of a credentials-based authentication and authorisation mechanism between the PDT and the vehicle; — requirements for the protection against tampering of the defined end-of-life activation of in-vehicle pyrotechnic devices; — PCU-relevant technical requirements. PDT-relevant requirements are specified in a test equipment-specific standard with PDT-specific requirements.

This document specifies in-vehicle Ethernet application layer, presentation layer, and session layer conformance test plans (CTP) for electronic control units (ECUs). This document is a collection of all conformance test cases which are recommended to be considered for automotive use and should be referred by car manufacturers within their quality control processes. The document specifies the scalable Service-Oriented MiddlewarE over Internet Protocol (SOME/IP) and Dynamic Host Configuration Protocol (DHCP) version 4 conformance test cases.

This document defines how to authenticate users and accessing parties on a web-services interface. It also defines how a resource owner can delegate access to its resources to an accessing party. Within this context, this document also defines the necessary roles and required separation of duties between these in order to fulfil requirements stated on security, data privacy and data protection. All conditions and dependencies of the roles are defined towards a reference implementation using OAuth 2.0 compatible framework and OpenID Connect 1.0 compatible framework.

This document defines how to access resources on a web-services interface of an offering party using the Hypertext Transfer Protocol Secure (HTTPS). Resources can be accessed through request/reply and/or requested to be pushed. The Representational State Transfer (REST) architectural pattern is chosen as a common way to format resource paths both for request/reply and push. Some specific extensions to this pattern are defined to allow for asynchronous resource requests, such as, for example, forcing readouts of data from a connected vehicle.

This document states the minimum requirements, recommendations, permissions and possibilities for ensuring interoperable web services from an accessing party’s perspective. The document: — states requirements on the structure and format of resources; — defines the concept of resource identifiers (direct and correlated); — provides different resource categories (e.g. anonymous, pseudonymized, technical, and personal resources); — provides different approaches on how to bundle shareable resources (e.g. resource group or container); — contains guidelines on how to define the unique resources of an individual application; — defines the entities and roles, necessary for granting an accessing party access to resource owner’s resources; — states requirements on how an accessing party accesses resources, including requirements on how to use the defined and referenced technologies, see Table 1. See Annex A for additional information about roles and responsibilities covered by ISO 20078 series.

This document specifies advanced features of an ISO/IEC/IEEE 8802-3 automotive Ethernet PHY (often also called transceiver), e.g. for diagnostic purposes for automotive Ethernet PHYs. This document specifies: — advanced PHY features; — wake-up and sleep features; — PHY test suite; — PHY control IUT requirements and conformance test plan; — PCS test suite; — PCS IUT requirements and conformance test plan; — PMA test suite; and — PMA IUT requirements and conformance test plan.

This document specifies in-vehicle Ethernet transport layer and network layer conformance test plans (CTP) for electronic control units (ECUs). This document is a collection of all conformance test cases which are recommended to be considered for automotive use and should be referred by car manufacturers within their quality control processes. The document includes conformance test plans for the address resolution protocol, Internet control message protocol version 4, Internet protocol version 4, Internet protocol version 4 auto configuration, user datagram protocol, transport control protocol, and dynamic host configuration protocol version 4.

This document specifies common session layer services and requirements to provide independence between unified diagnostic services (ISO 14229-1) and all transport protocols and network layer services (e.g. ISO 13400-2 DoIP, ISO 15765-2 DoCAN, ISO 10681-2 communication on FlexRay, ISO 14230-2 DoK-Line, and ISO 20794-3 CXPI). This document specifies a common service primitive interface between OSI layer 5 (session) and layer 4 (transport) via so-called service request/indication/confirmation primitives.

This document specifies ePTI-relevant system identifiers, data identifiers, routine identifiers, input/output control identifiers, data types, CompuMethods (computations), and units. This document describes ePTI systems' data definitions and associated technical requirements. The technical requirements of data definitions of emissions-related systems are specified in other standards, e.g. the ISO 15031 series[4], the ISO 27145 series[5], and SAE J1979DA. The ePTI system list defined in this document summarizes ePTI-relevant systems and specifies a defined name (system), a unique identifier (ePTI system identifier) and a description for each ePTI-relevant system. This document does not specify any type of test method or pass/fail criteria of the ePTI-relevant system during a PTI.

This document describes the processes of an offering party’s implementation to provide (ISO 20078‑2) access-controlled (ISO 20078-3) resources (ISO 20078‑1) to accessing parties. The processes are summarized as: registration of different stakeholder as well as granting, denying and revoking of access to resources. Those processes are held as examples of combining ISO 20078‑1, ISO 20078‑2 and ISO 20078‑3 and can vary depending on the actual implementation of the offering party.

This document specifies requirements for CAN-based communication systems between the in-vehicle network and the diagnostic link connector of the vehicle. This document does not specify any requirements related to the in-vehicle CAN network architecture. This document specifies the requirements to enable the in-vehicle CAN-based communication systems to establish, maintain, and terminate communication with the devices connected to the diagnostic link connector.