Service Discovery (Sd)

Initializes the Service Discovery.

Indication of a received PDU from a lower layer communication interface module.

This callout is invoked to determine whether the configuration options contained in a received SD message match the ones configured in the local SD configuration (i.e., SdServerCapability Record or SdClientCapabilityRecord).

Notification about a SoAd socket connection state change, e.g. socket connection gets online

Starts a preconfigured SdServiceGroup. For example, OfferService entries will be sent out after the call of Sd_ServiceGroupStart() for all ServerServives of a SdServiceGroup, which are not requested yet.

Update Service ACL SdClientServiceAllowedProviders or SdServerServiceAllowedConsumers depending on Client or Server service by adding or removing this IP address. Tags: atp.Status=draft

Callback function, which will be provided to SoAd to be able to trigger the ACL policy check or explicitly grant access on the received Method call request Tags: atp.Status=draft

Enabling or Disabling ACL policy check for all service instance

This type defines the Server states that are reported to the SD using the expected API Sd_Server ServiceSetState.

This type defines the Client states that are reported to the BswM using the expected API Sd_Client ServiceSetState.

This type defines the subscription policy by consumed EventGroup for the Client Service.

This type defines the modes to indicate the current mode request of a Client Service.

This type defines the subscription policy by consumed EventGroup for the Client Service.

This type defines the subscription policy by EventHandler for the Server Service.

Configuration data structure of Sd module.

Type for a zero-terminated string of configuration options.

The AUTOSAR ServiceDiscovery module's SdServiceGroup object identifier.

After initialization of the Service Discovery module by the call of the API Sd_Init(), all configured Server Service Instances shall have the state "SD_ SERVER_SERVICE_DOWN", unless a Server Service Instance has SdServerService AutoAvailable set to true, then the state shall be set to "SD_SERVER_SERVICE_ AVAILABLE".

The Service Discovery module shall be able to reference Routing Group(s) per Service Instance/Eventgroup. See the following configuration parame- ters: • SdClientServiceActivationRef (in SdConsumedMethods) • SdConsumedEventGroupMulticastActivationRef • SdConsumedEventGroupTcpActivationRef • SdConsumedEventGroupUdpActivationRef • SdServerServiceActivationRef (in SdProvidedMethods) • SdEventActivationRef (in SdEventHandlerMulticast) • SdEventActivationRef (in SdEventHandlerTcp) • SdEventTriggeringRef (in SdEventHandlerTcp) • SdEventActivationRef (in SdEventHandlerUdp) • SdEventTriggeringRef (in SdEventHandlerUdp)

The Service Discovery module shall only call SoAd_IfTransmit() if an IP address is assigned; i.e.: Sd_LocalIpAddrAssignmentChg() has been called with the current state TCPIP_IPADDR_STATE_ASSIGNED.

Production errors shall be reported to Diagnostic Event Manager.

Module Header File Imported Type ComStack_Types.h PduIdType ComStack_Types.h PduInfoType ComStack_Types ComStack_Types.h PduLengthType Rte_Dem_Type.h Dem_EventIdType Dem Rte_Dem_Type.h Dem_EventStatusType SoAd.h SoAd_RoutingGroupIdType SoAd.h SoAd_SoConIdType SoAd SoAd.h SoAd_SoConModeType Std_Types.h Std_ReturnType Std Std_Types.h Std_VersionInfoType TcpIp.h TcpIp_DomainType TcpIp.h TcpIp_IpAddrAssignmentType TcpIp.h TcpIp_IpAddrStateType TcpIp TcpIp.h TcpIp_SockAddrType

The Sd_Init function shall initialize the state machines for all Ser- vice Instances according to SWS_SD_00020 and SWS_SD_00021.

The Sd_Init function shall internally store the configuration data address to enable subsequent API calls to access the configuration data.

The Sd_Init function shall remember internally the successful ini- tialization for other API functions to check for proper module initialization.

Dem_SetEventStatus Dem.h Called by SW-Cs or BSW modules to report monitor status information to the Dem. BSW modules calling Dem_SetEventStatus can safely ignore the return value. This API will be available only if ({Dem/Dem ConfigSet/DemEventParameter/DemEvent ReportingType} == STANDARD_REPORTING) SoAd_DisableSpecificRouting SoAd.h Disables routing of a group of PDUs in the SoAd related to the RoutingGroup specified by parameter id only on the socket connection identified by SoCon Id. SoAd_EnableSpecificRouting SoAd.h Enables routing of a group of PDUs in the SoAd related to the RoutingGroup specified by parameter id only on the socket connection identified by SoCon Id. SoAd_GetLocalAddr SoAd.h Retrieves the local address (IP address and port) actually used for the SoAd socket connection specified by SoConId, the netmask and default router SoAd_GetPhysAddr SoAd.h Retrieves the physical source address of the EthIf controller used by the SoAd socket connection specified by SoConId. SoAd_GetRemoteAddr SoAd.h Retrieves the remote address (IP address and port) actually used for the SoAd socket connection specified by SoConId SoAd_GetSoConMode SoAd.h Returns current state of the socket connection specified by SoConId. SoAd_IfSpecificRoutingGroupTransmit SoAd.h Triggers the transmission of all If-TxPDUs identified by the parameter id on the socket connection specified by SoConId after requesting the data from the related upper layer. SoAd_IfTransmit SoAd.h Requests transmission of a PDU. SoAd_ReleaseRemoteAddr SoAd.h By this API service the remote address (IP address and port) of the specified socket connection shall be released, i.e. set back to the configured remote address setting. SoAd_SetRemoteAddr SoAd.h By this API service the remote address (IP address and port) of the specified socket connection shall be set.

The Service Discovery module shall support tool based configura- tion.

The configuration tool shall check the consistency of the configu- ration parameters at system configuration time.

The option format shall contain the following fields in the following order and sizes:  Length [16 bits]  Type [8 bits]  Reserved [8 bits]  Zero - t erminated Configuration String (format e.g. for two configuration items [len]id=value[len]id=value[0])

The Length field shall carry the total number of bytes occupied by the configuration option, excludin g the 16 bit Length field and the 8 bit type flag.

The Type field of the Configuration Option field shall be statically set to 0x01.

The Reserved field of the Configuration Option field shall be statically set to 0 x00.

T he Length field [16 bits] of the IPv6 Endpoint Option shall be set to 0x0015.

Eventgroups entries include: • SubscribeEventgroup and StopSubscribeEventgroup • SubscribeEventgroupAck and SubscribeEventgroupNack

All Eventgroup entries shall use the Entry Format Type 2.

Eventgroup entries shall set the Eventgroup ID to the ID of the Eventgroup (configuration parameters SdConsumedEventGroupId and SdEventHan- dlerEventGroupId).

The Configuration String shall be constructed as follows from the SdServerCapabilityRecord and SdClientCapabilityRecord (Eventgroups of Services with ID 0xFFFE shall include the Services CapabilityRecord): • For every SdServerCapabilityRecordKey/ SdServerCapabilityRecordValue or Sd ClientServiceCapabilityRecordKey/ SdClientServiceCapabilityRecordValue pair: – A config_item_string is constructed of the concatenation of key, "=", and value. – The length of this config_item_string is written as uint8 to the configuration string. – The config_item_string is appended to the configuration string. • Append a 0x00 uint8 at the end. This means no further config_item_string fol- lows.

Non - SOME/IP - Services exist, that are not iden tified by a unique 16 Bit Service ID but a unique value of the key otherserv . These services use the Service ID 0xFFFE and must always carry a configuration option with an otherserv record. ECUs receiving an entry with Service ID 0xFFFE shall use the confi guration option and the otherserv record within in order to identify the relevant Service or Eventgroup configuration item.

All entries concerning Services (FindService, OfferService, StopOfferService ) shall be of Entry Format Type 1.

An Instance ID of 0xFFFF shall mean any possible instances and are not allowed for OfferService and StopOfferService entries.

FindService entries shall carry Service ID, Service Instance ID, Major Version, and Minor Version as configured in SdClientServiceID, SdClientService InstanceID, SdClientServiceMajorVersion, and SdClientServiceMinorVersion.

FindService entries shall carry the TTL as configured in SdClient TimerTTL.

OfferService entries shall carry the TTL as configured in SdServer TimerTTL.

E ventgroup entries shall set the Reserved fields to 0x00 and 0x000 .

SubscribeEventgroup, and StopSubscribeEventgroup entries shall set the Service IDs, Service Instance IDs, and Eventgroup IDs based on the config- uration (configuration parameters SdClientServiceId and SdClientServiceInstanceId).

SubscribeEventgroup entries shall have the TTL field set to the configured value (configuration parameter SdClientTimerTTL of SdConsumedEvent Group) and the SubscribeEventgroupAck entry shall use the TTL value of the Sub- scribeEventgroup entry it acknowledges.

A StopSubscribeEventgroup (type 0x06), and SubscribeEventgr oupNack (type 0x07) entry shall set the TTL field to 0x 000000 .

Eventgroup entries shall carry the options as configured.

A Stop SubscribeEventgroup entry shall set the type to 0x06.

A SubscribeEventgroupAck entry shall set the type to 0x07.

A SubscribeEventgroup Ack entry shall set the TTL field to the value of the SubscribeEventgrou p entry , it acknowledges .

A SubscribeEventgroupNack entry shall set the type to 0x07.

If a FindService Entry is received within the Initial Wait Phase for this Server Service Instance, it shall be ignored.

If the Service Di scovery Module receives a Find Service Entry , the following step(s) shall be performed in the following order: - S end an “ OfferService Entry ” considering the appropriate delay (see chapter 7.5.3 ) without chan g ing the current counter value and without influencing the current running repetition timer.

If the following conditions apply, the Initial Wait Phase for this con- figured Client Service Instance shall be entered: • Sd_Init() has been called. • SdClientService was set to state SD_CLIENT_SERVICE_REQUESTED (indi- cated by a call of Sd_ClientServiceSetState() or Sd_ServiceGroupStart() or Sd ClientServiceAutoRequired = TRUE) • Sd_LocalIpAddrAssignmentChg() with state "TCPIP_IPADDR_STATE_AS- SIGNED" has been called for the first IpAddrId associated with the SdInstance TxPdu.

If an OfferService Entry for this Client Service Instance is received within the Initial Wait Phase, • The calculated random timer, which has been started when entering the Initial Wait Phase, shall be canceled. • If received TTL is not equal to the max value, set the TTL timer for this entry to the received TTL value. • Open TCP connection if SdClientServiceTcpRef is configured and was not opened before. • Leave the Initial Wait Phase Enter the Main Phase.

When the calculated random timer based on the parameters Sd ClientTimerInitialFindDelayMin and SdClientTimerInitialFindDelayMax expires (i.e. no OfferService has been received within this timespan), the following shall be done in the following order: • FindService Entry shall be sent. • If the SdClientTimerInitialFindRepetitionsMax>0, enter the Repetition Phase • If the SdClientTimerInitialFindRepetitionsMax=0, enter the Main Phase

If the API Sd_Init() is called while being in Initial Wait Phase, the Down Phase shall be entered.

If a SdClientService it set to state SD_CLIENT_SERVICE_RE- LEASED (by call of Sd_ClientServiceSetState() or Sd_ServiceGroupStop()) while be- ing in Initial Wait Phase, this phase shall be left and the Service shall enter Down Phase.

If Sd_LocalIpAddrAssignmentChg() is called with a state other than "TCPIP_IPADDR_STATE_ASSIGNED" while being in Initial Wait Phase, the Down Phase shall be entered.

When the Repetition Phase is entered, the Service Discovery Mod- ule shall start the timer SdClientTimerInitialFindRepetitionsBaseDelay

If the Service Discovery Module receives an OfferService Entry while the current state SD_CLIENT_SERVICE_REQUESTED is for this Client Service Instance, the following step(s) shall be performed in the following order: • Cancel the repetition timer. • If received TTL is not equal to the max value, set the TTL timer for this entry to the received TTL value. • Open TCP connection if SdClientServiceTcpRef is configured and was not opened before. • Leave the Repetition Phase immediately and enter the Main Phase. • Handle subscription as described in [SWS_Sd_00376] and [SWS_Sd_00721] in the same offer cycle

If the Service Discovery Module receives a StopOfferService Entry, the following step(s) shall be performed in the following order: • Stop the TTL timers of this Client Service Instance and all related Consumed Eventgroups. • Report this Client Service as DOWN if it was reported AVAILABLE before (call BswM_Sd_ClientServiceCurrentState with SD_CLIENT_SERVICE_DOWN and the Client Service's handle ID). • Report all Consumed Eventgroups as DOWN that were reported AVAILABLE be- fore (call BswM_Sd_ConsumedEventGroupCurrentState with SD_CONSUMED_ EVENTGROUP_DOWN and the Consumed Eventgroup's handle ID). • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, cancel the corresponding client service subscription retry delay timer and reset subscription retry counter of all corresponding Event- groups to 0. • Close all Socket Connections associated with this Client Service Instance that have been opened before. • Stay in Main Phase and do not send FindService entries.

After sending the maximum amount of repetitions (defined by SdClientTimerInitialFindRepetitionsMax) of FindService entries, the Repetition Phase shall be left and the Main Phase shall be entered.

If SdClientService it set to state SD_CLIENT_SERVICE_RE- LEASED (by call of Sd_ClientServiceSetState() or Sd_ServiceGroupStop()) while be- ing in Repetition Phase, this phase shall be left and the service instance shall enter Down Phase.

If Sd_LocalIpAddrAssignmentChg() is called with a state other than "TCPIP_IPADDR_STATE_ASSIGNED" while being in Repetition Phase the Down Phase shall be entered.

If the Service Discovery Module receives an OfferService Entry, the following step(s) shall be performed in the following order: • If received TTL is not equal to the max value, update the timer by the received TTL value. • Open TCP connection if SdClientServiceTcpRef is configured and was not opened before. • For each currently requested Consumed Eventgroup of this Client Service In- stance (Consumed Eventgroups are requested using Sd_ConsumedEventGroup SetState and with state SD_CONSUMED_EVENTGROUP_REQUESTED or au- tomatically on startup if SdConsumedEventGroupAutoRequire is configured to true), the following shall be done in exactly this order: – StopSubscribeEventgroup entry shall be sent out, if the last SubscribeEvent- group entry was sent as reaction to an OfferService entry received via Multi- cast, it was never answered with a SubscribeEventgroupAck, and the current OfferService entry was received via Multicast. – A SubscribeEventgroup entry shall be sent out. • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, the Eventgroup subscription retry counter shall be reset to 1.

The Service Discovery Module shall leave the Main Phase and enter the state SD_CLIENT_SERVICE_DOWN if at least one of the listed conditions described in SWS_SD_00375 does not apply any more.

If a SdClientService is set to state "SD_CLIENT_SERVICE_RE- LEASED" (indicated by a call of Sd_ClientServiceSetState() or Sd_ServiceGroup Stop()) while all other conditions listed in SWS_SD_00375 still apply, the Service Dis- covery module shall perform the following steps: • Enter the Down Phase and indicate the state SD_CLIENT_SERVICE_DOWN to the BswM by calling the API BswM_Sd_ClientServiceCurrentState (). • For all subscribed eventgroups of this Client Service, – a StopSubscribeEventgroup shall be sent – the status shall be set to SD_CONSUMED_EVENTGROUP_DOWN and re- ported to BswM by calling the API BswM_Sd_ConsumedEventGroupCurrent State(). • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, cancel the corresponding client service subscription retry delay timer and reset subscription retry counter of all corresponding Event- groups to 0.

When the Main Phase is left, • The API SoAd_DisableSpecificRouting()shall be called for all Socket Connections associated with this Client Service ID that have been opened before. • Close all Socket Connections associated with this Client Service Instance that have been opened before.

The Type field of the Type 2 Entry format layout shall carry one of the following values, depending o n the purpose of the messa ge sent :  0x06 to encode SubscribeEventgroup and StopSubscribeEventgroup  0x07 to encode SubscribeEventgroupAck and SubscribeEventgroupNack

The “Index First Option Run” field of the Type 2 Entry format layout shall carry the index of the first option of the first option run of this entry in the option array .

The “Number of Option 1” field of the Type 2 Entry format layout shall have a fixed size of 4 bits.

The TTL shall be set to 0x000000.

When the calculated random timer expires and the parameter SdServerTimerInitialOfferRepetition s Max does not equals ‘0’, the Repetition Phase shall be entered.

When the calcula ted random timer expires and the parameter SdServerTimerInitialOfferRepetition s Max equal ‘0’, the Main Phase shall be entered.

After initialization of the Service Discovery module by calling of the API Sd_Init(), all configured Eventgroups shall have the state "SD_CONSUMED_ EVENTGROUP_ RELEASED", unless a Consumed Eventgroup has "SdConsumed EventGroupAutoRequired" set to true, then the state shall be set to "SD_CONSUMED_ EVENTGROUP_REQUESTED" as soon as the associated Client Service Instance is requested.

If Sd_ConsumedEventGroupSetState is called with SD_CON- SUMED_EVENTGROUP_REQUESTED while its Client Service Instance is still re- leased (SD_CLIENT_SERVICE_RELEASED) E_NO_OK shall be returned.

If a SdClientService is set to SD_CLIENT_SERVICE_RELEASED (via Sd_ClientServiceSetState() or Sd_ServiceGroupStop()) while one or more of its Eventgroups are still requested (SD_CONSUMED_EVENTGROUP_REQUESTED) the Service Discovery shall interpret this the same way as these Eventgroups were called with SD_CONSUMED_EVENTGROUP_RELEASED first.

The Service Discovery shall keep track of the last received of a communication partner Session ID value and Reboot Flag value independently for unicast and multicast. This means that the communication partners values rec eived over multicast shall not be updated by a unicast message.

A reboot of the communication partner shall be detected based on consecutive Service Discovery messages (for communication partner; unicast and multicast separated) in the following two ways :  Reboot Flag change s from ‘0’ to ‘1’ or  Session ID does not increase, while Reboot Flag stays ‘1’ .

The Service Discovery may also detect reboots based on the unicast information.

A reboot detected with Session ID and Reboot Flag shall lead to expiration of the local state that is controlled by this communication partner. In case of a reboot of a server, of which the client uses a service, the client shall handle the reboot as if a Stop Offer entry was received (see also SWS_SD_00367 for further details) In case of a reboot of a server, of which the client uses a service, the server shall handle the reboot as if a StopSubscribeEventgroup entry was received (see also SWS_ SD_00345 for further details).

The number of subscribed clients with different endpoint informa- tion shall be used to control when to enable/disable Consumed Eventgroup unicast or Consumed Eventgroup multicast connention, or when to enable/disable Evenhandler Multicast connection by calling SoAd_EnableSpecificRouting and SoAd_DisableSpeci- ficRouting: • If SdEventHandlerMulticastThreshhold = 0: Setup a Consumed Eventgroup uni- cast connection or a Consumed Eventgroup multicast connection connection to every subscribed client (please note: Eventhandler Multicast connection is al- ways disabled). • If SdEventHandlerMulticastThreshhold = 1: Setup a Eventhandler Multicast con- nection if one or more clients are subscribed (please note: Consumed Event- group unicast connections and Consumed Eventgroup multicast connections are always disabled). • If SdEventHandlerMulticastThreshhold > 1: – Setup a Consumed Evengroup unicast connection or a Consumed Event- group multicast connection for all subscribed clients if the number of sub- scribed clients with different endpoint information < SdEventHandlerMulti- castThreshhold, – else setup a Eventhandler Multicast connection and switch automatically based on the number of subscribed clients with different endpoint informa- tion:  If the number of subscribed clients with different endpoint information is larger or equal than the threshold, then the Eventhandler multicast connection shall be used for transmission.  If the number of subscribed clients with different endpoint information is smaller than the threshold, the individual Consumed Eventgroup unicast connections and Consumed Eventgroup multicast connections shall be used for transmission.

If for any reasons the Initial Wait Phase is left, the calculated ran- dom timer (of the Initial Wait Phase) for this Service Instance shall be stopped.

When the timer SdClientTimerInitialFindRepetitionsBaseDelay ex- pires within the Repetition Phase, a FindOffer Message shall be sent.

For all SD messages sent and received via the Socket Adaptor module, the header mode shall be activated.

For all SD messages sent and received via the Socket Adap- tor module, the SoAdTxPduHeaderId and the SoAdRxPduHeaderId shall be set to 0xFFFF8100 respectively by Socket Adaptor.

SdServerCapabilityRecordValue and SdClientServiceCapability RecordValue are allowed to be empty. This means that after "=" the next length uint8 or "0" follows.

As long as a service is not requested by the BswM, the Service Discovery shall not send FindService Entry entries.

If an OfferService Entry is received during Down Phase, • The Service Discovery shall store the state of this Service instance. • A timer shall be set/reset to the TTL value of the received OfferService entry (TTL timer). • Until the TTL Timer expires or a StopOfferService entry is received, the Service instance is considered Available.

If a SdClientService is set to state SD_CLIENT_SERVICE_RE- QUESTED (by call of Sd_ClientServiceSetState() or Sd_ServiceGroupStart()) while being in Down Phase: • If no OfferService entry was received before or its TTL timer expired already: – The Initial Wait Phase shall be entered, • If an OfferService entry was received and its TTL timer did not expire yet: – If SoAd_OpenSoCon() was not called before, the API SoAd_OpenSoCon() shall be called for all Socket Connections associated with this Client Service Instance. – The API SoAd_EnableSpecificRouting() shall be called with SdClientService ActivationRef (see SdConsumedMethods) and the relevant Socket Connec- tions for this Client Service Instance. – Open TCP connection if SdClientServiceTcpRef is configured and was not opened before. – The Main Phase shall be entered.

Receiving a config_item_string without an "=" sign shall be inter- preted as key present without value.

Multiple config_item_string with the same key in a single configu- ration option shall be supported.

If SdInstanceHostname exists, a key "hostname" with the value set to the string of this configuration item shall be added to the Configuration Option.

If development error detection is enabled and the Service Dis- covery module has not been initialized using Sd_Init(), the Sd_RxIndication function shall raise the development error code SD_E_UNINIT and the Sd_RxIndication func- tion shall return without further action.

If RxPduId has an undefined value, the Service Discovery module shall discard the message and return without further action. In case development error detection is enabled, the Service Discovery module shall additionally raise the development error code SD_E_INV_ID.

Every wildcard socket connection shall be reset to wildcard using SoAd_ReleaseRemoteAddr() if all of the following conditions apply: • The remote address of a socket connection has been set by SD. • The socket connection is not used by a ClientService anymore. I.e. no Offer was received, a Stop Offer was received or the TTL has expired. • The socket connection is not used by an Eventhandler anymore. I.e. the client has unsubscribed all Eventgroups using this socket connection. The socket con- nection shall not be reset if the routings get disabled because the SdEventHan- dlerMulticastThreshold was reached.

When a OfferService for a required Client Service is received and SoAd_OpenSoCon()was not called before, the API SoAd_OpenSoCon() shall be called for all Socket Connections associated with this Client Service Instance.

If either the received Type 1 SD entry references a configuration option or a service match candidate has capability records configured (i.e., SdServer CapabilityRecord in case of a received FindService entry or SdClientCapabilityRecord in case of a OfferService or a StopOfferService entry), the configured SdCapability RecordMatchCallout shall be invoked by the SD implementation.

A received Type 2 SD entry with Service ID 0xFFFE (Non- SOMEIP) shall be matched accordingly to SWS_SD_00716 with the capability records of the Service (SdServerCapabilityRecord in case of a received SubscribeEventgroup or StopSubscribeEventgroup entry or SdClientCapabilityRecord in case of Subscribe EventgroupAck or SubscribeEventgroupNack entry).

If the invoked SdCapabilityRecordMatchCallout returns true, the respective service instance match candidate actually provides a match for the received SD message including the configured capability records.

If the invoked SdCapabilityRecordMatchCallout returns false, the respective service instance match candidate actually does not provide a match for the received SD message due to the mismatch with respect to the configured capability records.

If SdSubscribeEventgroupRetryEnable is set to TRUE and SdSub- scribeEventgroupRetryMax is set to a value greater than 0, every time a Consumed Eventgroup transit to the state SD_CONSUMED_EVENTGROUP_REQUESTED, the following actions shall be done: • the corresponding client service subscription retry delay timer shall be started and set to SdSubscribeEventgroupRetryDelay, if the timer is not already running • the Eventgroup subscription retry counter shall be initialized with 1

If SdSubscribeEventgroupRetryEnable is set to TRUE and Sub- scribeEventgroupRetryMax is set to 0xFF, the retries of subscription shall continue as long as all of the following conditions are fulfilled: • the corresponding Eventgroup is set to "SD_CONSUMED_EVENTGROUP_RE- QUESTED" • no SubscribeEventGroupAck or no SubscribeEventGroupNack was received

If a Consumed Eventgroup switches to the state SD_CON- SUMED_EVENTGROUP_REQUESTED while the corresponding state of the re- quested Service Instance was already set to SD_CLIENT_SERVICE_AVAILABLE (due to an already received Offer Service with TTL 0xFFFFFF), a SubscribeEventgroup entry shall be sent out only if all of the following conditions apply: • SdSubscribeEventgroupRetryEnable is set to TRUE, • SdSubscribeEventgroupRetryMax is greater 0,

Type of error Related error code Error value Retry was not successful SD_E_COUNT_OF_RETRY_SUBSCRIPTION_ EXCEEDED 0x06

A SdClientService and SdServerService, respectively, is re- quested and available, respectively, if at least one SdServiceGroup is started it refers to.

The state of a SdClientService and a SdServerService, respec- tively, which refer to at least one SdServiceGroup shall only be changed via Sd_ ServiceGroupStart and Sd_ServiceGroupStop, respectively. The state of a SdClient Service and SdServerService, respectively, which do NOT reference any SdService Group, shall only be changed via Sd_ClientServiceSetState() and Sd_ServerService SetState(), respectively.

The AUTOSAR ServiceDiscovery module shall keep track of re- quests and availabilities per SdClientServiceS and SdServerServiceS, respectively, which reference at least one SdServiceGroup. Therefore each affected SdClientSer- vice and SdServerService shall have a client request counter and server availability counter, respectively. Each time Sd_ServiceGroupStart() is called, the client request counter shall be incremented for all affected SdClientServices and the server avail- ability counter shall be incremented for all affected SdServerServices. Each time Sd_ ServiceGroupStop() is called the client request counter shall be decremented for all affected SdClientServices, and the server availability counter shall be decremented for all affected SdServerServices.

By default, all SdServiceGroupS shall be in the state stopped and they shall not be started automatically by a call to Sd_Init.

If an SdServiceGroup is started by Sd_ServiceGroupStart(), the AUTOSAR Service Discovery module shall set all SdClientServiceS which are ref- erencing the affected SdServiceGroup to SD_CLIENT_SERVICE_REQUESTED and all SdServerServiceS which are referencing the affected SdServiceGroup to SD_ SERVER_SERVICE_AVAILABLE.

If an SdServiceGroup is stopped by Sd_ServiceGroupStop(), the AUTOSAR Service Discovery module shall set all SdClientServiceS, which are ref- erencing the affected SdServiceGroup to SD_CLIENT_SERVICE_RELEASED where the corresponding client request counter (see SWS_SD_00747) has reached 0, and all SdServerServices which are referencing the affected SdServiceGroup to SD_ SERVER_SERVICE_DOWN where the corresponding server availability counter (see SWS_SD_00747) has reached 0.

The Service Discovery module shall ignore all received service entries of a Client Service, where the minor version of the received entry is specified within a version blacklist of the corresponding SdClientService (see SdBlacklistedVersions).

If SdVersionDrivenFindBehavior is set to MINIMUM_MINOR_VER- SION, the Minor Version in a received OfferService or StopOfferService shall be checked for identifying Service Instances and its associated Eventgroups. The Service Discovery module shall process a OfferServices or StopOfferServices where the minor version of the received entry are equal or greater than the configured minor version of the corresponding SdClientService.

If a service match candidate is detected for a ClientService where SdVersionDrivenFindBehavior is set to MINIMUM_MINOR_VERSION and the ClientService has already triggered a subsription to another ServerService, the Service Discovery module shall silently discard this service match candidate.

If SdVersionDrivenFindBehavior is set to MINIMUM_MINOR_VER- SION the following points shall be considered by the Service Discovery module: • the Minor Version shall be set to the minimum acceptable required minor version in the configuration • Service Discovery shall use 0xFFFF FFFF (ANY) for the FindService entry, which means that services with any minor version shall will be returned

The code file structure shall not be defined within this specification completely. At this point it shall be pointed out that the code-file structure shall include the following files named: • Sd_Lcfg.c - for link time configurable parameters and • Sd_PBcfg.c - for post build time configurable parameters. These files shall contain all link time and post-build time configurable parameters.

The module shall include the Dem.h file. By this inclusion, the APIs to report errors as well as the required Event Id symbols are included.

The Service Discovery shall implement a main function, which shall be called cyclically according to configuration parameter SdMainFunctionCycle Time.

The Service Discovery module shall store the ServiceModeRe- quest, which is provided via the BswM by calling the following APIs: • Sd_ServerServiceSetState() and Sd_ClientServiceSetState(), respectively, If the SdServerService and SdClientSerivce, respectively, is NOT referencing a SdSer- viceGroup • Sd_ServiceGroupStart and SdServiceGroupStop, if the SdServerService and Sd ClientService, respectively is referencing a SdServiceGroup • Sd_ConsumedEventGroupSetState(), if dedicated SdEventGroupS are re- quested by a SdClientService. ( Note: This API call is allowed independ of a reference to a SdServiceGroup of a SdClientService ) • Sd_EventHandlerSetState() does currently not exist, since this state is directly deduced from the state of a Server Service by the Service Discovery.

The following CurrentStates shall be available for reporting to Bsw M module via BswM_Sd_ClientServiceCurrentState(), BswM_Sd_ConsumedEvent GroupCurrentState(), and BswM_Sd_EventHandlerCurrentState() respectively: - SD_CLIENT_SERVICE_DOWN - SD_CLIENT_SERVICE_AVAILABLE - SD_CONSUMED_EVENTGROUP_DOWN - SD_CONSUMED_EVENTGROUP_AVAILABLE - SD_EVENT_HANDLER_RELEASED - SD_EVENT_HANDLER_REQUESTED

Every configured Server Service Instance shall have an ECU wide, unique SdServerServiceHandleId.

Every Service Discovery Configuration Instance (see configuration container SdInstance) shall have at least one TxPdu ID, one RxPdu ID for Unicast, and one RxPdu ID for Multicast (see configuration parameter SdInstanceTxPdu, Sd InstanceUnicastRxPdu, and SdInstanceMulticastRxPdu respectively).

For different links, separate Service Discovery instance containers shall be configured.

The Service Discovery module shall store the status of all statically configured Service Instances and Eventgroups separately.

After initialization of the Service Discovery module by calling of the API Sd_Init(), all configured Client Service Instances shall have the state "SD_ CLIENT_SERVICE_RELEASED", unless a Client Service Instance has SdClientSer- viceAutoRequired set to true, then the state shall be set to "SD_CLIENT_SERVICE_ REQUESTED".

The Service Discovery module shall be able to enable/disable rout- ing groups within the SoAd module using the APIs SoAd_EnableRouting(), SoAd_Dis- ableRouting(), SoAd_EnableSpecificRouting(), and SoAd_DisableSpecificRouting() for Server- and Client Service Instances.

After initialization of the Service Discovery Module, the Session ID for messages sent by the local ECU shall be 0x0001.

If not defined otherwise, all fields in the Service Discovery mes- sages shall be in Network Byte Order (i.e. Big Endian Byte Order).

The Service Discovery module sends Service Discovery mes- sages (Offer, StopOffer, Find,.. ) using the SoAd_IfTransmit() API carrying the ref- erenced TxPdu (see configuration parameter SdInstanceTxPdu).

The Service Discovery module receives Service Discovery mes- sages via the API Sd_SoAdIfRxIndication() and the configuration items SdInstance UnicastRxPdu and SdInstanceMulticastRxPdu. The received remote address must be saved in the call context of the Sd_RxIndication.

The Sd_GetVersionInfo function shall return the version informa- tion of this module. The version information includes: - Module Id - Vendor Id - Vendor specific version numbers

The Service ID field of the Type 1 Entry format layout shall carry the Service ID of the service, statically configured using the parameter SdServerServiceID and SdClientServiceID, depending on being a server or client entry.

The Instance ID field of the Type 1 Entry format layout shall carry the Instance ID of the service, statically configured using the parameter SdServerSer- viceInstanceID and SdClientServiceInstanceID, depending on being a server or client entry.

The Major Version field of the Type 1 Entry format layout shall carry the SdServerServiceMajorVersion and SdClientServiceMajorVersion, depending on being a server or client entry.

The TTL field of the Type 1 Entry format layout defines the lifetime of the entry in seconds configured using the parameter SdServerTimerTTL and Sd ClientTimerTTL, except for Stop-Entries, which have a TTL of 0.

The Minor Version field of the Type 1 Entry format layout shall carry the SdServerServiceMinorVersion and SdClientServiceMinorVersion.

The Service ID field of the Type 2 Entry format layout shall carry the Service ID of the eventgroups service, statically configured using the parameter Sd ServerServiceID and SdClientServiceID, depending on being a server or client entry.

The Instance ID field of the Type 2 Entry format layout shall carry the Instance ID of the eventgroups service statically configured using the parame- ter SdServerServiceInstanceID and SdClientServiceInstanceID, depending on being a server or client entry.

The Major Version field of the Type 2 Entry format layout shall carry the SdServerServiceMajorVersion and SdClientServiceMajorVersion, depending on being a server or client entry.

The TTL field of the Type 2 Entry format layout defines the lifetime of the entry in seconds configured using the parameter SdServerTimerTTL and Sd ClientTimerTTL, except for Stop- or Nack-Entries, which use a TTL of 0.

The Eventgroup ID field of the Type 2 Entry format layout shall carry the ID of an Eventgroup, configured using the parameter SdConsumedEvent GroupID.

All entries concerning Services (FindService, OfferService and StopOfferService shall carry - i.e. reference - the options as configured.

OfferService and StopOfferService shall carry Service ID, Service Instance ID, Major Version, Minor Version, and as configured in SdServerServiceID, Sd ServerServiceInstanceID, SdServerServiceMajorVersion, and SdServerServiceMinor Version.

If a SubscribeEventgroup Entry or StopSubscribeEventgroup Entry are received within the Initial Wait Phase (or other phases) for an Event Handler of this Server Service Instance, it shall only be processed within the Service Discovery.

This Client Service Instance shall stay in the Initial Wait Phase for a time within the configured range of SdClientTimerInitialFindDelayMin and SdClient TimerInitialFindDelayMax unless an OfferService entry for this Client Service Instance is received or this random timer expires.

In the Repetition Phase up to SdClientTimerInitialFindRepetitions Max FindServer entries shall be sent with doubling intervals (BaseDelay, first FindSer- vice Entry, 2x BaseDelay, second FindService Entry, 4x BaseDelay, third FindService Entry,... ).

It shall be possible to configure the Service Discovery module as an optional AUTOSAR BSW Module. Please refer to the SystemTemplate for configu- ration.

The Service Discovery module shall store all IP address assign- ment states referenced by server and client Service Instances.

Every configured Client Service Instance shall have an ECU wide, unique SdClientServiceHandleId.

Every configured Consumed Event Group shall have an ECU wide, unique SdConsumedEventGroupHandleId.

Every configured Event Handler shall have an ECU wide, unique SdEventHandlerHandleId.

If development error detection is enabled: The function shall check parameter PduInfoPtr for being a null pointer. In this case, the function shall raise the development error SD_E_PARAM_POINTER and return without further action.

Type 2 Entries (Entries for Eventgroups) shall not use "any values" as Service ID (i.e. 0xFFFF), Instance ID (i.e. 0xFFFF), Eventgroup ID (i.e. 0xFFFF), and/or Major Version (i.e. 0xFF).

This chapter describes how to derive all necessary data to assem- ble an OfferService Message: 1. Derive all static data from the configuration container. These are e.g: • Container SdServerService: SdServerServiceId • Container SdServerService: SdServerServiceInstanceId • Container SdServerService: SdServerServiceMajorVersion • Container SdServerService: SdServerServiceMinorVersion • Container SdServerTimer: SdServerTimerTTL • Container SdInstance: SdInstanceHostname 2. If TCP is configured for this service (configuration item SdServerServiceTcpRef exists): • The generator derives a SoConID out of the SoConGroup referenced by the configuration parameter SdServerServiceTcpRef • Call the Socket Adaptor's API SoAd_GetLocalAddr() with the derived So ConID to get back the IP Address, Transport protocol (Layer 4), and the port number needed for the Endpoint Option. • Build the relevant Endpoint Option with L4-Protocol set to TCP (shall be same as in LocalAddr) . 3. If UDP is configured for this service (configuration item SdServerServiceUdpRef exists): • The generator derives a SoConID out of the SoConGroup referenced by the configuration parameter SdServerServiceUdpRef • Call the Socket Adaptor's API SoAd_GetLocalAddr() with the derived So ConID to get back the IP Address, Transport protocol (Layer 4), and the port number needed for the Endpoint Option. • Build the relevant Endpoint Option with L4-Protocol set to TCP (shall be same as in LocalAddr) . 4. Build Configuration Option if configured (see configuration item SdServerCapa- bilityRecord and SdInstanceHostname). 5. Build OfferService Entry as described above.

When receiving Service Discovery messages the values of all re- served fields shall be ignored.

This chapter describes the interaction with the Socket Adaptor module to send Service Discovery messages: 1. Precondition: Service Discovery message is assembled 2. In case the message shall be sent via unicast: - Call the Socket Adaptor's API SoAd_SetRemoteAddr 3. In case the message shall be sent via multicast: - Call the API SoAd_SetRemoteAddr to set the destination 4. Call SoAd_IfTransmit() to send the message on the bus Please also refer to the sequence "CLIENT/SERVER: TransmitSdMessage" shown in Chapter 9.

This chapter describes the interaction with the Socket Adaptor on how Service Discovery messages are received: 1. When the SocketAdaptor receives a Service Discovery message, the API Sd_Rx Indication() is called. 2. Using the indicated RxPduId, the associated SoConId for this SD Instance has to be determined. 3. Call API SoAd_GetRemoteAddr() with this SoConId. 4. Store address and message for further processing. 5. Reset the SoCon back to Wildcard using SoAd_ReleaseRemoteAddr() 6. The entries shall be processed exactly in the order they arrived. Please also refer to the sequence "CLIENT/SERVER: Sd_RxIndication" shown in Chapter 9.

If SdClientServiceMinorVersion is set to 0xFFFFFF and SdVersion DrivenFindBehavior is set to EXACT_OR_ANY_MINOR_VERSION, the Minor Version in a received OfferService or StopOfferService entry is not checked for identifying Ser- vice Instances and its associated Eventgroups.

If SdClientServiceMinorVersion is set to any value except 0x FFFFFF and SdVersionDrivenFindBehavior is set to EXACT_OR_ANY_MINOR_VER- SION, the Minor Version in a received OfferService or StopOfferService shall be checked for identifying Service Instances and its associated Eventgroups. The Ser- vice Discovery module shall process a OfferService or StopOfferService where the minor version of the received entry match exact the configured minor version of the corresponding SdClientService.

Answers to Entries received via multicast shall be delayed based on the appropriate configuration items: • For ServerServices: – SdServerTimerRequestResponseMinDelay – SdServerTimerRequestResponseMaxDelay • For ConsumedEventgroups: – SdClientTimerRequestResponseMinDelay – SdClientTimerRequestResponseMaxDelay

The configuration parameters for delaying OfferService entries as response to FindService entries received by multicast shall be taken from the Timer containers referenced by the Service container: • SdServerService

The configuration parameters for delaying SubscribeEventgroup entries as response to OfferService entries received by multicast shall be taken from the Timer containers referenced by the Eventgroup containers: • SdConsumedEventGroup

There shall be a random delay between the appropriate MinDelay and MaxDelay before answering to an Entry received via multicast.

Delayed answering Entries received via multicast (as in SWS_ SD_00494) shall no influence other timers (e.g. for handling the Repetition Phase).

If development error detection for the Service Discovery module is enabled, then the function Sd_GetVersionInfo shall check whether the parameter VersioninfoPtr is a NULL pointer (NULL_PTR). If VersioninfoPtr is a NULL pointer, then the function Sd_GetVersionInfo shall raise the development error SD_E_PARAM_ POINTER and return.

If SdVersionDrivenFindBehavior is set to EXACT_OR_ANY_MI- NOR_VERSION, the Service Discovery shall use exact minor version for the Find- Service entry, which means services with this specific minor version shall only be re- turned.

TTL shall be set according to the configuration.

If the TTL Timer of a Client Service expires, the Service Discovery module shall perform the following steps: • Enter the Initial Wait Phase and indicate the state SD_CLIENT_SERVICE_ DOWN to the BswM by calling the API BswM_Sd_ClientServiceCurrentState (). • All subscribed Eventgroups of this Client Service shall expired in this instance (stop TTL timer) and the expiration shall be handled as describe in SWS_ SD_00601.

If the TTL Timer of an Eventgroup expires, the Service Discovery module shall perform the following step(s): • the status shall be set to SD_CONSUMED_EVENTGROUP_DOWN and re- ported to BswM by calling the API BswM_Sd_ConsumedEventGroupCurrent State().

When the Down Phase is entered (coming from states other than init), the API SoAd_CloseSoCon() shall be called for all Socket Connections associated with this Server Service Instance.

If the Load Balancing Option is used, the Priority field shall be set to the configured value of SdServerServiceLoadBalancingPriority.

If the Load Balancing Option is used, the Weight field shall be set to the configured value of SdServerServiceLoadBalancingWeight.

The amount of separate Service Discovery messages shall be re- duced, i.e.: Combine as much information as possible into one Service Discovery mes- sage before calling the Socket Adaptor's transmit API. This means that when a entry is sent after waiting the appropriate delay (i.e. based on Request-Response-Delay) all other entries for this communication partner may be packed into the Service Discovery message as well.

SubscribeEventgroup entries shall be answered with Sub- scribeEventgroupNack, if the SubscribeEventgroup entry reference two or more op- tions that are in conflict or the option type is unknown.

The Counter field in the Type 2 Entry format is used to differentiate different Subscribe Eventgroups to otherwise identical Eventgroups (i.e. same Service ID, same Instance ID, same Eventgroup ID, and same Major Version). The Counter field shall be reflected by the Server to the Subscribe Eventgroup Ack and Nack entries. If identical Consumed Eventgroups are configured with different Endpoints, then the SD shall use the Counter to differentiate the different Subscriptions. The value of the Counter can be determined by the implementation.

If a StopSubscribeEventgroup and SubscribeEventgroup for the same Eventgroup (i.e. same Service ID, Instance ID, Eventgroup ID, Counter, and Major Version) have to be sent out, these entries have to be directly after each other in the same SD message (no entry between them).

If the entries of a single Service Discovery Message would lead to closing and opening the same Socket Connection in the Socket Adaptor, the Service Discovery shall not close the Socket Connection first.

A SD Instance does only support a single Address Family (i.e. IPv4 or IPv6). This address family shall be learned by means of the SoAd configuration of SdInstanceTxPdu, SdInstanceUnicastRxPdu, and SdInstanceMulticastRxPdu (local address).

If a SubscribeEventgroup entry referencing two conflicting End- point Options (UDP or TCP) is received then a SubscribeEventgroupNack shall be generated. Endpoint options are considered conflicting if they are of the same type but hold different values, like different IP or Port number.

The Service Discovery module shall be able to trigger the sending of initial Events using the API SoAd_IfSpecificRoutingGroupTransmit().

The Service Discovery module shall be able to reference Socket Connections and SocketConnectionGroups per Service Instance/Eventgroup. See the following configuration parameters: • SdClientServiceTcpRef (Service Instance and Eventgroups) • SdClientServiceUdpRef (Service Instance and Eventgroups) • SdConsumedEventGroupMulticastGroupRef (Eventgroup) • SdServerServiceTcpRef (Service Instance and Eventgroups) • SdServerServiceUdpRef (Service Instance and Eventgroups) • SdMulticastEventSoConRef in SdEventHandlerMulticast (Eventgroup)

This requirement describes how to derive all necessary data to assemble a SubscribeEventgroup Message: 1. Derive all static data from the configuration container. These are e.g: • Container SdClientService: SdClientServiceId • Container SdClientService: SdClientServiceInstanceId • Container SdClientService: SdClientServiceMajorVersion • Container SdClientService: SdClientServiceMinorVersion • Container SdConsumedEventGroupTimerRef - SdClientTimer: SdClient TimerTTL • Container SdInstance: SdInstanceHostname 2. If TCP is configured for this service (configuration item SdClientServiceTcpRef exists): • Find the relevant SocketConnection based on the SdClientServiceTcpRef (finding SoConGroup) and the Endpoint Option of the OfferService entry (finding SoCon within). • Call the Socket Adaptor's API SoAd_GetLocalAddr() with the derived So ConID to get back the IP Address, Transport protocol (Layer 4), and the port number needed for the Endpoint Option. • Build the relevant Endpoint Option with L4-Protocol set to TCP (shall be same as in LocalAddr). 3. If UDP is configured for this service and used as Consumed Eventgroup unicast endpoint (configuration item SdClientServiceUdpRef exists): • Find the relevant SocketConnection based on the SdClientServiceUdpRef (finding SoConGroup) and the Endpoint Option of the OfferService entry (finding SoCon within). • Call the Socket Adaptor's API SoAd_GetLocalAddr() with the derived SoCon ID to get back the unicast IP Address, Transport protocol (Layer 4), and the port number needed for the Endpoint Option. • Build the relevant Endpoint Option with L4-Protocol set to UDP (shall be same as in LocalAddr). 4. If UDP is configured for this service and used as Consumed Eventgroup multicast endpoint (configuration item SdClientServiceMulticastRef exists): • Find the relevant SocketConnection based on the SdClientServiceMulticas- tRef (finding SoConGroup) and the Endpoint Option of the OfferService en- try (finding SoCon within). • Call the Socket Adaptor's API SoAd_GetLocalAddr() with the derived So- ConID to get back the multicast IP Address, Transport protocol (Layer 4), and the port number needed for the Multicast Option. • Build the relevant Multicast Option with L4-Protocol set to UDP (shall be same as in LocalAddr). 5. Build Configuration Option if configured (see configuration item SdClientCapabil- ityRecord and SdInstanceHostname). 6. Build SubscribeEventgroup Entry as described above.

If SdConsumedEventGroupTcpActivationRef is configured: When sending SubscribeEventgroup entries for this Eventgroup, the following shall be done: • The relevant Routing Group shall be identified by following SdConsumedEvent GroupTcpActivationRef. • The relevant TCP Socket Connection shall be identified by SdClientServiceTcp Ref. • A TCP Endpoint option shall be constructed with these parameters. • Only if this client is currently not subscribed yet: – SoAd_EnableSpecificRouting with the two parameters above.

If SdConsumedEventGroupUdpActivationRef is configured: When sending SubscribeEventgroup entries for this Eventgroup, the following shall be done: • The relevant Routing Group shall be identified by following SdConsumedEvent GroupUdpActivationRef. • The relevant TCP Socket Connection shall be identified by SdClientServiceUdp Ref. • A UDP Endpoint option shall be constructed with these parameters. • Only if this client is currently not subscribed yet: – SoAd_EnableSpecificRouting with the two parameters above.

If SdConsumedEventGroupMulticastActivationRef is configured: When receiving SubscribeEventgroupAck entries for this Eventgroup and with a ref- erenced Multicast Option, the following shall be done if this client is currently not sub- scribed yet: • The relevant Routing Group shall be identified by following SdConsumedEvent GroupMulticastActivationRef. • The relevant UDP Socket Connection shall be identified: – Find the relevant Socket Connection Group using SdConsumedEventGroup MulticastGroupRef with the local Address and Port of the Multicast Option or set one up. – Find the relevant Socket Connection in this Socket Connection Group by finding the Address and Port of this Services Endpoint or set one up. • SoAd_EnableSpecificRouting with the two parameters above.

Every wildcard socket connection shall be reset to wildcard using ReleaseSoAd_RemoteAddr() if all of the following conditions apply: • The remote address of the socket connection has been set by SD according to [SWS_Sd_00377]. • No Eventgroup Subscription for this socket connection is used anymore.

Every time the Service Discovery module receives a SOME/IP-SD message, the consistency of this message has to be checked. This includes but is not limited to: • Validating that the SOME/IP-SD message is long enough to fit the entries and options arrays (total length = 12 + length of entries array + length of options array). • Check that entries reference existing options. In case a malformed message has been received, the extended production error SD_ E_MALFORMED_MSG shall be reported.

Ignore, if SoAd_IfTransmit() returns E_NOT_OK.

Routing Groups of EventGroups (see SdConsumedEventGroup TcpActivationRef, SdConsumedEventGroupUdpActivationRef, and SdConsumed EventGroupMulticastActivationRef) shall be deactivated, if they are not needed anymore (Main phase was left, StopOffer received or ConsumedEventgroup was released).

If Sd_LocalIpAddrAssignmentChg() is called with a state other than "TCPIP_IPADDR_STATE_ASSIGNED" while being in Main Phase: • The Down Phase shall be entered. • "SD_CLIENT_SERVICE_DOWN" shall be indicated to the BswM module by call- ing the API BswM_Sd_ClientServiceCurrentState(), if the present state is SD_ CLIENT_SERVICE_AVAILABLE. • "SD_CONSUMED_EVENTGROUP_DOWN" shall be indicated to the BswM module by calling the API BswM_Sd_ConsumedEventGroupCurrentState() for all associated ConsumedEventgroups, if the present state is SD_CONSUMED_ EVENTGROUP_AVAILABLE. • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, cancel the corresponding client service subscription retry delay timer and reset subscription retry counter of all corresponding Event- groups to 0.

If the Consumed Event Group is not requested anymore as in- dicated by a call of Sd_ConsumedEventGroupSetState with state SD_CONSUMED_ EVENTGROUP_RELEASED, the Service Discovery module shall perform the follow- ing steps for the consumed event group: • A StopSubscribeEventgroup shall be sent. • The status shall be set to SD_CONSUMED_EVENTGROUP_DOWN and be re- ported to the BswM by calling the API BswM_Sd_ConsumedEventGroupCurrent State(), if the status is not currently SD_CONSUMED_EVENTGROUP_DOWN. • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, cancel the corresponding client service subscription retry delay timer and reset subscription retry counter of all corresponding Event- groups to 0.

For checking if endpoints are topological correct, the value of ECUC_Sd_00128 shall be used in order to determine on how many leading bits shall be compared to check if an IP address is qualified as local. If not present, the value of the locally configured netmask for the IP address shall be used.

If an OfferService entry was received and its TTL timer did not expire yet, the associated Socket Connections are in state SOAD_SOCON_ONLINE in the Main phase: • If the client service has not been reported as SD_CLIENT_SERVICE_AVAIL- ABLE: – the API SoAd_EnableSpecificRouting() shall be called with SdClientService ActivationRef (see SdConsumedMethods) and the relevant Socket Connec- tions for this Client Service Instance. – SD_CLIENT_SERVICE_AVAILABLE shall be indicated to the BswM module by calling the API BswM_Sd_ClientServiceCurrentState(). • For each currently requested Consumed Eventgroup of this Client Service In- stance (Consumed Eventgroups are requested using Sd_ConsumedEventGroup SetState() and with state SD_CONSUMED_EVENTGROUP_REQUESTED or automatically on startup if SdConsumedEventGroupAutoRequire is configured to true), the following shall be done in exactly this order: – StopSubscribeEventgroup entry shall be sent out, if the last SubscribeEvent- group entry was sent as reaction to an OfferService entry received via Multi- cast, it was never answered with a SubscribeEventgroupAck, and the current OfferService entry was received via Multicast. – A SubscribeEventgroup entry shall be sent out. • If SdSubscribeEventgroupRetryEnable is set to TRUE and if SdSubscribeEvent- groupRetryMax is greater 0, the Eventgroup subscription retry counter shall be reset to 1.

When the Client Service is reported as SD_CLIENT_SERVICE_ DOWN to the BswM by calling the API BswM_Sd_ClientServiceCurrentState() • the API SoAd_DisableSpecificRouting() shall be called with SdClientServiceAc- tivationRef (see SdConsumedMethods) and the relevant Socket Connections for this Client Service Instance.

During initialization of the SD module, the API SoAd_OpenSoCon() shall be called for all Socket Connections associated with SdInstanceTxPdu, SdIn- stanceUnicastRxPdu and SdInstanceMulticastRxPdu.

If SdServerTimerRequestResponseMinDelay and SdServerTimer RequestResponseMaxDelay are set to the same value, this value shall be used as delay. If SdServerTimerRequestResponseMinDelay and SdServerTimerRequestResponse MaxDelay are set to 0, no delay shall be introduced.

If SdClientTimerRequestResponseMinDelay and SdClientTimer RequestResponseMaxDelay are set to the same value, this value shall be used as delay. If SdClientTimerRequestResponseMinDelay and SdClientTimerRequestResponse MaxDelay are set to 0, no delay shall be introduced.

If the TCP/IP connection has been lost (Socket connection is other than SOAD_SOCON_ONLINE), the Service Discovery Module shall leave the Repeti- tion Phase, enter the Down Phase, and stop the TTL timers of the associated Client Service Instances and EventGroups.

If the TCP/IP connection has been lost (Socket connection is other than SOAD_SOCON_ONLINE), the Service Discovery Module shall leave the Main Phase, enter the Wait Phase, and stop the TTL timers of the associated Client Service Instances and EventGroups.

If the TCP/IP connection has been lost (Socket connection is other than SOAD_SOCON_ONLINE), the Service Discovery Module shall leave the Repeti- tion Phase and enter the Wait Phase.

If the TCP/IP connection has been lost (Socket connection is other than SOAD_SOCON_ONLINE), the Service Discovery Module shall leave the Main Phase and enter the Wait Phase.

Every wildcard socket connection group shall be reset to wildcard using SoAd_ReleaseIpAddrAssignment() if all of the following conditions apply: • Local address of the socket connection group has been set by SD according to [SWS_Sd_00377]. • All socket connections of this socket connection group have been released.

The subscribe Eventgroup retry handling shall only be processed for Eventgroups of a ServerService where • SdSubscribeEventgroupRetryMax is greater than 0, • and only if SdSubscribeEventgroupRetryEnable is set to TRUE.

If the client service subscription retry delay timer elapsed and the counts of retries of subscription (SdSubscribeEventgroupRetryMax) did not exceed for a configured Eventgroup, the subscription for the Eventgroup shall be re-triggered by sending a combination of StopSubscribeEventgroup/SubscribeEventgroup, and the retry counter shall be incremented. If the counts of retries of subscription (SdSubscribe EventgroupRetryMax) exceeds, the ServiceDiscovery module shall raise the runtime error "SD_E_COUNT_OF_RETRY_SUBSCRIPTION_EXCEEDED".

The retry of a subscription for a requested Eventgroup shall be stopped for the following conditions: • If a SubscribeEventGroupAck or SubscribeEventGroupNack was received for the requested Eventgroup. • If the count of retries exceeds SdEventgroupSubscribeRetryMax of the requested Eventgroup. • If the requested Eventgroup is set to "SD_CONSUMED_EVENTGROUP_RE- LEASED".

The client service subscription retry delay timer shall be can- celled, if the retry is finished for all Eventgroups of a ClientService according to SWS_ SD_00738.

If several ServerServices refer to the same SdServerTimer, they shall share a common timer (and therefore a common random offset), if they either refer to the same SdServiceGroup and do not refer to any other (additional) SdService Group or, if SdServerServiceAutoAvailable of all ServerServices are set to TRUE.

If several ClientServices refer to the same SdClientTimer, they shall share a common timer (and therefore a common random offset), if they either refer to the same SdServiceGroup and do not refer to any other (additional) SdService Group or, if SdClientServiceAutoRequire of all ClientServices are set to TRUE.

If the Service Discovery Module receives an StopOfferService En- try while the current state SD_CLIENT_SERVICE_REQUESTED is for this Client Ser- vice Instance, the following step(s) shall be performed in the following order: • Cancel the repetition timer. • Leave the Repetition Phase immediately and enter the Main Phase.

If SdVersionDrivenFindBehavior is set to EXACT_OR_ANY_MI- NOR_VERSION the Service Discovery shall use 0xFFFF FFFF (ANY) for the Find- Service entry, which means that services with any minor version shall be returned

If SdEventHandlerUdp is configured: For every SubscribeEvent- group entry of this Eventhandler and if the SubscribeEventgroup entry references a Multicast Option, the following shall be done: • The relevant Routing Groups shall be identified by SdEventHandlerUdp. • The relevant UDP Socket Connection of this client shall be identified using the Eventgroup multicast endpoint (Address/Port) of the Multicast Option referenced in the SubscribeEventgroup entry and the SdServerServiceUdpRef, or shall be set up (SoAd_SetUniqueRemoteAddr()), if not existed before. – If no Wildcard Socket Connection is left, SD_E_OUT_OF_RES shall be re- ported. • The following action shall be performed, if no other client has already subscribed with the same Comsumed Eventgroup Multicast endpoint information: – Call SoAd_EnableSpecificRouting with SdEventActivationRef and the corre- sponding Socket Connection. The corresponding Socket Connection shall be the configured Socket Connection referenced by SdMulticastEventSo- ConRef, if the number of subscribed clients with different endpoint informa- tion has reached SdEventHandlerMulticastThreshold. Otherwise the identi- fied Socket Connection (described in the previous point) • Only if the client was not subscribed before receiving this entry: – SoAd_IfSpecificRoutingGroupTransmit with SdEventTriggeringRef and the Socket Connection.

Each Eventhandler shall qualify based on the configured SdEven- tHandlerMulticastThreshhold and the number of clients with different endpoint infor- mation (either received as Eventgroup unicast endpoint or as Eventgroup multicast endpoint), if the threshold has been reached to transmit the Events via the configured Evenhandler multicast endpoint (see SdMulticastEventSoConRef).

The ports shall be used for the events and notification events as well. • When using UDP the server uses the announced port as source port. • With TCP the client shall check the status of the socket connection by calling SoAd_GetSoConMode(). Calling this API has to provide SOAD_SOCON_ON- LINE state for at the dedicated socket connection. In addition, if a secure port was selected, an security association needs to be estab- lished before sending the subscription. Otherwise events and notification events can neither be sent secure ports nor received.

The ports shall be used for the events and notification events as well. • When using UDP the server uses the announced port as source port. • With TCP the client shall check the status of the socket connection by calling SoAd_GetSoConMode(). Calling this API has to provide SOAD_SOCON_ON- LINE state for at the dedicated socket connection. In addition, if a secure port was selected, an security association needs to be estab- lished before sending the subscription. Otherwise events and notification events can neither be sent secure ports nor received.

In case network security protocols are in use clients shall be hold- ing back their SubscribeEventgroup, as long as the security association that enables secure communication is not established (see [SWS_Sd_00761]).

When the client receives a SubscribeEventgroupNack as response to a SubscribeEventgroup for which a security association is required, the client shall check the state of the security protocol (see [SWS_Sd_00761]) and shall restart the security protocol, if not yet started (see [SWS_Sd_00465]).

If a SubscribeEventgroup entry is received, for which a security association is required, and the security association not yet established, this entry shall be answered with a SubscribeEventgroupNack entry (see [SWS_Sd_00760]).

If a Sd server receives a SubscribeEventgroup entry and client end point is assigned to a socket connection, the server shall call SoAd_IsConnection- Ready() for this socket connection and client endpoint: • If the function returns TCPIP_E_OK, the server shall respond with Sub- scribeEventgroupAck. • For all other return values the server shall discard the entry and respond with SubscribeEventgroupNack.

If a Sd client wants to subscribe to an Eventgroup, it shall call SoAd_IsConnectionReady() for the assigned socket connection and indented server end point. • If the function returns TCPIP_E_OK, the client can send a SubscribeEventgroup entry. • If the function returns TCPIP_E_PENDING, the client shall delay the subscription. • For all other return values the client shall discard the subscription request.

[SWS_Sd_00785]. ⌋

Figure 7.15: - Communication phases Client [SWS_Sd_00761] Upstream requirements: SRS_Eth_00162, SRS_Eth_00014 ⌈A client shall check the socket connection by calling SoAd_IsConnectionReady() to ensure that the connection is ready for communication (i.e., ARP has finished, TCP connection established, security association established etc. before subscribing or calling a method ). • If the function returns TCPIP_E_OK, then the connection is ready for communi- cation, thus the client can send a SubscribeEventgroup entry or call methods. • If the function returns TCPIP_E_PENDING, then SD shall repeat the call in next Sd_MainFunction() in accordance with the respective OfferService entry . • For all other values SD shall apply [SWS_Sd_00785]. ⌋

[SWS_Sd_00798]. – The socket connection shall be rechecked to be still ready for communication according to [SWS_Sd_00761]. – Event groups shall be resubscribed according to [SWS_Sd_00806]. ⌋

[SWS_Sd_00806]. • If the client service current state is indicated as SD_CLIENT_SERVICE_AVAIL- ABLE: – Check that the socket connection is matching the Address and Port of the Endpoint Option referenced in the OfferService entry. If it does not match, apply [SWS_Sd_00798]. – The socket connection shall be rechecked to be still ready for communication according to [SWS_Sd_00761]. – Event groups shall be resubscribed according to [SWS_Sd_00806]. ⌋