INTERNATIONAL STANDARD ISO 17215-2 First edition 2014-04-15 Road vehicles — Video communication interface for cameras (VCIC) — Part 2: Service discovery and control Véhicules routiers — Interface de communication vidéo pour caméras (ICVC) `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS Reference number ISO 17215-2:2014(E) Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT © ISO 2014 ISO 17215-2:2014(E) `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - COPYRIGHT PROTECTED DOCUMENT © ISO 2014 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 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) Contents Page Foreword iv Introduction v 1 Scope Normative references Terms, definitions, and abbreviated terms 3.1 Terms and definitions 3.2 Abbreviated terms 4 Conventions 5 Overview 5.1 General 5.2 Document overview and structure 5.3 Open Systems Interconnection (OSI) model 5.4 Document reference according to OSI model 6 SOME/IP 6.1 General 6.2 Header 6.3 Wire format 10 6.4 Parameter serialization 12 `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - Service discovery protocol specification 17 7.1 General 17 7.2 Definitions 17 7.3 General requirements 17 7.4 Service discovery ECU-internal interface 19 7.5 Packet format 19 Runtime behaviour 30 8.1 General 30 8.2 SD communication 31 8.3 RPC communication 38 Bibliography 41 © ISO 2014 – 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, 05/13/2014 23:04:42 MDT iii ISO 17215-2:2014(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 The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the different types of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives). `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - 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. Details of any patent rights identified during the development of the document will be in the Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement For an explanation on the meaning of ISO specific terms and expressions related to conformity assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers to Trade (TBT) see the following URL: Foreword - Supplementary information The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electric and electronic equipment ISO 17215 consists of the following parts, under the general title Road vehicles — Video communication interface for cameras (VCIC): — Part 1: General information and use case definition — Part 2: Service discovery and control — Part 3: Camera message dictionary — Part 4: Implementation of communication requirements iv Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) Introduction Driver assistance systems are more and more common in road vehicles From the beginning, cameras were part of this trend Analogue cameras were used in the beginning, because of lower complexity of the first systems With increasing demand for more advanced functionality, digital image processing has been introduced So-called one box design cameras (combining a digital image sensor and a processing unit) appeared in the vehicles Currently, the market demands such systems with multiple functions Even different viewing directions are in use It seems to be common sense that up to 12 cameras in a single vehicle will be seen in the next future Out of this and the limitation in size, power consumption, etc it will lead to designs where the cameras are separated from the processing unit Therefore, a high performance digital interface between camera and processing unit is necessary This International Standard has been established in order to define the use cases, the communication protocol, and the physical layer requirements of a video communication interface for cameras which covers the needs of driver assistance applications The video communication interface for cameras — incorporates the needs of the whole life cycle of an automotive grade digital camera, `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - — utilizes existing standards to define a long-term stable state-of-art video communication interface for cameras usable for operating and diagnosis purpose, — can be easily adapted to new physical data link layers including wired and wireless connections by using existing adaption layers, and — is compatible with AUTOSAR This part of ISO 17215 is related to the general information and use case definition This is a general overview document which is not related to the OSI model To achieve this, it is based on the open systems interconnection (OSI) basic reference model specified in ISO/IEC 7498-1 and ISO/IEC 10731 which structures communication systems into seven layers When mapped on this model, the protocol and physical layer requirements specified by this International Standard, in accordance with Table 1, are broken into following layers: — application (layer 7), specified in ISO 17215-3; — presentation layer (layer 6), specified in ISO 17215-2; — session layer (layer 5), specified in ISO 17215-2; — transport protocol (layer 4), specified in ISO 17215-4, ISO 13400-2; — network layer (layer 3), specified in ISO 17215-4, ISO 13400-2; — data link layer (layer 2), specified in ISO 17215-4, ISO 13400-3; — physical layer (layer 1), specified in ISO 17215-4, ISO 13400-3 © ISO 2014 – 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, 05/13/2014 23:04:42 MDT v ISO 17215-2:2014(E) Table 1 — Specifications applicable to the OSI layers Applicability Seven layers according to ISO 7498-1 and ISO/IEC 10731 OSI layers Video communication interface for cameras Application (layer 7) ISO 17215-3 Session (layer 5) ISO 17215-2 Presentation (layer 6) Transport (layer 4) Network (layer 3) Data link (layer 2) Physical (layer 1) Camera diagnostics ISO 17215-2 ISO 17215-4 Other future interface standards ISO 17215-4 ISO 13400-2 ISO 13400-3 ISO 17215-1 has been established in order to define the use cases for vehicle communication systems implemented on a video communication interface for cameras; it is an overall document not related to the OSI model ISO 17215-3 covers the application layer implementation of the video communication interface for cameras; it includes the API ISO 17215-2 covers the session and presentation layer implementation of the video communication interface for cameras ISO 17215-4, being the common standard for the OSI layers to for video communication interface for cameras, complements ISO 13400-2 and ISO 13400-3 and adds the requirement for video transmission over Ethernet `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - ISO 17215-2 and ISO 17215-3 (OSI layer to 7) services have been defined to be independent of the ISO 17215-4 (OSI layer to 4) implementation Therefore ISO 17215-4 could be replaced by other future communication standards vi Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT INTERNATIONAL STANDARD ISO 17215-2:2014(E) Road vehicles — Video communication interface for cameras (VCIC) — Part 2: Service discovery and control 1 Scope This part of ISO 17215 specifies how services can be discovered and controlled This functionality is located mainly in layer of the OSI model Both discovery and control are implemented using the scalable service oriented middlewire over IP (SOME/IP) Figure 1 shows a diagram of these aspects and their relation to other parts of this International Standard Figure 1 — Overview of ISO 17215 The general terminology defined in ISO 17215-1 is also used in this part of ISO 17215 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application For dated references, only the edition cited applies For undated references, the latest edition of the referenced document (including any amendments) applies ISO 7498-1, Information processing systems — Open Systems Interconnection — Basic Reference Model: The Basic Model — Part 1 ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - © ISO 2014 – 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, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) ISO 17215 (all parts), Road vehicles — Video communication interface for cameras (VCIC) NOTE The keywords shall, should, etc as defined in [IETF RFC 2119] are used in this part of ISO 17215 to indicate requirement levels Capitalization of those keywords is not required If an RFC referenced by this part of ISO 17215 has been updated by one or several RFCs, the update is fully applicable for the purpose of implementing this International Standard This presumes the additional document describes an implementation which is compatible with implementation described by document referred to herein If one or more errata for an RFC referenced by this part of ISO 17215 have been published, all of these errata documents are fully applicable for the purpose of implementing this International Standard It is assumed that future implementations of this International Standard will use the most recent versions of the referenced RFCs, but maintain backward compatibility to existing implementations Terms, definitions, and abbreviated terms For the purposes of this document, the terms and definitions given in ISO 17215-1 and the following apply 3.1.1 AUTOSAR open and standardized automotive software architecture, jointly developed by automobile manufacturers, suppliers, and tool developers 3.1.2 client software component that uses a service instance, e.g by invoking a method 3.1.3 event fire and forget message invoked on changes or cyclic and sent from server to client 3.1.4 event group logical grouping of events or notifications within a service in order to ease subscription 3.1.5 field representation of a remote property which has up to one getter, up to one setter, and up to one notifier Note 1 to entry: A getter/setter is a method to get/set the value of a field 3.1.6 fire and forget communication RPC call that consists only of a request message 3.1.7 interface definition concrete specification of a service interface (e.g in IDL or PDU notation) Note 1 to entry: In the case of ISO 17215, the interface definition is contained in ISO 17215‑3 3.1.8 method procedure, function, or subroutine that can be called by a client 2 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - 3.1 Terms and definitions ISO 17215-2:2014(E) 3.1.9 notification fire and forget message that is sent on defined status changes or periodically by the notifier of an event or a field Note 1 to entry: Field messages cannot be distinguished from an event message; therefore, when referring to an event message, this shall also be true for the messages of notifiers of fields 3.1.10 parameters input, output, or input/output arguments of a method `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - 3.1.11 remote procedure call method call between two processes that is transmitted using messages 3.1.12 request message from the client to the server invoking a method 3.1.13 request/response communication RPC that consists of a request and a response 3.1.14 response message from the server to the client transporting results of a method invocation 3.1.15 server software component that offers a service instance, e.g by providing a method 3.1.16 service logical combination of zero or more methods, zero or more fields, and zero or more events 3.1.17 service instance instantiation of the service interface, which can exist more than once in the vehicle or on an ECU 3.1.18 service interface abstract specification of a service including its methods, events, and fields 3.1.19 union data structure that can dynamically assume different data types (also known as variant) © ISO 2014 – 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, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) 3.2 Abbreviated terms Term Description OSI Open Systems Interconnection RPC Remote Procedure Call PDU ECU IDL AUTOSAR Protocol Data Unit Electronic Control Unit Interface Description Language AUTomotive Open System ARchitecture 4 Conventions ISO 17215 is based on the conventions specified in the OSI service conventions (ISO/IEC 10731) as they apply for physical layer, protocol, network and transport protocol, and diagnostic services 5 Overview 5.1 General ISO 17215 has been established in order to implement a standardized video communication interface for cameras in vehicles The focus of ISO 17215 is using existing protocols Figure 1 specifies the relation to the other parts of the standard Figure 2 specifies the relation of ISO 17215 to existing protocols 5.2 Document overview and structure This International Standard consists of a set of four sub-documents, which provide all references and requirements to support the implementation of a video communication interface for cameras according to the standard at hand — ISO 17215-1: This part provides an overview of the document set and structure along with use case definitions and a common set of resources (definitions, references) for use by all subsequent parts — ISO 17215-3: This part specifies the standardized camera messages and data types used by an VCIC camera (OSI layer 7) — ISO 17215-4: This part specifies standardized low-level communication requirements for implementation of the physical layer, data link layer, network layer, and transport layer (OSI layers to 4) 5.3 Open Systems Interconnection (OSI) model This International Standard is based on the Open Systems Interconnection (OSI) basic reference model as specified in ISO/IEC 7498 which structures communication systems into seven layers 4 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - — ISO 17215-2: This part specifies the discovery and control of services provided by a VCIC camera ISO 17215-2:2014(E) Figure 14 — SOME/IP SD IPv6 endpoint option layout 7.5.2.4 IPv4 multicast option The IPv4 multicast option is used by the server to announce the IPv4 multicast address, the transport layer protocol (ISO/OSI layer 4), and the port number the multicast events and multicast notification events are sent to As transport layer protocol, currently, only UDP is supported The format of the IPv4 multicast option shall be as follows — Length [uint16]: Shall be set to 0x0009 — The IPv4 multicast option shall use the type 20 — Reserved [uint8]: Shall be set to 0x00 — IPv4 address [uint32]: Shall transport the multicast IP address as 4 bytes — L4-Proto [uint8]: Shall be set to the transport layer protocol (ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP) — L4-Port [uint16]: Shall be set to the port of the layer protocol The IPv6 multicast option and not the IPv6 endpoint option shall be referenced by SubscribeEventgroupAck messages `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - Figure 15 — SOME/IP SD IPv4 Multicast option layout 7.5.2.5 IPv6 multicast option The IPv4 multicast option is used by the server to announce the IPv6 multicast address, the transport layer protocol (ISO/OSI layer 4), and the port number the multicast events and multicast notification events are sent to As transport layer protocol, currently, only UDP is supported 28 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) The format of the IPv6 multicast option shall be as follows — Length [uint16]: Shall be set to 0x0021 — The IPv4 multicast option shall use the type 22 — Reserved [uint8]: Shall be set to 0x00 — IPv6 address [uint32]: Shall transport the multicast IP address as 16 bytes — L4-Proto [uint8]: Shall be set to the transport layer protocol (ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP) — L4-Port [uint16]: Shall be set to the port of the layer 4 protocol The IPv4 multicast option and not the IPv4 endpoint option shall be referenced by SubscribeEventgroupAck messages Figure 16 — SOME/IP SD IPv4 Multicast option layout 7.5.3 Example PDU Figure 17 shows an example service discovery packet containing two entries and one option The IP header and the UDP header are only shown in abstract form `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - © ISO 2014 – 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, 05/13/2014 23:04:42 MDT 29 `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - ISO 17215-2:2014(E) Figure 17 — Example SOME/IP SD PDU Runtime behaviour 8.1 General This clause describes the runtime behaviour of SOME/IP and SOME/IP-SD 30 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT ISO 17215-2:2014(E) 8.2 SD communication 8.2.1 General — Whenever possible, the implementation shall combine multiple operations (e.g FindService, OfferService, Publish, Subscribe) into one packet to reduce network load — All delay values used below shall be specified as a minimum and maximum delay Each service instance shall randomly choose a concrete delay value from the interval — The delay and timeout values shall be chosen by the system integrator Generally, timeout values should be below 2 s to avoid lengthy “hangs” — Caching can be implemented The service discovery implementation can temporarily store information locally to reduce the amount of network queries To allow for cleanup of stale client registrations (to avoid that the list of listeners fills over time), a cleanup mechanism might be required — Query for Service ID shall produce a result (the answers can come from different hosts), the result being a list of records for all service instances, which have the given Service ID — Query for the combination (Instance ID and Service ID) shall produce a result (the answers can come from different hosts), the result being a list of records for all service instances, which have the requested (Instance ID and Service ID) in common — The server shall delay the answer to FindService and FindEventgroup messages transported by multicast/broadcast for a delay based on REQUEST_RESPONSE_DELAY This is to avoid flooding the network The server shall not delay unicast messages that are answered with unicast messages — RequestService, SubscribeEventgroup, SubscribeEventgroupAck, and SubscribeEventgroupNack messages shall be sent as unicast — FindService, OfferService, FindEventgroup, and PublishEventgroup messages should be sent as multicast — FindService/FindEventgroup (respectively RequestService, SubscibeEventgroup) messages received with the unicast flag set to 1, shall be answered with a unicast response if the last announcement was sent less than 1/2 CYCLIC_OFFER_DELAY (respectively 1/2 CYCLIC_REQUEST_ DELAY) ago — FindService/FindEventgroup (respectively RequestService, SubscibeEventgroup) messages received with the unicast flag set to 1, shall be answered with a multicast response if the last announcement was 1/2 CYCLIC_OFFER_DELAY (respectively 1/2 CYCLIC_REQUEST_DELAY) or more ago — FindService/FindEventgroup messages received with unicast flag set to (multicast), shall be answered with a multicast response 8.2.2 Startup The startup behaviour of the particular service instances or Eventgroups has three phases: initial, repetition, and main The phases are illustrated in Figure 18 — After the network link has been established, the service discovery implementation shall be in the initial phase and nothing for INITIAL_DELAY milliseconds NOTE After sending the first message, the system enters the repetition phase — The service discovery shall send out up to REPETITIONS_MAX announcements during the repetitions phase with a delay of REPETITIONS_BASE_DELAY*2N, where N is increasing from to (REPETITIONS_MAX-1) `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - © ISO 2014 – 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, 05/13/2014 23:04:42 MDT 31 ISO 17215-2:2014(E) — Sending find entries shall be stopped after receiving the corresponding offer entries by jumping to the main phase in which no find entries are sent NOTE After the repetitions phase, the main phase is entered — In the main phase, offer messages shall be sent periodically if a CYCLIC_OFFER_DELAY is configured — After entering the main phase, CYCLIC_OFFER_DELAY is waited before sending the first message — For requests/subscriptions, the same cyclic behaviour as for the offers shall be implemented with the parameter CYCLIC_REQUEST_DELAY instead of CYCLIC_OFFER_DELAY — For find entries (Find Service and Find Eventgroup) no cyclic messages shall be sent in the main phase 32 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - — After a message for a specific service instance, the service discovery waits for CYCLIC_OFFER_ DELAY before sending the next message for this service instance `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - ISO 17215-2:2014(E) Figure 18 — Startup behaviour 8.2.3 Multiple service instances Instances of the same service are identified through different Instance IDs Multiple service instances can reside on different ECUs and also multiple service instances of one or more services can reside on one single ECU The Instance IDs are used for service discovery, but are not contained in the RPC header Multiple instances of the same service on a single ECU shall listen on different ports A service instance can be identified through the socket (i.e the combination of IP address, transport protocol, and port number) It is recommended that instances use the same port number for UDP and TCP — The Instance ID shall be chosen so that it is guaranteed to be unique in the local network (in combination with the Service ID) — The Service Instance IDs of 0x0000 and 0xFFFF shall not be used for a service, since 0x0000 is reserved and 0xFFFF is used to describe all service instances © ISO 2014 – 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, 05/13/2014 23:04:42 MDT 33 ISO 17215-2:2014(E) — If a service instance uses UDP port x, exactly this instance should use exactly TCP port x for its services Possibilities to obtain unique Instance IDs include computing them from the unique IP address directly, or using a lookup table mapping IP addresses to Instance IDs This table has to be flashed into the camera but it can support multiple instances per IP address To avoid confusion, the following paragraphs highlight some of the differences between the ClientID and the InstanceID fields The Client ID is configured by the ECU manufacturer It is unique within each ECU (independent of the Service ID) and used in every SOME/IP header Its purpose is to allow SOME/IP to relay incoming PDUs to the correct process, as the socket information has been stripped away by AUTOSAR at this point The Instance ID is configured by the OEM In combination with the Service ID, it is unique within the vehicle and it is used in SOME/IP-SD messages only It is needed for SOME/IP-SD to differentiate between multiple instances of the same service 8.2.4 Subscription handling If a client wishes to subscribe to an Eventgroup, it shall send a SubscribeEventgroup message to the server offering the Eventgroup — Upon receiving a subscription message, the server shall reply with a SubscribeEventgroupAck if it accepts the subscription — Upon receiving a subscription message, the server shall reply with a SubscribeEventgroupNack if it does not accept the subscription, e.g because the eventgroup is not available or resources are exhausted — Upon receiving a subscription message, the server offering the notifications shall send “initial value” notifications for all relevant events — If a client wishes to subscribe to an Eventgroup but does not know which servers offer it, it shall send a FindService message — A server shall stop the publishing of notifications by sending a StopOfferService message for the corresponding Eventgroup — A client shall unsubscribe from a notification by sending a StopSubscribe message for the corresponding Eventgroup — The SOME/IP-SD on the server shall cancel the subscription if a relevant SOME/IP error is received after sending a notification — If the server loses its Ethernet link, it shall delete all the registered subscriptions — If the Ethernet link of the server comes up again, it shall trigger a SOME/IP-SD OfferService message — A link-up event on the clients Ethernet link shall trigger a SOME/IP-SD SubscribeEventgroup message An example sequence chart can be seen in Figure 19 34 Copyright International Organization for Standardization Provided by IHS under license with ISO No reproduction or networking permitted without license from IHS © ISO 2014 – All rights reserved Licensee=University of Alberta/5966844001, User=sharabiani, shahramfs Not for Resale, 05/13/2014 23:04:42 MDT `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - — If the notification client does not receive the expected notification message for a certain time, it shall send out a new SubscribeEventgroup to the server This timeout is to be specified in the interface definition for each eventgroup ISO 17215-2:2014(E) `,,```,`,`,`,`,,,````,`,,,-`-`,,`,,`,`,,` - Figure 19 — Notification subscription 8.2.5 Endpoint handling This section describes how the endpoints encoded in the endpoint and multicast options shall be set and used The service discovery shall overwrite IP addresses and port numbers with those transported in endpoint and multicast options if the statically configured values are different from those in these options 8.2.5.1 Service endpoints — Offer service entries shall reference up to one UDP endpoint option and up to one TCP endpoint option Both shall be of the same version Internet Protocol (IPv4 or IPv6) — The referenced endpoint options of the offer service entries denote the IP address and port numbers the service instance can be reached at the server — The referenced endpoint options of the offer service entries also denote the IP address and port numbers the service instance sends the events from Events of this service instance shall be sent only from this IP address and ports — If an ECU offers multiple service instances, SOME/IP messages of these service instances shall be differentiated by the information transported in the endpoint options referenced by the offer service entries Therefore, transporting an Instance ID in the SOME/IP header is not required 8.2.5.2 Eventgroup endpoints © ISO 2014 – 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, 05/13/2014 23:04:42 MDT 35 ISO 17215-2:2014(E) — Subscribe Eventgroup entries shall reference up to one UDP endpoint option and up to one TCP endpoint option for the Internet Protocol used (IPv4 or IPv6) — The endpoint options referenced in the subscribe eventgroup entries is used to send unicast UDP or TCP SOME/IP events for this service instance to, i.e the IP address and the port numbers on the client side — TCP events are transported using the TCP connection the client has opened to the server before sending the Subscribe Eventgroup entry — The initial events shall be transported using unicast from server to client — Subscribe Eventgroup Ack entries shall reference up to one multicast option for the Internet Protocol used (IPv4 or IPv6) — The multicast option shall be set to UDP as transport protocol If the server has to send multicast events very shortly (