Requirements on SOME/IP Protocol
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_RS_SOMEIPProtocol.pdf
abbreviation
| Abbreviation / Acronym | Description |
|---|---|
| RPC | Remote Procedure Call |
| SOME/IP | Scalable service-Oriented MiddlewarE over Internet Protocol. |
| TCP | Transmission Control Protocol. |
| UDP | User Datagram Protocol. |
Devide abbreviation and term. The list below is term and description.
term
| Term | Description |
|---|---|
| Event | A uni-directional data transmission that is only invoked on changes or cyclically and is sent from the producer of data to the consumers. |
| Eventgroup | A logical grouping of events and notification events of fields inside a service in order to allow subscription |
| Field | A field does represent a status and thus has an valid value at all times on which getter, setter and notifier act upon. |
| Getter | A Request/Response call that allows read access to a field. |
| Method | A method, procedure, function, or subroutine that is called/in- voked. |
| Notification Event | An event message of the notifier of a field. |
| Notifier | Sends out event message with a new value on change of the value of the field. |
| Remote Procedure Call (RPC) | A method call from one ECU to another that is transmitted using messages |
| Service | A logical combination of zero or more methods, zero or more events, and zero or more fields. |
| Service Instance | Implementation of a service, which can exist more than once in the vehicle and more than once on an ECU |
| Setter | A Request/Response call that allows write access to a field. |
| Union | A data structure that dynamically assumes different data types. |
references
p.27
[1] Standardization Template AUTOSAR_TPS_StandardizationTemplate
https://www.autosar.org/fileadmin/user_upload/standards/classic/19-11/AUTOSAR_TPS_StandardizationTemplate.pdf
[2] Glossary AUTOSAR_TR_Glossary
https://www.autosar.org/fileadmin/user_upload/standards/foundation/19-11/AUTOSAR_TR_Glossary.pdf
[3] IEEE Standard for Floating-Point Arithmetic (IEEE Std 754-2008)
Review
The granularity of the request is different.
The level of abstraction of the request is different.
The relations of the description, rationale and use case are different.
[RS_SOMEIP_00002] SOME/IP protocol shall provide service-based communication
Type:valid
Description:SOME/IP protocol shall provide service-based communication where communication paths are established during runtime.
Rationale:Service-based communication allows a communication which was not predefined during system design phase.
Use Case:Communication between partners is not statically defined during system design phase.
service
"service based communication" is not defined in this document and the references. service oriented communication is defined.
In glossary,
3.8 Adaptive Platform Services
3.37 AUTOSAR Service
the service-oriented architecture.
The term service is also used to describe the handling of diagnostic services, e.g. UDS service ReadDataByIdentifier, for the communication between a diagnostic tester and a diagnostic stack on an (AUTOSAR) ECU.
3.73 Confirmation
Service primitive defined in the ISO/OSI Reference model (ISO 7498).
3.102 Event Message (SOME/IP)
Event – a message sent by an ECU implementing a service instance to an ECU using this service instance (Publish/Subscribe).
3.152 Indication
Service primitive defined in the ISO/OSI Reference Model (ISO 7498).
3.159 Interrupt Service Routine
A software routine called in case of an Interrupt.
3.160 Interrupt Vector Table
An interrupt vector table is a table of interrupt vectors that associates the Interrupt Service Routine with the corresponding interrupt request (typically by an array of jumps or similar mechanisms).
3.248 Service Data Unit
Service Data Unit is the data passed by an upper layer, with the request to transmit the data. It is as well the data, which is extracted after reception by the lower layer and passed to the upper layer.
3.256 Service
A service is a type of operation that has a published specification of interface and behavior, involving a contract between the provider of the capability and the potential clients.
3.257 Service Discovery
Generic functionality provided by the Communication Management to Applications that allows Applications at runtime to find locally or remotely available Service Instances providing the requested service.
3.258 Service Instance
The properties of a service instance are described by a specific service interface. A service instance has a unique identity.
3.259 Service Interface
A service interface is a special kind of port interface (see
Port Interface) used in the Adaptive platform. It defines both data elements for event based communication and operations that are provided by the service provider and that can be used by the service requester.
3.260 Service Oriented Communication
Communication, for which communication partners are generally not defined during design time, but dynamically discovered and bound during runtime.
3.261 Service Port
A Service Port is a Port of a Software Component, Complex Driver and/or ECU Abstraction Layer connected to an AUTOSAR Service.
3.262 Service Proxy
A facade that represents a specific service on code level from the perspective of the service consumer providing methods for all functionalities offered by the represented service.
3.263 Service Skeleton
A representation of a specific service on code level from the perspective of the service implementation, which provides functionalities according to the service definition and allows to connect the service implementation to the Communication Management transport layer, so that the service implementation can be contacted by service consumers.
3.264 Services Layer
The Services Layer is the highest layer of the Basic Software which also applies for its relevance for the application software: while access to I/O signals is covered by the Hardware Abstraction Layer, the Services Layer offers Operating system services, Vehicle network communication and management services, Memory services (NVRAM management), Diagnosis Services (including KWP2000 interface and error memory), ECU state management.
3.265 Signal Service Translation Definition
Signal Service Translation is the standardized way to map the definition of signal-based communication to service-oriented communication, and vice versa.
serviceとmanagementとsoftware(OS)とcommunicationとsignalの関係をぼんやりと記述しているかもしれない。
system design
"system design phase" is not defined in this document.
[RS_SOMEIP_00041] SOME/IP protocol shall provide support of multiple versions of the protocol
SOME/IP protocol shall provide support of multiple versions of the protocol to distinguish the version of the messages on the network.
A version is needed to be able to distinguish SOME/IP messages of different versions with different structure in header or payload.
Backward incompatible extension and modifications of SOME/IP where both the old and the new protocol are used within the same network.
Are there any description of how many versions should be supported?
How can we manage the versions of the protocols. In RS_SOMEIP_00003 interfaces are used.
[RS_SOMEIP_00003] SOME/IP protocol shall provide support of multiple versions of a service interface
Description: SOME/IP protocol shall provide support of multiple versions of a service interface to detect incompatible changes of the service interface.
Rationale: The communication partners need to distinguish different versions of a service.
Use Case: Backward-incompatible changes of a service interface.
[RS_SOMEIP_00004] SOME/IP protocol shall support event communication
SOME/IP protocol shall support event communication which is a uni-directional communication that is produced and sent by the service provider.
Event based communication needs to be considered in the communication over the network.
Communication of data which are produced on event-base, e.g gear-shifts.
What is the meaning of event based communication.
event based communication
https://qiita.com/kaizen_nagoya/items/f8af9bc5641c6eb8f5cf
[RS_SOMEIP_00005] SOME/IP protocol shall support different strategies for event communication
Description:SOME/IP protocol shall support different update strategies for event communication to enable communication on a cyclic base or when the value has changed
Rationale:Different data need to be communicated on different conditions
Use Case:Some event-based data need to be communicated only on changes, other are communicated in cyclic manner, e.g, to avoid errors if ECUs were restarted during runtime
[RS_SOMEIP_00006] SOME/IP protocol shall support uni-directional RPC communication
Description:SOME/IP protocol shall support uni-directional RPC communication which triggers the execution of an RPC without informing the caller about the result
Rationale:Depending on the number of receiver unicast or multicast communication is more efficient. Unicast messages are a mechanism to hide data for certain receivers that do not need to spend processing resources on reception of unwanted data. Multicast allows to save bandwidth if many receivers shall receive the same data.
Use Case:If the caller does not need to be informed about the result of an RPC, uni-directional communication suffices.
Execution of RPCs where the caller is only interested in triggering the RPC but in no result
[RS_SOMEIP_00007] SOME/IP protocol shall support bi-directional RPC communication
Description:SOME/IP protocol shall support bi-directional RPC communication and inform the caller about the result
Rationale:If the caller needs to be informed about the result of an RPC, it has to be communicated back to the caller.
Use Case:Execution of RPCs and transporting the result back to the caller.
[RS_SOMEIP_00008] SOME/IP protocol shall support error handling of RPC communication
Description: SOME/IP protocol shall support error handling of RPC communication and communicate errors on callee side back to the caller.
Rationale: The caller needs to be able to react on remote errors of the callee.
Use Case: An RPC fails and the failure is considered at the error handling routine of the caller.
[RS_SOMEIP_00009] SOME/IP protocol shall support field communication
Description:SOME/IP protocol shall support field communication with getters, setters and notification events.
Rationale:For properties held at a central party, this communication pattern provides the needed access functionality.
Use Case:One party in the vehicle holds a central property which is set and/or used by multiple other parties.
What is "field communication"?
field communication in AUTOSAR
https://qiita.com/kaizen_nagoya/items/db4fb2c213cac6ff76ee
[RS_SOMEIP_00010] SOME/IP protocol shall support different transport protocols underneath ⌈ valid
Description: SOME/IP protocol shall support different transport protocols underneath. SOME/IP protocol shall transport data based on TCP/IP and UDP/IP.
Rationale: SOME/IP does not directly operate on IP but needs an transport protocol based on IP that provides basic transport services.
Use Case: SOME/IP over UDP for time critical communication, SOME/IP over TCP for time-uncritical communication of large data
[RS_SOMEIP_00011] SOME/IP protocol shall support messages of different
Description: SOME/IP protocol shall support messages of different lengths. The PDU size shall be variable based on the size of the data to transmit.
Rationale: Message lengths are application specific.
Use Case: Some application transmit small data chunks, other transmit large data chunks. Length of data sent by the same application can vary during execution.
[RS_SOMEIP_00012] SOME/IP protocol shall support session handling
Description: SOME/IP protocol shall support session handling and provide a mechanism to distinguish multiple parallel communications between the same parties.
Rationale: Session handling is used to distinguish multiple parallel communications between the same parties for the same service.
Use Case: One client issues multiple RPCs which get handled separately and the responses are correctly assigned to the requests.
[RS_SOMEIP_00014] SOME/IP protocol shall support handling of protocol errors on receiver side
Description: SOME/IP protocol shall support handling of protocol errors on receiver side and define checks to be performed by the receiver.
Rationale: Errors which are a consequence of faulty configuration (either sender or receiver side) can be recognized on receiver side. Recevied data are not handed over from the communication stack to the receiving applications if they are not expected by an application.
Use Case: Any mismatch between received and expected message on receiver side could lead to an erroneous behavior.
#[RS_SOMEIP_00051] SOME/IP protocol shall provide support for segmented
Description: SOME/IP protocol shall provide support for segmented transmission of large data. The sender shall be able to split one large message into multiple smaller segments. These are transported to the receiver. The receiver shall be able to reassemble the original message.
Rationale:Time critical data can’t be transmitted over TCP but UDP has to be used. UDP has a maximum packet length of 4KB. IP Fragmentation can only be used until 65KB. So, no existing technology provides suitable possibilities of segmentation. For these cases segmentation needs to be done by SOME/IP and not by the application itself.
Use Case: Time critical transmission of data larger than 65KB
[RS_SOMEIP_00019] SOME/IP protocol shall identify services using unique identifiers
Description: SOME/IP protocol shall identify services using vehicle-wide unique identifiers
Rationale: It is necessary to distinguish services vehicle wide.
Use Case: Discovery of a specific service.
[RS_SOMEIP_00015] SOME/IP protocol shall support multiple instances of a service
Description: SOME/IP protocol shall support multiple instances of a service for services which provide the same functionality.
Rationale: One system design might provide one service with multiple instances, another system design might define multiple services with one instance each.
Use Case: One system design might provide one service with multiple instances, another system design might define multiple services with one instance each.
[RS_SOMEIP_00016] SOME/IP protocol shall support combining multiple RPC methods, events and fields in one service
Description: SOME/IP protocol shall support combining multiple RPC methods, events and fields in one service. Functionality based on services (e.g service discovery) shall treat them together but the encapsulated RPC methods, events and fields themselves shall be usable on its own.
Rationale: If functionality is often used together or other reasons for grouping exist from architectural point of view, it is not suitable to provide an own service per functionality.
Use Case: Combination of functionality which is always used together.
[RS_SOMEIP_00017] SOME/IP protocol shall support grouping events into event group.
Description: SOME/IP protocol shall support grouping events of the same provider into eventgroups to enable subscriptions to all events of a specific eventgroup in one step.
Rationale: If events are provided by the same party, a grouping into an eventgroup enables more efficient service subscriptions.
Use Case: A large number of related events is provided by the same party.
[RS_SOMEIP_00018] SOME/IP protocol shall support grouping fields in event groups
Description: SOME/IP protocol shall support grouping fields of the same provider in eventgroups to enable subscriptions to all fields of a specific eventgroup in one step.
Rationale: If fields are provided by the same party, a grouping into an eventgroup enables more efficient service subscriptions.
Use Case: A large number of related fields is provided by the same party.
[RS_SOMEIP_00021] SOME/IP protocol shall identify RPC methods of services using unique identifiers ⌈ valid
Description: SOME/IP protocol shall identify RPC methods, getters of fields and setters of fields using identifiers which are unique for that service.
Rationale: Methods, getters and setters within one service needs to be distinguishable from other methods, getters or setter within the same service.
Use Case: Services which consist of more than one method, getter or setter.
[RS_SOMEIP_00022] SOME/IP protocol shall identify events of services using unique identifiers
Description: SOME/IP protocol shall identify events and notifiers of fields using identifiers which are unique for that service.
Rationale: An event within one service needs to be distinguishable from the other events within the same service.
Use Case: Services which consist of more than one event.
[RS_SOMEIP_00023] SOME/IP protocol shall identify event groups of services using unique identifiers
Description: SOME/IP protocol shall identify event groups of services using identifiers which are unique for that service.
Rationale: An event group within one service needs to be distinguishable from the other event groups within the same service.
Use Case: Services which consist of more than one event group.
[RS_SOMEIP_00024] SOME/IP protocol shall define reserved identifiers
Description: SOME/IP protocol shall define reserved identifiers for special services. These identifiers cannot be used for normal services.
Rationale: For compatibility reasons a range of reserved IDs needs be defined. This can be used later on by OEMs without interfering with the rest of the services.
Use Case: Service discovery of non-SOME/IP services
[RS_SOMEIP_00025] SOME/IP protocol shall support the identification of callers of an RPC using unique identifiers
Description: SSOME/IP protocol shall support the identification of callers of an RPC using identifiers which are unique for the RPC in the system.
Rationale: Callers need to be identified if multiple callers on the same ECU which are using the same socket connection use the same RPC method to be able to assign the response correctly to the request.
Use Case: Calling an RPC method from multiple callers which are located on one or multiple remote machines.
[RS_SOMEIP_00027] SOME/IP protocol shall define the header layout of messages
Description: SOME/IP protocol shall define the header layout of messages for a respective version.
Rationale: The layout of the header needs to be understood by the communication partners.
Use Case: Communication between different parties.
[RS_SOMEIP_00028] SOME/IP protocol shall specify the serialization algorithm for data
Description: SOME/IP protocol shall specify the serialization algorithm for data to convert the machine-specific memory representation to a common network-representation.
Rationale: The memory representation of data heavily depends on processor architecture and compiler settings which differ between the machine in the vehicle.
Use Case: Communication of payload between communication partners using different processor architectures.
[RS_SOMEIP_00029] SOME/IP protocol shall specify how data in the payload are aligned
Description: SOME/IP protocol shall specify how data in the payload are aligned. This includes the start of primitive data types and gaps between them.
Rationale: Some architectures allow a faster access to data which are aligned in memory. If speed matters, it is useful to be able to influence the alignment and optimize the accesses.
Use Case: Fast access to serialized representation of structured data types.
[RS_SOMEIP_00026] SOME/IP protocol shall define the endianness of header and payload
Description: SOME/IP protocol shall define the endianness of data representation in header and payload. The communication partners shall use that endianness on the network.
Rationale: If machines with different endianness communicate with each other, the format on the network needs to be defined.
Use Case: A little-endian machine communicates with a big-endian machine.
[RS_SOMEIP_00030] SOME/IP protocol shall support transporting integer data types
Description: SOME/IP protocol shall support transporting integer data types, signed and unsigned of 8, 16 and 32 bit length.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of basic data types needs to be supported by SOME/IP.
Use Case: Communication of c-data types
[RS_SOMEIP_00031] SOME/IP protocol shall support transporting boolean data type
Description: SOME/IP protocol shall support transporting boolean data type.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of basic data types needs to be supported by SOME/IP.
Use Case: Communication of boolean values.
[RS_SOMEIP_00032] SOME/IP protocol shall support transporting float data types
Description: SOME/IP protocol shall support transporting float data types kown as single and double (defined in IEEE 754 [3] as binary32 and binary64)
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of basic data types needs to be supported by SOME/IP.
Use Case: Communication of c-data types
[RS_SOMEIP_00033] SOME/IP protocol shall support transporting structured data types
Description: SOME/IP protocol shall support transporting structured data types which can consist of one or multiple structured data types of fixed or variable size and/or primitive data types.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Consistent communication of more than one primitive data type.
[RS_SOMEIP_00034] SOME/IP protocol shall support transporting union data types
Description: SOME/IP protocol shall support transporting union data types where the concrete data type is determined during execution.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Communication of data with the possibility to choose representation dynamically.
[RS_SOMEIP_00035] SOME/IP protocol shall support transporting one dimensional and multi-dimensional array data types
Description: SOME/IP protocol shall support transporting one-dimensional and multi-dimensional array data types.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Consistent communication of more than one data element of the same type.
[RS_SOMEIP_00036] SOME/IP protocol shall support transporting array data types with a fixed length
Description: SOME/IP protocol shall support transporting array data types with a fixed length which represent the fixed number of array elements.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Consistent communication of a specific number of data elements of the same type.
[RS_SOMEIP_00037] SOME/IP protocol shall support transporting array data types with flexible length
Description: SOME/IP protocol shall support transporting one-dimensional and multi-dimensional array data types with flexible number of data elements. A maximum number of data elements shall be provided.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Consistent communication of a variable number of data elements of the same type.
[RS_SOMEIP_00038] SOME/IP protocol shall support transporting string types with a fixed length
Description: SOME/IP protocol shall support transporting string types with a fixed length.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Communication of strings.
[RS_SOMEIP_00039] SOME/IP protocol shall support transporting string data types with flexible length ⌈ valid
Description: SOME/IP protocol shall support transporting string data types with flexible length. A maximum length shall be provided.
Rationale: For the specification of a serialization algorithm of SOME/IP, a set of data types needs to be supported by SOME/IP.
Use Case: Communication of strings.
[RS_SOMEIP_00040] SOME/IP protocol shall support providing the length of a serialized data element in the payload
Description: SOME/IP protocol shall support providing the overall length of a serialized data element in the payload without the need of parsing the content of the element.
Rationale: The length information can be used to determine the start of the following serialized data element without parsing data or knowing the internal structure.
Use Case: Backward compatible extension of structs by adding additional elements at the end.
[RS_SOMEIP_00050] SOME/IP protocol shall support serialization of extensible
Description: SOME/IP shall support serialization of structs with tagged data elements in order to support optional elements and easy extensibility of an interface definition. The tags serve as identifiers for the individual element. An additional length field allows that during deserialization unknown elements can be skipped.
Rationale: Allow compact transmission of complex data structures with optional elements, allow compatible extension of existing interfaces without recompilation of existing code.
Use Case: Serialization of Structured Datatypes with Identifier and optional Members.
document history
ver. 0.01 20200203
ver. 0.02 add items 20200204 morning
ver. 0.03 all requirements 20200205 noon
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.