Requirements on SOME/IP Protocol
https://qiita.com/kaizen_nagoya/items/29e9889061b5314af173
Requirements on SOME/IP Protocol
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_RS_SOMEIPProtocol.pdf
"field communication" and "event communication" are 2 of important communication methods in AUTOSAR
field communication in AUTOSAR
https://qiita.com/kaizen_nagoya/items/db4fb2c213cac6ff76ee
In [RS_SOMEIP_00004] SOME/IP protocol shall support event communication
Description:SOME/IP protocol shall support event communication which is a uni-directional communication that is produced and sent by the service provider.
Rationale: Event based communication needs to be considered in the communication over the network.
The terms "event communication" and "event based communication" are used.
AUTOSAR_RS_CommunicationManagement.pdf.txt:The event-based communication between RESTful services shall be realized
AUTOSAR_RS_E2E.pdf.txt:2. If error prevention alone is insufficient (e.g. for inter-ECU communication), then
AUTOSAR_RS_E2E.pdf.txt:• periodic/mixed periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:for non-periodic event-based communication loss of communication data cannot be
AUTOSAR_RS_E2E.pdf.txt:• Detection of corrupted messages in periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:event-based communication
AUTOSAR_RS_E2E.pdf.txt:messages in periodic event-based communication
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TR_AdaptivePlatformSystemTests.pdf.txt:To verify the event-based communication with the Websocket protocol.
AUTOSAR_TR_Glossary.pdf.txt:event based communication and operations that are provided by the service
grep
ubuntu/bash
# grep event * | grep communication
AUTOSAR_EXP_ARAComAPI.pdf.txt:only provide the minimal set of functionality needed to support the service based communication paradigm consisting of the basic mechanisms: methods, events and fields.
AUTOSAR_EXP_ARAComAPI.pdf.txt:API shall only deal with the functionality to handle method, field and event communication on service consumer and service provider implementation side.
AUTOSAR_EXP_ARAComAPI.pdf.txt:In those rather typical scenarios of 1:N event communication, this would allow to have
AUTOSAR_EXP_ARAComAPI.pdf.txt:only accepted by specific (RT) timers. Asynchronous communication events shall not
AUTOSAR_EXP_PlatformDesign.pdf.txt:taken to prevent a second communication path beneath the functionality provided by
AUTOSAR_PRS_E2EProtocol.pdf.txt:Data communication is called sender/receiver in Classic Platform, and it is called event
AUTOSAR_PRS_E2EProtocol.pdf.txt:communication in Adaptive Platform. Note that the word event is a bit confusing as a
AUTOSAR_PRS_SOMEIPProtocol.pdf.txt:event communication
AUTOSAR_RS_CommunicationManagement.pdf.txt:[RS_CM_00314]{DRAFT} The Communication Management shall provide Websockets to establish event communication. d
AUTOSAR_RS_CommunicationManagement.pdf.txt:The event-based communication between RESTful services shall be realized
AUTOSAR_RS_E2E.pdf.txt:2. If error prevention alone is insufficient (e.g. for inter-ECU communication), then
AUTOSAR_RS_E2E.pdf.txt:• periodic/mixed periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:for non-periodic event-based communication loss of communication data cannot be
AUTOSAR_RS_E2E.pdf.txt:• Detection of corrupted messages in periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:event-based communication
AUTOSAR_RS_E2E.pdf.txt:messages in periodic event-based communication
AUTOSAR_RS_FoundationDebugTraceProfile.pdf.txt:events shall be grouped into classes (e.g. scheduler or communication events).
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:[RS_SOMEIP_00004] SOME/IP protocol shall support event communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:[RS_SOMEIP_00005] SOME/IP protocol shall support different strategies for event communication . . . . . . . . . . . . . . . . . .
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:[RS_SOMEIP_00042] SOME/IP protocol shall support unicast and multicast based event communication . . . . . . . . . . . . . . .
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:This document specifies the requirements of the Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol — an automotive/embedded protocol and the underlying serialization / wire format which can be used for request/response and eventbased communication.
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:[RS_SOMEIP_00004] SOME/IP protocol shall support event communication d
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:SOME/IP protocol shall support event communication which is a uni-directional
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:event communication d
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:based event communication d
AUTOSAR_RS_SOMEIPServiceDiscoveryProtocol.pdf.txt:Service based event communication is based on a publish/subscribe pattern to
AUTOSAR_RS_SystemTemplate.pdf.txt:simply to experience, some communication paths must be prevented to be
AUTOSAR_SRS_RTE.pdf.txt:The RTE shall support the communication of External Trigger events from one
AUTOSAR_SRS_RTE.pdf.txt:External and internal trigger event communication shall support queuing the
AUTOSAR_SRS_TTCAN.pdf.txt:support the event synchronized time-triggered communication.
AUTOSAR_SRS_TTCAN.pdf.txt:Synchronizing communication with external events.
AUTOSAR_SWS_CANInterface.pdf.txt:through the CanTrcv. The transceiver device and the underlying communication driver has to buffer detected wake-up events and raise the event(s), when the wake-up
AUTOSAR_SWS_CANTransceiverDriver.pdf.txt:events from the last communication cycle. It is very important not to lose wake up
AUTOSAR_SWS_CANTransportLayer.pdf.txt:The AUTOSAR communication stack supports both polling and event triggering
AUTOSAR_SWS_COMManager.pdf.txt:Communication’ mode, and prevent the ECU from shutdown during communication.
AUTOSAR_SWS_COMManager.pdf.txt:related communication channels that usually get communication-requests from SWCs as the consequence of this event. This corrupts the forwarding of communication
AUTOSAR_SWS_CommunicationManagement.pdf.txt:The Communication Management provides a build-in safety mechanism (E2E protection), which can be used for all levels of communication for events that are received
AUTOSAR_SWS_CommunicationManagement.pdf.txt:event communication
AUTOSAR_SWS_CommunicationManagement.pdf.txt:event communication
AUTOSAR_SWS_CommunicationManagement.pdf.txt:The specified E2E communication protection for events include only events which are:
AUTOSAR_SWS_CommunicationManagement.pdf.txt:SOME/IP supports one-to-many (unicast) and many-to-many (multicast) communication paradigms. These paradigms may switch at runtime for events (see multicastThreshold).
AUTOSAR_SWS_CommunicationManagement.pdf.txt:Event handling on receiver side is based on queued communication with configurable cache sizes. The cache size for a specific event of a proxy instance is determined by the Communication Management, when subscribing to a specific event by
AUTOSAR_SWS_CommunicationManagement.pdf.txt:Some data types are used only in context of e2e-protected communication of events.
AUTOSAR_SWS_CommunicationManagement.pdf.txt:the e2e check yielded ERROR were received within the E2E time window – communication of the sample of this event not functioning properly, sample(s) cannot be used.
AUTOSAR_SWS_CommunicationStackTypes.pdf.txt:[CompTypes]. To prevent multiple includes of header files, the communication stack
AUTOSAR_SWS_DiagnosticCommunicationManager.pdf.txt:[SWS_Dcm_00135] dROE events occurring in a communication mode different from
AUTOSAR_SWS_DiagnosticEventManager.pdf.txt:if the modules purpose is different than processing diagnostic requests. The design focuses on Dcm for OBD and UDS processing, as well as remote event communication
AUTOSAR_SWS_Diagnostics.pdf.txt:Diagnostic Management is a placeholder for the complete functionality of diagnostic communication and event handling.
AUTOSAR_SWS_Diagnostics.pdf.txt:event. The DTC is used by diagnostics, including e.g. UDS communication with an
AUTOSAR_SWS_ECUStateManager.pdf.txt:[SWS_EcuM_02963] ⌈If a wakeup event (e.g. toggling a wakeup line, communication
AUTOSAR_SWS_ExecutionManagement.pdf.txt:DeterministicClient::WaitForNextActivation returns based on the communicationevent-triggers that are configured for the Process from the outside via
AUTOSAR_SWS_FlexRayInterface.pdf.txt:Note: There is no true spontaneous event-driven data communication on FlexRay.
AUTOSAR_SWS_FlexRayNetworkManagement.pdf.txt:repetition of its communication scheme, the so called Cycle – see [6]). To prevent
AUTOSAR_SWS_LINInterface.pdf.txt: Indication of a detected communication error event (LinIf_LinErrorIndication)
AUTOSAR_SWS_LINStateManager.pdf.txt:sleep event is forwarded to ComM. Otherwise if the full communication mode
AUTOSAR_SWS_OS.pdf.txt:The IOC provides both, unqueued (Last-is-Best, data semantics) or queued (First-InFirst-Out, event semantics) communication operations. If present, the IOC internal
AUTOSAR_SWS_OS.pdf.txt:If an IOC communication with event semantics (queued) is configured the length of
AUTOSAR_SWS_RTE.pdf.txt:“real” value has been received, possibly via the communication service. The requirement does not apply when “event” semantics are used since the implied state change
AUTOSAR_SWS_RTE.pdf.txt:which references the VariableDataPrototype for which the API is being generated), the API call immediately returns the next value to be read and, if the communication is queued (event reception), it removes the data from the receiver-side queue,
AUTOSAR_SWS_RTE.pdf.txt:Note: A loss of events might occur in inter-ECU communication even if the receiver
AUTOSAR_SWS_RTE.pdf.txt:The communication of mode switch notifications is typically event driven. Accordingly, RTE offers a similar queueing mechanism as for the ’queued’ sender receiver
AUTOSAR_SWS_RTE.pdf.txt:mode machine instance, assigns a constant length to the receive queue. In contrast to the event communication, for mode switch communication, the length is associated with the sender side, the mode manager, because it is unique for the mode
AUTOSAR_SWS_RTE.pdf.txt:Figure 4.40: Sender Receiver communication with event semantics and dataReceivePointByArgument as reception mechanism
AUTOSAR_SWS_RTE.pdf.txt:Figure 4.41: Sender Receiver communication with event semantics and activation of
AUTOSAR_SWS_RTE.pdf.txt:For Sender-Receiver communication currently only "explicit" transmission of data elements with "event" semantic (queued) is supported.
AUTOSAR_SWS_RTE.pdf.txt:With the mechanism of the trigger event communication a software component or a
AUTOSAR_SWS_RTE.pdf.txt:in one or more tasks/ISR2s. In this case the event communication can be implemented
AUTOSAR_SWS_RTE.pdf.txt:The concept of external event communication supports, that a trigger source activates one or more triggered ExecutableEntitys in one or more trigger
AUTOSAR_SWS_RTE.pdf.txt:events to the same Trigger in a trigger sink (‘n : 1’ communication where n > 1).
AUTOSAR_SWS_RTE.pdf.txt:[SWS_Rte_02536] dIncoming data and events from sender receiver communication
AUTOSAR_SWS_RTE.pdf.txt:in their execution order for queued (event semantics) sender-receiver communication
AUTOSAR_SWS_RTE.pdf.txt:• “Overlayed Errors” are associated with communication events that happened after the reception of the currently available data set, e.g., data element outdated notification, or loss of data elements due to queue overflow.
AUTOSAR_SWS_RTE.pdf.txt:COM trace events occur when the generated RTE interacts with the AUTOSAR communication service.
AUTOSAR_SWS_RTE.pdf.txt:the Rte_Pim API. However, many trace events are applicable to object-code softwarecomponents including trace events related to the explicit communication API, to task
AUTOSAR_SWS_RTE.pdf.txt:keeping even for internal client server communication to prevent that the unique
AUTOSAR_SWS_RTE.pdf.txt:Rationale: This prevents the misuse of references for communication via the referenced memory (intra-partition scope) between ApplicationSwComponentTypes
AUTOSAR_SWS_TTCANDriver.pdf.txt:[SWS_TtCan_00007] dTtcanDrv shall support event-synchronized communication
AUTOSAR_SWS_TimeService.pdf.txt:in each BSW partition to prevent inter-partition communication.
AUTOSAR_SWS_XCP.pdf.txt:This restriction prevents disturbances of ongoing FlexRay communication.
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf.txt:communication, the various task local buffers need to be identified in relation to RTE events and variable
AUTOSAR_TPS_ManifestSpecification.pdf.txt:[TPS_MANI_03210]{DRAFT} Specification of event specific communication attributes dThe meta-class QueuedSenderComSpec can be used to specify communication attributes that are relevant for an event on the sender side.c(RS_MANI_00002)
AUTOSAR_TPS_ManifestSpecification.pdf.txt:[TPS_MANI_03010]{DRAFT} Udp Transport Protocol Configuration in case of IPMulticast dThe SomeipServiceInstanceToMachineMapping.eventMulticastUdpPort defines the Transport Protocol Port Number for a UDP event communication
AUTOSAR_TPS_ManifestSpecification.pdf.txt:ProvidedSomeipServiceInstance and a ProvidedUserDefinedServiceInstance representing an IPC communication then an event is allowed to be protected
AUTOSAR_TPS_ManifestSpecification.pdf.txt:Specification of event specific communication attributes
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:[TPS_SWCT_01196] Semantics of an external trigger event communication dThe
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:underlying semantics of an external trigger event communication is that a trigger source
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:event communication in a queued manner.
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:Sections 7.5.1 and 7.5.2 then explain the sender-receiver and client-server communication patterns with respect to the RTE, the RTE events and the corresponding communication attributes.
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:This constraint prevents hidden communication between SwComponentPrototypes
AUTOSAR_TPS_SoftwareComponentTemplate.pdf.txt:Semantics of an external trigger event communication
AUTOSAR_TPS_SystemTemplate.pdf.txt:The AUTOSAR protocol SOME/IP is a Service Discovery protocol that is used to communicate the availability of functional entities called services in the in-vehiclecommunication and to control the send behavior of event messages to receivers that subscribed
AUTOSAR_TPS_SystemTemplate.pdf.txt:Types of a RoutingGroups for the event communication.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Multicast Address that is used for event communication in
AUTOSAR_TPS_SystemTemplate.pdf.txt:multicastThreshold, the transmission of events takes place via unicast communication.c()
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Multicast Address that is used for event communication in the IP-Multicast case. It is the destination
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_SystemTemplate.pdf.txt:Please note that this attribute is only valid for event communication (Sender Receiver communication) and shall be omitted in MethodActivationRoutingGroups.
AUTOSAR_TPS_TimingExtensions.pdf.txt:event of a chain somehow causes subsequent chain events. An example for an endto-end event chain with bus communication is depicted in Figure 3.5 in chapter 3. This
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe timing events related to sender-receiver communication at VFB level.
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe timing events related to client-server communication at VFB level.
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe timing events related to mode switchcommunication at VFB level.
AUTOSAR_TPS_TimingExtensions.pdf.txt:at a specific location in the System view, in particular any event related to communications.c(RS_TIMEX_00001)
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is the abstract parent class to describe timing events related to communication including the physical
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe timing events related to the exchange of frames between the communication
AUTOSAR_TPS_TimingExtensions.pdf.txt:to the start of a FlexRay communication cycle dThe element TDEventFrClusterCycleStart is used to specify events, namely the start of a communication cycle,
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe the timing event related to a point in time where a communication cycle starts on
AUTOSAR_TPS_TimingExtensions.pdf.txt:the start of a TTCAN communication cycle dThe element TDEventTTCanCycleStart is used to specify events, namely the start of a communication cycle, observable at the physical layer of the TTCAN bus.c(RS_TIMEX_00001)
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe the timing event related to a point in time where a communication cycle starts on
AUTOSAR_TPS_TimingExtensions.pdf.txt:events in case of BSW mode communication dThe element TDEventBswModeDeclaration is used to specify events that are observable when mode changes
AUTOSAR_TPS_TimingExtensions.pdf.txt:This is used to describe timing events related to the mode communication on BSW level.
AUTOSAR_TR_AdaptiveMethodology.pdf.txt:service-oriented communication are specified, i.e., particular events, methods and
AUTOSAR_TR_AdaptivePlatformSystemTests.pdf.txt:To verify the event-based communication with the Websocket protocol.
AUTOSAR_TR_AutosarModelConstraints.pdf.txt:Types of a RoutingGroups for the event communication.
AUTOSAR_TR_AutosarModelConstraints.pdf.txt:Multicast Address that is used for event communication in
AUTOSAR_TR_AutosarModelConstraints.pdf.txt:communication, the various task local buffers need to be identified in relation to RTE events and variable
AUTOSAR_TR_AutosarModelConstraints.pdf.txt:This is used to describe timing events related to client-server communication at VFB level.
AUTOSAR_TR_AutosarModelConstraints.pdf.txt:This is used to describe timing events related to sender-receiver communication at VFB level.
AUTOSAR_TR_Glossary.pdf.txt:event based communication and operations that are provided by the service
AUTOSAR_TR_TimingAnalysis.pdf.txt:independent from a communication schedule. The eventtriggered sending is limited by a debounce time which
AUTOSAR_TR_TimingAnalysis.pdf.txt:to the service. The communication shall consist of events and method calls. With this
AUTOSAR_TR_TimingAnalysis.pdf.txt:(c) Analysis 3: In order to consider the ECU influence and the total communication the event chain / the routing time analysis of the PDUs/frames/package
# grep event * | grep communication |grep based
AUTOSAR_EXP_ARAComAPI.pdf.txt:only provide the minimal set of functionality needed to support the service based communication paradigm consisting of the basic mechanisms: methods, events and fields.
AUTOSAR_RS_CommunicationManagement.pdf.txt:The event-based communication between RESTful services shall be realized
AUTOSAR_RS_E2E.pdf.txt:• periodic/mixed periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:for non-periodic event-based communication loss of communication data cannot be
AUTOSAR_RS_E2E.pdf.txt:• Detection of corrupted messages in periodic event-based communication
AUTOSAR_RS_E2E.pdf.txt:event-based communication
AUTOSAR_RS_E2E.pdf.txt:messages in periodic event-based communication
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:[RS_SOMEIP_00042] SOME/IP protocol shall support unicast and multicast based event communication . . . . . . . . . . . . . . .
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:This document specifies the requirements of the Scalable service-Oriented MiddlewarE over IP (SOME/IP) protocol — an automotive/embedded protocol and the underlying serialization / wire format which can be used for request/response and eventbased communication.
AUTOSAR_RS_SOMEIPProtocol.pdf.txt:based event communication d
AUTOSAR_RS_SOMEIPServiceDiscoveryProtocol.pdf.txt:Service based event communication is based on a publish/subscribe pattern to
AUTOSAR_SWS_CommunicationManagement.pdf.txt:Event handling on receiver side is based on queued communication with configurable cache sizes. The cache size for a specific event of a proxy instance is determined by the Communication Management, when subscribing to a specific event by
AUTOSAR_SWS_ExecutionManagement.pdf.txt:DeterministicClient::WaitForNextActivation returns based on the communicationevent-triggers that are configured for the Process from the outside via
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:RTE event-based communication, i.e. queued communication with queue size = 1,
AUTOSAR_TPS_SystemTemplate.pdf.txt:event-based communication, i.e. queued communication with queue size = 1, using
AUTOSAR_TR_AdaptivePlatformSystemTests.pdf.txt:To verify the event-based communication with the Websocket protocol.
AUTOSAR_TR_Glossary.pdf.txt:event based communication and operations that are provided by the service
docker
docker hubに作業中の資料を置いています。上記grepもdocker上で実施。同じコマンドを叩けば、同じ結果が得られるはず。
$ docker run -v /Users/administrator/Downloads/autosar:/tmp/docker -it kaizenjapan/autosar /bin/bash
/Users/administrator/Downloads/autosarは、PCに存在しているフォルダ名。
後はそのままでいいはず。
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.