INTERNATIONAL STANDARD ISO 14229-1 Second edition 2013-03-15 Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements Véhicules routiers — Services de diagnostic unifiés (SDU) — Partie 1: Spécification et exigences ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - Reference number ISO 14229-1:2013(E) Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) COPYRIGHT PROTECTED DOCUMENT © ISO 2013 All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior written permission Permission can be requested from either ISO at the address below or ISO’s member body in the country of the requester ISO copyright office Case postale 56 • CH-1211 Geneva 20 Tel + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyright@iso.org Web www.iso.org Published in Switzerland ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - ii Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Contents Page Foreword vi Introduction .vii Scope Normative references 3.1 3.2 Terms, definitions, symbols and abbreviated terms Terms and definitions Abbreviated terms 4 Conventions 5 Document overview .6 6.1 6.2 6.3 6.4 Application layer services General Format description of application layer services Format description of service primitives Service data unit specification 12 7.1 7.2 7.3 7.4 7.5 Application layer protocol 15 General definition 15 Protocol data unit specification .16 Application protocol control information 16 Negative response/confirmation service primitive 18 Server response implementation rules .18 8.1 8.2 8.3 8.4 8.5 Service description conventions .29 Service description .29 Request message 30 Positive response message .33 Supported negative response codes (NRC_) 34 Message flow examples 34 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 Diagnostic and Communication Management functional unit .35 Overview .35 DiagnosticSessionControl (0x10) service .36 ECUReset (0x11) service 43 SecurityAccess (0x27) service 47 CommunicationControl (0x28) service 53 TesterPresent (0x3E) service .58 AccessTimingParameter (0x83) service 61 SecuredDataTransmission (0x84) service 66 ControlDTCSetting (0x85) service .71 ResponseOnEvent (0x86) service 75 LinkControl (0x87) service 99 10 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 Data Transmission functional unit 106 Overview 106 ReadDataByIdentifier (0x22) service .106 ReadMemoryByAddress (0x23) service 113 ReadScalingDataByIdentifier (0x24) service 119 ReadDataByPeriodicIdentifier (0x2A) service 126 DynamicallyDefineDataIdentifier (0x2C) service 140 WriteDataByIdentifier (0x2E) service .162 WriteMemoryByAddress (0x3D) service 167 ``,`,,,,,,`,,,`,``,,` 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS iii reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) 11 11.1 11.2 11.3 Stored Data Transmission functional unit 174 Overview .174 ClearDiagnosticInformation (0x14) Service 175 ReadDTCInformation (0x19) Service 178 12 12.1 12.2 InputOutput Control functional unit .245 Overview .245 InputOutputControlByIdentifier (0x2F) service 245 13 13.1 13.2 Routine functional unit 259 Overview .259 RoutineControl (0x31) service 260 14 14.1 14.2 14.3 14.4 14.5 14.6 Upload Download functional unit 270 Overview .270 RequestDownload (0x34) service 270 RequestUpload (0x35) service 275 TransferData (0x36) service 280 RequestTransferExit (0x37) service .285 RequestFileTransfer (0x38) service 295 15 15.1 15.2 15.3 15.4 Non-volatile server memory programming process 303 General information 303 Detailed programming sequence .307 Server reprogramming requirements 315 Non-volatile server memory programming message flow examples 319 Annex A (normative) Global parameter definitions .325 A.1 Negative response codes 325 Annex C (normative) Data transmission functional unit data-parameter definitions 337 C.1 DID parameter definitions 337 C.2 scalingByte parameter definitions 343 C.3 scalingByteExtension parameter definitions 345 C.4 transmissionMode parameter definitions .351 C.5 Coding of UDS version number .352 Annex D (normative) Stored data transmission functional unit data-parameter definitions 353 D.1 groupOfDTC parameter definition 353 D.2 DTCStatusMask and statusOfDTC bit definitions 353 D.3 DTC severity and class definition 366 D.4 DTCFormatIdentifier definition .369 D.5 FunctionalGroupIdentifier definition .369 D.6 DTCFaultDetectionCounter operation implementation example 371 D.7 DTCAgingCounter example 372 Annex E (normative) Input output control functional unit data-parameter definitions 374 E.1 InputOutputControlParameter definitions 374 Annex F (normative) Routine functional unit data-parameter definitions .375 F.1 RoutineIdentifier (RID) definition .375 Annex G (normative) Upload and download functional unit data-parameter 376 G.1 Definition of modeOfOperation values 376 Annex H (informative) Examples for addressAndLengthFormatIdentifier parameter values 377 H.1 addressAndLengthFormatIdentifier example values 377 Annex I (normative) Security access state chart 379 iv Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - Annex B (normative) Diagnostic and communication management functional unit data-parameter definitions 333 B.1 communicationType parameter definition 333 B.2 eventWindowTime parameter definition 334 B.3 linkControlModeIdentifier parameter definition .334 B.4 nodeIdentificationNumber parameter definition 335 ISO 14229-1:2013(E) I.1 I.2 General .379 Disjunctive normal form based state transition definitions 379 Annex J (informative) Recommended implementation for multiple client environments .385 J.1 Introduction 385 J.2 Implementation specific limitations 385 J.3 Use cases relevant for system design 386 J.4 Use Case Evaluation: 388 J.5 Multiple client server level implementation 389 Bibliography 391 ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS v reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies) The work of preparing International Standards is normally carried out through ISO technical committees Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part The main task of technical committees is to prepare International Standards Draft International Standards adopted by the technical committees are circulated to the member bodies for voting Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights ISO shall not be held responsible for identifying any or all such patent rights ISO 14229-1 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment This second edition cancels and replaces the first edition (ISO 14229-1:2006), which has been technically revised ISO 14229 consists of the following parts, under the general title Road vehicles — Unified diagnostic services (UDS): ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - ⎯ Part 1: Specification and requirements ⎯ Part 2: Session layer services ⎯ Part 3: Unified diagnostic services on CAN implementation (UDSonCAN) ⎯ Part 4: Unified diagnostic services on FlexRay implementation (UDSonFR) ⎯ Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP) ⎯ Part 6: Unified diagnostic services on K-Line implementation (UDSonK-Line) The following part is under preparation: ⎯ Part 7: Unified diagnostic services on Local Interconnect Network implementation (UDSonLIN) The titles of future parts will be drafted as follows: ⎯ vi Part n: Unified diagnostic services on … implementation (UDSon…) Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Introduction ISO 14229 has been established in order to define common requirements for diagnostic systems, whatever the serial data link is To achieve this, ISO 14229 is based on the Open Systems Interconnection (OSI) Basic Reference Model in accordance with ISO 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers When mapped on this model, the services used by a diagnostic tester (client) and an Electronic Control Unit (ECU, server) are broken into the following layers in accordance with Table 1: ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - ⎯ Application layer (layer 7), unified diagnostic services specified in ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, further standards and ISO 27145-3 WWH-OBD ⎯ Presentation layer (layer 6), vehicle manufacturer specific, ISO°27145-2 WWH-OBD ⎯ Session layer services (layer 5) specified in ISO 14229-2 ⎯ Transport layer services (layer 4), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 27145-4 WWH-OBD ⎯ Network layer services (layer 3), specified in ISO 15765-2 DoCAN, ISO 10681-2 Communication on FlexRay, ISO 13400-2 DoIP, ISO 17987-2 LIN, ISO 27145-4 WWH-OBD ⎯ Data link layer (layer 2), specified in ISO 11898-1, ISO 11898-2, ISO 17458-2, ISO 13400-3, IEEE 802.3, ISO 14230-2, ISO 17987-3 LIN and further standards, ISO 27145-4 WWH-OBD ⎯ Physical layer (layer 1), specified in ISO 11898-1, ISO 11898-2, ISO 17458-4, ISO 13400-3, IEEE 802.3, ISO 14230-1, ISO 17987-4 LIN and further standards, ISO 27145-4 WWH-OBD NOTE The diagnostic services in this standard are implemented in various applications e.g Road vehicles – Tachograph systems, Road vehicles – Interchange of digital information on electrical connections between towing and towed vehicles, Road vehicles – Diagnostic systems, etc It is required that future modifications to this standard provide long-term backward compatibility with the implementation standards as described above Table — Example of diagnostic/programming specifications applicable to the OSI layers OSI seven layer Applicability Application (layer 7) Enhanced diagnostics services WWHOBD ISO 14229-1, ISO 14229-3 UDSonCAN, ISO 14229-4 UDSonFR, ISO 14229-5 UDSonIP, ISO 14229-6 UDSonK-Line, ISO 14229-7 UDSonLIN, further standards ISO 27145-3 vehicle manufacturer specific ISO 27145-2 Presentation (layer 6) Seven layer according to ISO/IEC 7498-1 and ISO/IEC 10731 Session (layer 5) Transport (layer 4) Network (layer 3) Data link (layer 2) Physical (layer 1) 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS ISO 14229-2 ISO 15765-2 ISO 10681-2 ISO 11898-1, ISO 11898-2 ISO 17458-2 ISO 17458-4 further standards ISO 13400-2 Not applicable ISO 17987-2 ISO 13400-3, IEEE 802.3 ISO 14230-2 ISO 17987-3 further standards ISO 14230-1 ISO 17987-4 further standards further standards ISO 27145-4 vii reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST INTERNATIONAL STANDARD ISO 14229-1:2013(E) Road vehicles — Unified diagnostic services (UDS) — Part 1: Specifications and requirements Scope This part of ISO 14229 specifies data link independent requirements of diagnostic services, which allow a diagnostic tester (client) to control diagnostic functions in an on-vehicle Electronic Control Unit (ECU, server) such as an electronic fuel injection, automatic gear box, anti-lock braking system, etc connected to a serial data link embedded in a road vehicle It specifies generic services, which allow the diagnostic tester (client) to stop or to resume non-diagnostic message transmission on the data link This part of ISO 14229 does not apply to non-diagnostic message transmission on the vehicle's communication data link between two Electronic Control Units However, this part of ISO 14229 does not restrict an in-vehicle on-board tester (client) implementation in an ECU in order to utilize the diagnostic services on the vehicle's communication data link to perform bidirectional diagnostic data exchange This part of ISO 14229 does not specify any implementation requirements Normative references The following referenced documents are indispensable for the application of this document For dated references, only the edition cited applies For undated references, the latest edition of the referenced document (including any amendments) applies ISO 14229-2, Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services 3.1 Terms, definitions, symbols and abbreviated terms Terms and definitions For the purposes of this document, the following terms and definitions apply 3.1.1 boot manager part of the boot software that executes immediately after an ECU power on or reset whose primary purpose is to check whether a valid application is available to execute as compared to transferring control to the reprogramming software ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - NOTE software The boot manager may also take into account other conditions for transitioning control to the reprogramming 3.1.2 boot memory partition area of the server memory in which the boot software is located 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) 3.1.3 boot software software which is executed in a special part of server memory which is used primarily to boot the ECU and perform server programming NOTE This area of memory is not erased during a normal programming sequence and must execute when the server application is missing or otherwise deemed invalid to always ensure the capability to reprogram the server NOTE See also 3.1.1 and 3.1.17 3.1.4 client function that is part of the tester and that makes use of the diagnostic services NOTE A tester normally makes use of other functions such as data base management, specific interpretation, human-machine interface 3.1.5 diagnostic data data that is located in the memory of an electronic control unit which may be inspected and/or possibly modified by the tester NOTE Diagnostic data includes analogue inputs and outputs, digital inputs and outputs, intermediate values and various status information NOTE Examples of diagnostic data are vehicle speed, throttle angle, mirror position, system status, etc Three types of values are defined for diagnostic data: ⎯ the current value: the value currently used by (or resulting from) the normal operation of the electronic control unit; ⎯ a stored value: an internal copy of the current value made at specific moments (e.g when a malfunction occurs or periodically); this copy is made under the control of the electronic control unit; ⎯ a static value: e.g VIN The server is not obliged to keep internal copies of its data for diagnostic purposes, in which case the tester may only request the current value NOTE Defining a repair shop or development testing session selects different server functionality (e.g access to all memory locations may only be allowed in the development testing session) 3.1.6 diagnostic routine routine that is embedded in an electronic control unit and that may be started by a server upon a request from the client NOTE It could either run instead of a normal operating program, or could be enabled in this mode and executed with the normal operating program In the first case, normal operation for the server is not possible In the second case, multiple diagnostic routines may be enabled that run while all other parts of the electronic control unit are functioning normally 3.1.7 diagnostic service information exchange initiated by a client in order to require diagnostic information from a server or/and to modify its behaviour for diagnostic purpose 3.1.8 diagnostic session state within the server in which a specific set of diagnostic services and functionality is enabled ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) The state chart takes into account that the general session handling is done at the proper place within the session management layer (see ISO 14229-2) and therefore does not need to be considered in the statechart The state transition definitions make use of some parameters that can be set according to vehicle manufacturer specific requirements The support of Delay_Timer and Att_Cnt parameters is optional and decided by the vehicle manufacturer In general, for longer seed/key lengths (e.g., 16 bytes and beyond) the support of these parameters is no longer as important Table I.1 defines the state transitions – parameters Table I.1 — State transitions – parameters Name Description Delay_Timer If supported, this value represents the required minimum time between security access attempts In addition, it is vehicle manufacturer specific whether this delay timer will be invoked upon every power on / start up The standard use case will have a fixed value for the delay time, but it is also possible for a customer-specific use case to have a variable value (e.g., the value depends on the number of false access attempts in case they are stored in non-volatile memory) NOTE A server may choose to implement a separate timer for each security level or utilize a single timer for all levels Att_Cnt If supported, this value represents the number of false security access attempts before a delay time (Start_Delay) is inserted When implemented, the counter is required for each individual security level Static_Seed This represents a boolean value where true indicates that a seed is stored and re-used in a positive response to a seed request under certain conditions according to Table I.2 A value of false indicates that a random seed is used every time a new seed request is received If Delay_Timer and Att_Cnt are not supported, a random seed shall always be used xx This represents the last requestSeed securityAccessType received by the server yy This represents the current sendKey securityAccessType received by the server Legend: ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 380 AND, OR Italic “==” "=" “” “” “+” “-” "++" logical operation optional, customer specific equal (comparison operator) assignment operator un-equal less than greater than mathematical addition mathematical subtraction increment operator (variable++ is the same as variable = variable + 1) Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Table I.2 includes the complete set of state transition definitions Table I.2 — State transitions – disjunctive normal form representation No Operation Condition Action Start / restart of ECU Application (e.g., ECU reset, power cycle, key cycle, sleep Ỉ wake transition, etc.) Initialize Att_Cnt (if applicable) SecurityAccess requestSeed received If Static_Seed == True then generate and store Seed for the requested securityAccessType (if not previously generated and stored during the current ECU operating cycle) If Static_Seed = False, then generate new Seed Save sub-function: xx = securityAccess Type Transmit SecurityAccess positive response on requestSeed request with Seed as active for the requested securityAccessType Message length OKb Optional pre-conditions fulfilled AND Delay expired (if applicable) SecurityAccess sendKey received sub-function: yy == xx+1c AND Message length OK Key OK ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - AND SecurityAccess requestSeed received Message Length NOK SecurityAccess sendKey received Start Delay_Timera (if required on start up) Att_Cnt = for subfunction xx (if applicable) Store Att_Cnt in non-volatile memory (if applicable) Unlock security level for subfunction xx If Static_Seed = True then clear generated seed for subfunction xx Transmit SecurityAccess positive response on sendKey request Transmit negative response NRC 0x13 Transmit negative response NRC 0x24 SecurityAccess requestSeed received AND Message length OK Optional pre-conditions NOT Transmit negative response NRC 0x22 fulfilledd SecurityAccess requestSeed received OR AND Message length OK Delay NOT expired (if applicable) Transmit negative response NRC 0x37 Optional pre-conditions fulfilled AND SecurityAccess request results in a general negative response code (e.g., minimum length, sub-function supported) according to the general negative response handling (see section 7.5) Transmit negative response code as defined in section 7.5 SecurityAccess requestSeed received Generate new seed and transmit SecurityAccess positive response with the new seed for the requested securityAccessType Save sub-function: xx = securityAccess Type Static_Seed == False SecurityAccess requestSeed received AND Static_Seed == True requested securityAccessType has an active stored seed OR SecurityAccess requestSeed received Static_Seed == True AND 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS requested securityAccessType has no active seed stored (different securityAccessType than before) Transmit SecurityAccess positive response with the active stored seed for the requested securityAccessType Save sub-function: xx = securityAccess Type Generate and store Seed for the requested securityAccessType (if not previously generated and stored during the current ECU operating cycle) Save sub-function: xx = securityAccess Type Transmit SecurityAccess positive response on requestSeed request with Seed as active for the requested securityAccessType 381 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Table I.2 — (continued) No Operation AND Condition Action DiagnosticSessionControl accepted or session timeout occurs Start appropriate diagnostic session Lock ECU SecurityAccess sendKey received Transmit negative response NRC 0x24 SecurityAccess requestSeed received Transmit SecurityAccess positive response with zero seede Requested level is unlocked OR SecurityAccess request results in a general negative response code (e.g., minimum length, sub-function supported) according to the general negative response handling (see section 7.5) Transmit negative response code as defined in section 7.5 SecurityAccess requestSeed received Generate and store Seed for the requested securityAccessType (if not previously generated and stored during the current ECU operating cycle) Save sub-function: xx = securityAccess Type Requested level is NOT unlocked AND Message length OK Transmit SecurityAccess positive response on requestSeed request with Seed as active for the requested securityAccessType Optional pre-conditions fulfilled Delay expired (if applicable) SecurityAccess sendKey received sub-function: yy == xx+1 Att_Cnt++ for sub-function xx (if applicable)f Store Att_Cnt in non-volatile memory (if applicable) Key NOK Transmit negative response NRC 0x35 (Att_Cnt+1) applicable) < Att_Cnt_Limit (if SecurityAccess sendKey received sub-function: yy == xx+1 AND Message length OK Key NOK Att_Cnt++ for sub-function xx (if applicable) Start Delay_Timer for sub-function xx (if applicable) Store Att_Cnt in non-volatile memory (if applicable) Transmit negative response NRC 0x36 (Att_Cnt+1) >= Att_Cnt_Limit OR SecurityAccess sendKey received AND AND sub-function: yy xx+1 Transmit negative response NRC 0x24 Att_Cnt++ for sub-function xx (if applicable) Store Att_Cnt in non-volatile memory SecurityAccess sendKey received Transmit negative response NRC 0x13 sub-function: yy == xx+1 Att_Cnt++ for sub-function xx (if applicable) Store Att_Cnt in non-volatile memory Message length NOK AND DiagnosticSessionControl accepted or session timeout occurs SecurityAccess request results in a general negative response code (e.g., minimum length, sub-function supported) according to the general negative response handling (see section 7.5) 382 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Start appropriate diagnostic session Transmit negative response code as defined in section 7.5 © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - AND Message length OK ISO 14229-1:2013(E) Table I.2 — (continued) No Operation AND Condition Action SecurityAccess requestSeed received Transmit SecurityAccess positive response with zero seedg Requested level is unlocked SecurityAccess sendKey received sub-function: yy == AND Att_Cnt = for subfunction xx (if applicable) Store Att_Cnt in non-volatile memory (if applicable) xx+1h Lock currently unlocked security level Unlock security level for subfunction xx Message length OK Key OK If Static_Seed = True then clear generated seed for subfunction xx.Transmit SecurityAccess positive response on sendKey request SecurityAccess sendKey received sub-function: yy == xx+1 AND Att_Cnt++ for sub-function xx (if applicable)i Store Att_Cnt in non-volatile memory (if applicable) Message length OK Key NOK (Att_Cnt+1) applicable) 10 Transmit negative response NRC 0x35 < Att_Cnt_Limit (if SecurityAccess sendKey received OR Att_Cnt++ for sub-function xx (if applicable) Start Delay_Timer for sub-function xx (if applicable) Store Att_Cnt in non-volatile memory (if applicable) sub-function: yy == xx+1 AND Message length OK Key NOK Transmit negative response NRC 0x36 (Att_Cnt+1) >= Att_Cnt_Limit AND SecurityAccess sendKey received Transmit negative response NRC 0x24 sub-function: yy xx+1 Att_Cnt++ for sub-function xx (if applicable)j SecurityAccess sendKey received AND Transmit negative response NRC 0x13 Att_Cnt++ for sub-function xx (if applicable) sub-function: yy == xx+1 Message length NOK SecurityAccess request results in a general negative response code (e.g., minimum length, sub-function supported) according to the general negative response handling (see section 7.5) Transmit negative response code as defined in section 7.5 a The default use case will have a fixed value for the delay time, but it is also possible for a customer-specific use case that the value depends on the number of false access attempts in case they are stored in non-volatile memory b The exact length check can only be done after the evaluation of the sub-function, because the length depends on the sub-function (i.e., length of requestSeed is different from length of sendKey message) The check for the minimum length is done during the general service evaluation process c The sendKey sub-function (yy) must be of the expected securityAccessType (the active stored seed is for the corresponding requestSeed securityAccessType, i.e sendKey securityAccessType – 1) d Customer specific precondition can be checked (e.g fingerprint written in this driving cycle, engine not running, and vehicle not moving) e Once a given security level is unlocked, it shall remain unlocked even after a seed request is received for a different security level until either a new security level is completely unlocked or the security access is exited for other reasons (e.g., DiagnosticSessionControl accepted or session timeout occurs) f The counter for false access attempts will be increased with every valid formatted, but invalid key value and will be set to zero in case a valid key is received It may be a customer-specific use case to store this counter in non-volatile memory to be able to decide after reset if a delay has to be started or not (and possibly the delay time even depends on the value of this counter) In case a valid formatted key was received the stored seed shall be discarded ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS 383 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) g Once a given security level is unlocked, it shall remain unlocked even after a seed request is received for a different security level until either a new security is completely unlocked or the security access is exited for other reasons (e.g., diagnosticSessionControl received) h The sendKey sub-function must be of the expected access type (active stored seed is for sendKey accessType – 1) i The counter for false access attempts will be increased with every valid formatted, but invalid key value and will be set to zero in case a valid key is received It may be a customer-specific use case to store this counter in non-volatile memory to be able to decide after reset if a delay has to be started or not (and possibly the delay time even depends on the value of this counter) In case a valid formatted key was received the stored seed shall be discarded j The counter for false access attempts will be increased with every valid formatted, but invalid key value and will be set to zero in case a valid key is received It may be a customer-specific use case to store this counter in non-volatile memory to be able to decide after reset if a delay has to be started or not (and possibly the delay time even depends on the value of this counter) In case a valid formatted key was received the stored seed shall be discarded NOTE It has to be considered that when defining the state transitions via multiple conjunctions which are OR-ed together and each conjunction has an action applied that only one of the conjunctions of a disjunction becomes true at a time and forces a state transition in order to only execute one of the actions for a certain state transition defined (e.g only single negative response to be transmitted) ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 384 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Annex J (informative) Recommended implementation for multiple client environments J.1 Introduction This annex is intended to address the increasing number of use cases where the diagnostic vehicle topology is extended by adding one or more onboard diagnostic clients to the basic diagnostic topology with a single diagnostic client (external test equipment) and multiple servers (ECUs in vehicle) This document and the normative references herein not limit the number of diagnostic communication channels that a server can support The design of such a server-implementation for multi-client handling, needs to take into account that there are specifications and restrictions which force certain diagnostic clients to be served with a higher priority than others, e.g to fulfil existing legislative OBD requirements In this case the vehicle system design needs to ensure that parallel client requests can be handled by the respective server(s) An example for such a scenario would be an internal data logger which is connected to a server in parallel to a OBD scan tool externally connected to the diagnostic connector Either the overall vehicle design accounts for this parallel handling of client requests (e.g gateway arbiter mechanism) or the individual servers have to implement new strategies to assign the available resources to different clients In the server either the protocol implementation or the available resources are unique and can only be accessed by one client at a time This annex describes the implementation on server level only It is the vehicle manufacturer's responsibility to select a mechanism which fits its individual needs best J.2 Implementation specific limitations A unique Address Information must be assigned to each communication participant to allow the detection of different clients, which then can be used to limit the functionality or to assign priorities If the vehicle manufacturer's design does not use unique address information for certain peer protocol entities, the implementation described in this annex does not apply In this case the vehicle design needs to ensure that the chosen approach for handling of multiple clients fulfils the legislative requirements ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS 385 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) J.3 Use cases relevant for system design Figure J.1 shows an example of a vehicle topology where multiple clients exist Offboard client DoCAN or DoIP Onboard Client Central Gateway Sub-networks Onboard Client Auxiliary Gateway Auxiliary Gateway Server Server Auxiliary Gateway Server Server Server Server Server Server Onboard Client Server Server Server Server Server Server Figure J.1 — Example vehicle topology with onboard clients The implementation described in this document is intended to fulfil the use cases summarized in Figure J.1 All use case scenarios marked with an 'N/A' in the table below are not described as part of this standard It is highly recommended to avoid such scenarios The implementation and design rules specified in this Annex are not intended to support OBD communication requirements beyond the scenarios defined in Table J.1 ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 386 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) Table J.1 — Use case (UC) matrix of multiple client scenarios to be addressed Test equipment Off-board clients in use (vehicle external test equipment) OBD scan (tool) test OEM service equipment equipment Additional test equipment On-board clients (vehicle internal test equipment) test On-board client On-board client On-board client n OBD scan (tool) test equipment Not existent N/A A (UC 1) A (UC 1) A (UC 1) OEM service test equipment N/A Not existent X (UC 2) X (UC 2) X (UC 2) On-board client T (UC 3) X (UC 4) Not existent X (UC 5) X (UC 5) On-board client T (UC 3) X (UC 4) X (UC5) Not existent X (UC 5) … … … … … … On-board client n T (UC3) X (UC 4) X (UC5) X (UC5) Not existent T: Test equipment in use has higher pirority than additional test tool A: Additional test equipment has higher priority than test tool in use X: vehicle manufacturer specific (equal or different priority) When referring to the term 'test equipment in use' it needs to be differentiated between the server perspective and the client perspective as follows: ⎯ from a server perspective a test tool is considered in use if a request is currently processed or a nondefault session is active ⎯ from a client perspective a test tool is considered in use if an expected response has not yet been received, P3 client is not expired yet or a non-default session is active When referring to the term 'additional test equipment' the following definition applies: ⎯ a test equipment in this context is considered 'additional' if another tool is in use (refer to definition of test tool in use) When referring to the term 'OBD scan (tool) test equipment' the following definition applies: ⎯ On-Board Diagnostic (OBD) regulations require passenger cars and light, medium and heavy duty trucks to support communication of a minimum set of diagnostic information with off-board test equipment according to SAE J1978 / ISO 15031-4 A vehicle is considered non-compliant if the communication with the test equipment (e.g., handheld scan tools, PC based diagnostic computers, etc.) cannot be conducted as defined by the appropriate standards ⎯ An OEM specified test equipment which fulfils the OEM requirements and utilizes proprietary address information The OEM Service test equipment may utilize standardized parts, i.e SAE J2534 to communicate between the application and the Service tool hardware, but the communication to the vehicle utilizes OEM proprietary information When referring to the term 'on-board client' the following definition applies: ⎯ An ECU which may include at least a diagnostic client part but also may include a diagnostic server part The client part has functionality to sent diagnostic service requests to other servers in the vehicle An example may be a telematics gateway which can be integrated into an ECU which also includes other functionality The telematics gateway will act as a server if an OEM Service tool is connected to the 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS 387 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - When referring to the term 'OEM service test equipment' the following definition applies: ISO 14229-1:2013(E) diagnostic connector and requests data from the telematic gateway, but the telematic gateway itself also acts as a client requesting data from the other servers in the vehicle J.4 Use Case Evaluation: Table J.2 is intended to guide the decision what kind of concept the system designer should select Table J.2 — Evaluation of multiple client use cases Use Case # Pseudo parallel concept Priority concept UC 1, UC3 Pro: Pro: ⎯ both type of test equipment can be handled without stopping a protocol ⎯ processing based on dedicated priority assumption: OBD has higher prio than onboard client all clients will be informed by the server (worst case NRC 0x21, usually positive response) ⎯ if OBD scan (tool) test equipment client is permanently connected (3rd party tools), OBD and non-OBD requests can be handled in parallel dedicated timing behaviour for OBD responses, due to the fact the ongoing non-OBD response will be stopped ⎯ just one single buffer required Con: ⎯ resource management needed ⎯ ⎯ non-OBD request might be rejected or not even responded to client (on-board test equipment) request can only processed when OBD request is not currently processed ⎯ enable application to 'kill' ongoing requests from other clients ⎯ If permanently connected it depends on the request frequency whether the onboard client is still able to collect data on-board or not Pro: Pro: ⎯ ⎯ processing based on dedicated priority ⎯ allows to prioritize between different clients ⎯ 388 ⎯ Con: ⎯ OBD II: if the physical OBD CAN IDs are used for UDS concept is not working UC2, UC4, UC5 ⎯ no resource management needed client requests are handled based on arrival time without stopping a protocol if default session is active and protocol parameters are identical client is informed by NRC 0x21 when server is busy processing a different request or being in non-default session requested by a different client Con: Con: ⎯ parallel handling just possible if clients not request a non-default session ⎯ low prio client not informed about the fact that it won't be served ⎯ client shall always request default session when done with data retrieval ⎯ detection just via timeout (P2max timeout) ⎯ enable application to 'kill' ongoing requests from other clients Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - ⎯ ISO 14229-1:2013(E) J.5 Multiple client server level implementation J.5.1 Definition of diagnostic protocol In this context a diagnostic communication protocol is a compilation of specific parameter values depending on the Address Information (e.g protocol buffer size, session timings, supported services, security levels) A protocol is identified by a communication path established between peer protocol entities Each peer protocol entity has exactly one unique physical address, and n functional addresses (for the server(s)) identified by the respective N_AI NOTE That means one single address cannot be used for different protocols NOTE 2: As defined in this part of ISO 14229 there is only one diagnostic session state and one security level state active at a time in one specific ECU and shared over all active protocols J.5.2 Assumptions A protocol can either have exclusive protocol resources or multiple protocols can share one protocol resource The OBD scan (tool) test equipment client address has either the highest priority or an exclusive protocol resource is assigned to this address ensuring that the legislative requirements can be fulfilled J.5.3 Multiple client handling flow ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - If a server implements multiple client handling on server level the implementation shall adhere to the flow chart depicted in Figure J.2 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS 389 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) New request T_Data.ind: Request message received completely Is another diagnostic protocol requested than currently in progress? NO YES NO Is a diagnostic request in progress? Is an additional protocol resource available for parallel service execution? NO YES Has the received request a higher priority? Is NRC 0x21 handling supported? NO YES NO YES Stop active service execution (CancelReceive / CancelTransmit) Assign additional protocol resource to new protocol NO Ignore new request Send NRC 0x21 negative response Is server in nondefault session? YES Has the received request a higher priority? NO YES Stop active non-default diagnostic session, switch to default session Does parallel service access the same resource? YES Resource management: Allow access to resource only for high-prio request, cancel access of low-prio request and stop low-prio service execution / cancel transmission NO Process high-prio request, send response (if required) Wait for next request Key Reason for overflow: The temporary receive-buffer for the 2nd request is limited to one frame Figure J.2 — Multiple client handling flow 390 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - YES ISO 14229-1:2013(E) Bibliography [1] ISO4092:1988/Cor.1:1991, Road vehicles — Diagnostic systems for motor vehicles — Vocabulary — Technical Corrigendum [2] ISO/IEC7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model [3] ISO/TR 8509:1987, Information processing systems — Open Systems Interconnection — Service conventions [4] ISO/IEC10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services [5] ISO11992-4, Road vehicles — Interchange of digital information on electrical connections between towing and towed vehicles — Part 4: Diagnostics [6] ISO 14229-3, Road vehicles — Unified diagnostic services (UDS) — Part 3: Unified diagnostic services on CAN implementation (UDSonCAN) [7] ISO 14229-4, Road vehicles — Unified diagnostic services (UDS) — Part 4: Unified diagnostic services on FlexRay implementation (UDSonFR) [8] ISO 14229-5, Road vehicles — Unified diagnostic services (UDS) — Part 5: Unified diagnostic services on Internet Protocol implementation (UDSonIP)1) [9] ISO 14229-6, Road vehicles — Unified diagnostic services (UDS) — Part 6: Unified diagnostic services on K-Line implementation (UDSonK-Line) [10] ISO 14229-7, Road vehicles — Unified diagnostic services (UDS) — Part 7: Unified diagnostic services on Local Interconnect Network implementation (UDSonLIN)2) [11] ISO15031-2, Road vehicles — Communication between vehicle and external equipment for emissionsrelated diagnostics — Part 2: Guidance on terms, definitions, abbreviations and acronyms [12] ISO15031-6, Road vehicles — Communication between vehicle and external equipment for emissionsrelated diagnostics — Part 6: Diagnostic trouble code definitions [13] ISO 15765-4, Road vehicles — Diagnostic communication over Controller Area Network (DoCAN) — Part 4: Requirements for emissions-related systems [14] ISO22901-1, Road vehicles — Open diagnostic data exchange (ODX) — Part 1: Data model specification [15] ISO26021-2, Road vehicles — End-of-life activation of on-board pyrotechnic devices — Part 2: Communication requirements [16] ISO27145-2, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 2: Common data dictionary 1) To be published 2) Under preparation ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - 2013 – All rights Copyright International Organization © for ISO Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS 391 reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) ISO27145-3, Road vehicles — Implementation of World-Wide Harmonized On-Board Diagnostics (WWH-OBD) communication requirements — Part 3: Common message dictionary [18] SAE J1939:2011, Serial Control and Communications Heavy Duty Vehicle Network — Top Level Document [19] SAE J1939-73:2010, Application Layer — Diagnostics [20] ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating Point Arithmetic ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - [17] 392 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2013 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST ISO 14229-1:2013(E) ICS 43.180 Price based on 39 pages ``,`,,,,,,`,,,`,``,,`,,```,`,`-`-`,,`,,`,`,,` - ISO 2013 – All rights reserved Copyright International©Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 11/30/2013 22:26:47 MST