ISO 10681-2 INTERNATIONAL STANDARD First edition 2010-06-15 Road vehicles — Communication on FlexRay — Part 2: Communication layer services Véhicules routiers — Communication par FlexRay — Partie 2: Services de la couche de communication Reference number ISO 10681-2:2010(E) `,,```,,,,````-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 Not for Resale ISO 10681-2:2010(E) PDF disclaimer This PDF file may contain embedded typefaces In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing In downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy The ISO Central Secretariat accepts no liability in this area Adobe is a trademark of Adobe Systems Incorporated Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing Every care has been taken to ensure that the file is suitable for use by ISO member bodies In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below `,,```,,,,````-`-`,,`,,`,`,,` - COPYRIGHT PROTECTED DOCUMENT © ISO 2010 All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing 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 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) Contents Page Foreword iv Introduction v Scope Normative references Terms, definitions, symbols and abbreviated terms Conventions Communication layer overview Communication layer services 10 Communication layer protocol 22 Data link layer usage 48 Annex A (informative) Implementation examples 58 Bibliography 64 iii `,,```,,,,````-`-`,,`,,`,`,,` - © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(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 10681-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical and electronic equipment ISO 10681 consists of the following parts, under the general title Road vehicles — Communication on FlexRay: Part 1: General information and use case definition ⎯ Part 2: Communication layer services `,,```,,,,````-`-`,,`,,`,`,,` - ⎯ iv Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) Introduction This part of ISO 10681 is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers (see example in Table 1) When mapped on this model, this part of ISO 10681 incorporates the network layer (layer 3) and the transport layer (layer 4) services as communication layer services Table — Example of enhanced diagnostic specifications according to the OSI layers Applicability OSI layers Vehicle manufacturer enhanced diagnostics Application layer ISO 14229-1 Presentation layer Seven layers according to ISO/IEC 7498-1 and ISO/IEC 10731 N/A Session layer ISO 14229-2 Transport layer ISO 10681-2 Network layer Data link layer FlexRay Communications Systems Protocol Specification Physical layer FlexRay Communications System Electrical Physical Layer Specification `,,```,,,,````-`-`,,`,,`,`,,` - v © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale `,,```,,,,````-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale INTERNATIONAL STANDARD ISO 10681-2:2010(E) Road vehicles — Communication on FlexRay — Part 2: Communication layer services Scope This part of ISO 10681 specifies the requirements for a communication protocol tailored to meet the requirements of FlexRay-based vehicle network systems as specified in the FlexRay Communications Systems Protocol Specification As the communication protocol combines the network layer and transport layer functionality (OSI layers and 4), this part of ISO 10681 does not explicitly distinguish between these layer services ⎯ transmit messages with known data length; ⎯ transmit messages with unknown but finite data length; ⎯ additional acknowledgement with retry mechanism; ⎯ routing data on the fly; ⎯ support of dynamic frame length 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/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model ISO 7498-2, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 2: Security Architecture ISO/IEC 7498-3, Information technology — Open Systems Interconnection — Basic Reference Model: Naming and addressing ISO/IEC 7498-4, Information processing systems — Open Systems Interconnection — Basic Reference Model — Part 4: Management framework ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale `,,```,,,,````-`-`,,`,,`,`,,` - The technical features of this communication protocol are as follows: ISO 10681-2:2010(E) Terms, definitions, symbols and abbreviated terms 3.1 Terms and definitions For the purposes of this document, the terms and definitions given in ISO/IEC 7498-1, ISO 7498-2, ISO/IEC 7498-3 and ISO/IEC 7498-4 and the following apply 3.1.1 communication layer CL layer that includes the network layer (layer 3) and the transport layer (layer 4) 3.1.2 protocol data unit PDU 〈layered system〉 data unit that is specified in the protocol of a given layer NOTE The protocol data unit contains user data of that layer and possible protocol control information The protocol data unit of layer X is the service data unit of its lower layer (X − 1) 3.1.3 service data unit SDU 〈layered system〉 set of data that is sent by a user of the service in a given layer NOTE 3.2 It is transmitted to a peer service user with no semantic change Abbreviated terms For the purposes of this document, the following abbreviated terms apply ABT abort ACK acknowledge BC bandwidth control BfS buffer size BP byte position C_AI communication address information C_Ar communication layer timing parameter A receiver C_As communication layer timing parameter A sender C_Br communication layer timing parameter B receiver C_Bs communication layer timing parameter B sender C_Cr communication layer timing parameter C receiver C_Cs communication layer timing parameter C sender C_CT communication type C_Data communication layer data transfer service name C_PCI communication protocol control information C_SA communication source address C_TA communication target address `,,```,,,,````-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) `,,```,,,,````-`-`,,`,,`,`,,` - C_TAType communication target address type CF consecutive frame CL communication layer COMM communication CTS continue to send C_PDU communication layer protocol data unit C_SDU communication layer service data unit DLL data link layer ECU electronic control unit EOB end of block FC flow control FIFO first in first out FPL frame payload length FR FlexRay FS flow status Ind indication LF last frame L_PDU data link layer protocol data unit max maximum ML message length MNPC maximum numbers of PDUs per cycle N/A not applicable N_PDU network protocol data unit NUM number OVFLW overflow PDU protocol data unit pLatestTx latest point of transmission Req request RET retry RX receive SCexp separation cycle exponent SDU service data unit SN sequence number STF start frame STFA start frame acknowledged STFU start frame unacknowledged © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) UNEXP unexpected UNUM unsigned numeric TX transmission WFT wait frame transmission WT wait 3.3 Symbols Σ summation ≠ not equal Conventions 5.1 `,,```,,,,````-`-`,,`,,`,`,,` - ISO 10681 is based on the conventions discussed in the OSI Services Conventions (ISO/IEC 10731:1994) as they apply for diagnostic services Communication layer overview General This clause describes the overall functionality of the communication layer This part of ISO 10681 specifies an unacknowledged and acknowledged communication layer protocol for the exchange of data with known or unknown length between network nodes, e.g from ECU to ECU, or between a diagnostic tester equipment and an ECU If the data to be transferred not fit into a single L_PDU, a segmentation method is provided In order to describe the function of the communication layer, services provided to upper layers and the internal operation of the communication layer have to be considered 5.2 Services provided by communication layer to upper layers The service interface defines a set of services that are needed to access the functions offered by the communication layer, i.e transmission/reception of data and setting of protocol parameters Four types of services are defined a) Communication services These services, of which the following are defined, enable the transfer of up to 64 kbytes of data 1) C_Data.request This service is used to request the transfer of data If necessary, the communication layer segments the data 2) C_Data_STF.indication This service is used to signal the beginning of a segmented message reception to the upper layer 3) C_Data.indication This service is used to provide received data to the upper layer Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) Handling description (referencing the numbers given in Figure 21): 1) The communication layer receives a transmit request from the upper layer 2) The CL reserves a transmit queue for the complete transmission of this particular message (e.g Queue 4) This reservation includes the allocation of the FlexRay channel(s) to be used (see definitions above) 3) The CL starts filling the queue with C_PDUs (e.g 4A, 4B, 4C, etc.) as long as space in the queue is available according to the Filling-Level With each inserted C_PDU, the CL increments the FillingLevel by 4) The DLL scheduler retrieves the C_PDUs from each queue in ascending order The following conditions have to be satisfied in order to retrieve a C_PDU from an individual queue and place it in the next free L_PDU ⎯ Filling-Level of the individual queue must be greater than zero ⎯ Tx-Pending-Counter of the individual queue must be equal to zero at the start of a new FlexRay cycle ⎯ A suitable L_PDU must be available for transmission A suitable L_PDU fulfils the following conditions ⎯ The FlexRay channel(s) as given in the queue attributes must be met (see above) ⎯ All subsequent C_PDUs retrieved from the same queue must be transmitted on the same preselected FlexRay channel ⎯ L_PDU is not occupied by another queue If a suitable L_PDU has been found then the Tx-Pending-Counter is incremented by and the FillingLevel is decremented by If no suitable condition is found the DLL scheduler switches to the next queue and evaluates the possibility for a transmission again 5) The DLL scheduler generates a transmit confirmation for each transmitted C_PDU Each confirmation decrements the Tx-Pending-Counter (by 1) of the particular queue where the confirmed C_PDU belongs to A transmission might be executed in a following FlexRay cycle because the latest point of transmission (pLatestTx) has elapsed Therefore, the DLL scheduler needs to postpone the transmission until the Tx-Pending-Counter of the affected queue is equal to zero Figure 22 shows a message transfer example where three different L_PDU's are assigned within the dynamic segment The picture considers a multi frame message transfer (consecutive frames only): `,,```,,,,````-`-`,,`, 52 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) FrCL = FlexRay Communication Layer Figure 22 — Example for message transfer mechanism on CL and DLL Interface (API) For the example given, the L_PDUs n + 1, n + and n + are assigned for CL communication The repetition for the L_PDUs is equal to 1) The first consecutive frame (CF) is transmitted within the guaranteed part of the dynamic segment 2) The second CF won't be transmitted within the same cycle (m and m + 1) because the assigned slot is within the non-guaranteed part and 'pLatestTx' has been passed already 3) The second CF will be transmitted within cycle m + 4) After a successful transmission of the second CF (positive confirmation received), the transmission of the third CF is started in cycle m + 8.3.2 Receive data flow Figure 23 depicts the receive data flow `,,```,,,,````-`-`,,`,,`,`,,` - 53 © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) Figure 23 — Communication layer PDU distribution for reception The DLL receives any FlexRay frame configured for communication layer handling (L_PDU) The header and trailer are stripped off and the payload data (C_PDU) is forwarded to the communication layer ⎯ The communication layer interprets the address information embedded in the received C_PDU in order to identify whether the node is addressed If the address matches, the C_PDU is processed 8.4 `,,```,,,,````-`-`,,`,,`,`,,` - ⎯ Data link layer interface services 8.4.1 L_Data.request The request primitive requests transmission of that shall be mapped within specific attributes of the data link protocol data unit selected by means of , , and L_Data.request 8.4.2 ( , , , , ) L_Data.indication The service primitive indicates data link layer event to the upper layer and delivers identified by a Address information are part of the which will be evaluated by the upper layer Any information is not necessary because the address information (TA, SA, etc.) is part of the payload information Furthermore, no PDU filtering is part of the communication layer which would require an information L_Data.indication ( , ) 54 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) 8.4.3 L_Data.confirm The service primitive confirms the completion of an L_Data.request service for a specific L_Data.confirm 8.5 ( , ) Data link layer service parameters The following data link layer service parameters are defined: Identifier which is assigned to a transmission queue of the CL (API specific value such as a handle) Type: unsigned bits Range: to FF hex This parameter identifies the FlexRay channel(s) to be used for the transmission of the C_PDU: Type: enumeration Range: channel_A, channel_B, channel_AB NOTE The communication layer evaluates the address information (C_TA) in order to select the FlexRay channel This parameter identifies the FlexRay segment to be used for the transmission of the C_PDU: Type: enumeration Range: static, dynamic NOTE The communication layer evaluates the address information (C_TA) in order to select the FlexRay segment Length of the field, size of C_PDU to be transmitted (see Figure 23) Type: unsigned bits Range: to FE hex This parameter includes all data of the C_PDU to be transmitted Type: string of bytes with length Length of the field, size of C_PDU received also including potential fill bytes Type: unsigned bits Range: to FE hex This parameter includes all data received, including the C_PDU and potential fill-bytes Type: string of bytes with length `,,```,,,,````-` 55 © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) This parameter contains the status relating the execution of the L_Data.request service primitive Type: enumeration Range: L_OK, WRONG_LENGTH ⎯ WRONG_FR_CHANNEL, L_WRONG_FR_SEGMENT, L_OK This value means that the service execution has completed successfully ⎯ L_WRONG_FR_CHANNEL This value is issued to the service user to indicate that the service did not execute due to an invalid parameter ⎯ L_WRONG_FR_SEGMENT This value is issued to the service user to indicate that the service did not execute due to an invalid parameter ⎯ L_WRONG_LENGTH This value is issued to the service user to indicate that the service did not execute due to an invalid parameter ⎯ L_NOT_OK This value is issued to the service user if an immediate transmission is conducted with failure by the DLL, e.g the FlexRay-CC refuses access to the Tx-object 8.6 Mapping of C_PDU fields Table 34 specifies the mapping of the communication layer C_PDUs onto the FlexRay data link layer L_PDU payload field Table 34 — Mapping of C_PDU into the L_PDU payload field Name L_PDU payload field Byte position B1-2 B3-4 StartFrame (STF) C_TA C_SA ConsecutiveFrame_x (CFxa) C_TA C_SA FlowControl (FC_CTS) C_TA C_SA C_PCI FlowControl (FC_ACK/RET) C_TA C_SA C_PCI FlowControl (FC_ABT, FC_WT) C_TA C_SA LastFrame (LF) C_TA C_SA B6 B7 B8 C_PCI C_PCI D1 D2 B9 B10 B11 … Bn D1 D2 D3 … Dm D3 D4 D5 … Dm D1 D2 D3 … Dm C_PCI C_PCI x = or 2, representing ConsecutiveFrame_1, ConsecutiveFrame_2 and ConsecutiveFrame_EOB `,,```,,,,````-`-`,,`,,`,`,,` - a B5 NOTE Grayed out cells are not utilized for data information 56 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) 8.7 Hardware Address filtering within dynamic segment The Payload Preamble Indicator (1 Bit) in combination with the MessageIdentifier might (optional feature) be used for hardware acceptance filtering within the dynamic segment It can be used based on current C_PDU mapping onto FlexRay L_PDU payload field (see Table 34) For communication within the static segment, the Payload Preamble Indicator shall always be set to zero Figure 24 — Target address mapping for dynamic segment NOTE 8.8 For simplicity, potential fill Bytes on the FlexRay Data Link Layer are not shown in the Figure 24 Multiple C_PDU to single L_PDU mapping Figure 25 graphically depicts a concept utilizing the potential placement of multiple C_PDUs into a single L_PDU as stated in 8.2 Figure 25 — Multiple C_PDU to single L_PDU mapping `,,```,,,,````-`-`,,`,,`,`,,` - 57 © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) Annex A (informative) Implementation examples A.1 Scope This annex shows a possible implementation of an API which considers buffer constraints in the sender and the receiver It is assumed that there is at least the memory available for a single C_PDU to be transmitted in a SingleFrame; therefore, this document focuses on the following cases only ⎯ Case #1: Message Length < TxBufferSize, MessageLength < Rx Buffer ⎯ Case #2: Message Length > TxBufferSize, MessageLength < Rx Buffer ⎯ Case #3: Message Length < TxBufferSize, MessageLength > Rx Buffer ⎯ Case #4: Message Length > TxBufferSize, MessageLength > Rx Buffer A.2 Case analysis A.2.1 Case #1: Message Length < TxBufferSize, MessageLength < Rx Buffer In the following case, the message to be transmitted fits into the transmit buffer and receive buffer completely Figure A.1 depicts this Figure A.1 — MLTxBufferSize, ML Rx Buffer In this case, the message to be transmitted fits completely into the transmit buffer, but it does not fit completely into the receive buffer Figure A.3 depicts this Figure A.3 — MLRxBufferSize `,,```,,,,````-`-`,,`,,`,`,,` - 60 Organization for Standardization Copyright International Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) 1) The sender requests the transmission of a message with MessageLength (ML) via C_Data.req and hands over the complete message, because it fits into its communication layer (ActualLength = 0) 2) The StartFrame of the message is received by the receiver and indicated to the upper layer via C_Data_STF.indication 3) The receiver reports its buffer capabilities back to the sender in the FlowControl frame via the BfS parameter For the given case, only part of the message fits into the buffer of the receiver (BfS < ML) 4) The sender starts the block following the FlowControl frame with a ConsecutiveFrame 5) The last frame of the block (CF_EOB) indicates that an acknowledgement of that block is required from the receiver, because the sender uses the reported BfS information based on the receiver buffer capabilities to perform the block acknowledgement 6) The receiver acknowledges the reception There is no adjustment of the buffer in the sender required 7) In the receiver, the data received up to that point are reported to the upper layer via C_Data.ind with C_Result = C_MOREDATA and the buffer is adjusted, so it can be used to receive the next block 8) The sender starts the next block following the FlowControl frame with a ConsecutiveFrame 9) The last frame of the block (CF_EOB) indicates that an acknowledgement of that block is required from the receiver, because the sender uses the reported BfS information based on the receiver buffer capabilities to perform the block acknowledgement 10) In the receiver, the data received up to that point are reported to the upper layer via C_Data.ind with C_Result = C_MOREDATA and the buffer is adjusted, so it can be used to receive the next block 11) The receiver acknowledges the reception There is no adjustment of the buffer in the sender required 12) Now the complete message is transmitted After the transmission of the Last Frame (assumed it is an unacknowledged transmission with a known message length), the completion is indicated in the sender via C_Data.con 13) The completion of the reception is indicated in the receiver via C_Data.ind with C_Result =C_OK A.2.4 Case #4: ML > TxBufferSize, ML > Rx Buffer In this case, the message to be transmitted does not fit completely into the transmit buffer nor the receive buffer Figure A.4 depicts this `,,```,,,,````-`-`,,`,,`,`,,` - © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale 61 ISO 10681-2:2010(E) Figure A.4 — ML>TxBufferSize, ML>RxBufferSize 1) The sender requests the transmission of a message with MessageLength (ML) set to the total length of the message via C_Data.req but hands over only the amount of data that fits into the sender buffer (ActualLength 0) The StartFrame transmitted indicates the complete message via ML 2) The StartFrame of the message is received by the receiver and indicated to the upper layer via C_Data_STF.indication 3) The receiver reports its buffer capabilities back to the sender in the FlowControl frame via the BfS parameter For the given case, only part of the message fits into the buffer of the receiver (BfS < ML) 4) The sender starts the block following the FlowControl frame with a Consecutive Frame 5) The last frame of the block (CF_EOB) indicates that an acknowledgement of that block is required from the receiver This can either be forced by the buffer constraints in the sender or via the reported BfS of the receiver 6) The receiver acknowledges the reception 7) In the receiver, the data received up to that point are reported to the upper layer via C_Data.ind with C_Result = C_MOREDATA and the buffer is adjusted, so it can be used to receive the next block 8) The communication layer in the sender indicates to the upper layer to feed in further data for this message via C_Data.con with C_Result = C_MOREDATA 9) The upper layer in the sender now provides further data to be transmitted `,,```,,,,````-`-`,,`,,`,`,,` - 10) The sender starts the next block following the FlowControl frame with a ConsecutiveFrame 11) The last frame of the block (CF_EOB) indicates that an acknowledgement of that segment is required from the receiver This can either be forced by the buffer constraints in the sender or via the reported BfS of the receiver 62 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale ISO 10681-2:2010(E) 12) The receiver acknowledges the reception 13) In the receiver, the data received up to that point are reported to the upper layer via C_Data.ind with C_Result = C_MOREDATA and the buffer is adjusted, so it can be used to receive the next block 14) The communication layer in the sender indicates to the upper layer to feed in further data for this message via C_Data.con with C_Result = C_MOREDATA 15) The upper layer in the sender now provides further data to be transmitted 16) Now the complete message is transmitted After the transmission of the Last Frame (assumed it is an unacknowledged transmission with a known message length), the completion is indicated in the sender via C_Data.con with C_Result = C_OK `,,```,,,,````-`-`,,`,,`,`,,` - 17) The completion of the reception is indicated in the receiver via C_Data.ind with C_Result = C_OK 63 © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) Bibliography [1] AUTOSAR, Specification of Module FlexRay Transport [2] ISO 14229-1 ), Road vehicles — Unified diagnostic services (UDS) — Part 1: Specification and requirements [3] ISO 14229-25), Road vehicles — Unified diagnostic services (UDS) — Part 2: Session layer services [4] ISO 14229-45), Road vehicles — Unified diagnostic services (UDS) — Part 4: Unified diagnostic services on FlexRay implementation (UDSonFR) [5] FlexRay Communications Systems Protocol Specification `,,```,,,,````-`-`,,`,,`,`,,` - 4) Under preparation (Revision of ISO 14229-1:2006) 5) Under preparation 64 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2010 – All rights reserved Not for Resale `,,```,,,,````-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Not for Resale ISO 10681-2:2010(E) ICS 43.040.15 Price based on 64 pages © ISO 2010 – All rights reserved Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS `,,```,,,,````-`-`,,`,,`,`,,` - Not for Resale