AUTOSARがわかりにくい点は、いくつかある。
WTO/TBT協定に基づけば、ISO,IEC, ITUに基づいた規格であれば、
非関税障壁にならないようにするのが容易である。
また、特許条項があり、どの規格は、どの関係者がどういう特許を持っているかがわかり易い。
国際以外の規格は国際規格との違いとその理由を記述することにより、
非関税障壁にならないような工夫をするとよい。
Some/IPは、ISO 27315-2で規定している。AUTOSARで参照せずに、重複して規定している背景を存じ上げていない。
@hori-takeshi さんからのご指摘にあるように、ISOのWebの記述で、ISO 27315-2 では
MiddleWareでなくMiddlewireとなっていた。
あとから出たISO 21111-11では、Middlewareになっている。この記事ではMiddlewareに訂正した。ISOへの連絡は @hori-takeshi さんがしてくださるに違いない。
いいね(LGTM)をくださっていない方のコメントには返事をしない習慣にしています。
ISOの誤植はさすがに反応しないとまずいかもと思い反応させていただきました。
翌日、すぐにいいね（LGTM)をいただきました。ありがとうございます。
ISO 2111-11:2011を追記させていただきました。
service oriented middleware over IP SOME/IP
ISO 17215-2:2014
Road vehicles — Video communication interface for cameras (VCIC) — Part 2: Service discovery and control
https://www.iso.org/standard/59546.html
ISO 21111-11:2021
Road vehicles — In-vehicle Ethernet — Part 11: Application layer to session layer conformance test plans
https://www.iso.org/standard/82193.html
ISO 17215-2:2014
ISO 17215-2 ABSTRACT
ISO 17215-2:2014 specifies how services can be discovered and controlled. This functionality is located mainly in layer 5 of the OSI model. Both discovery and control are implemented using the scalable service oriented middleware over IP (SOME/IP).
The general terminology defined in ISO 17215‑1 is also used in ISO 17215-2:2014.
https://www.iso.org/obp/ui/#iso:std:iso:17215:-2:ed-1:v1:en
ISO 17215-2 Normative Reference
ISO 7498-1, Information processing systems — Open Systems Interconnection — Basic Reference Model: The Basic Model — Part 1
ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
ISO 17215 (all parts), Road vehicles — Video communication interface for cameras (VCIC)
ISO 17215-2 Bibliography
[1] IEEE 754-2008, IEEE Standard for Binary Floating-Point Arithmetic
ISO 17215-2 content
Foreword
Introduction
1 Scope
2 Normative references
3 Terms, definitions, and abbreviated terms
3.1 Terms and definitions
3.2 Abbreviated terms
4 Conventions
5 Overview
5.1 General
5.2 Document overview and structure
5.3 Open Systems Interconnection (OSI) model
5.4 Document reference according to OSI model
6 SOME/IP
6.1 General
6.2 Header
6.3 Wire format
6.4 Parameter serialization
7 Service discovery protocol specification
7.1 General
7.2 Definitions
7.3 General requirements
7.4 Service discovery ECU-internal interface
7.5 Packet format
8 Runtime behaviour
8.1 General
8.2 SD communication
8.3 RPC communication
Bibliography
6. SOME/iP
6.1 General
Service discovery as well as command and control is performed using the Scalable service-Oriented MiddlewarE over IP. SOME/IP is a lightweight RPC protocol that defines an AUTOSAR-compatible method for describing interfaces and marshalling data over automotive Ethernet and IP networks. The basic feature set of the SOME/IP wire format is already supported by AUTOSAR. This allows AUTOSAR to parse the RPC PDUs and transport the signals to the application.
6.2 Header
This subclause defines the header structure. For interoperability reasons, the header layout shall be identical for all implementations of SOME/IP and is shown in Figure 3.
— The header-fields are presented in transmission order; i.e. the header-fields on the top left are transmitted first. In the following sections, the different header-fields and their usage is being described.
— All RPC header fields shall use network byte order (big endian) [IETF RFC 791].
Figure 3 — General SOME/IP header layout
6.2.1 Message ID [32-bit]
The Message ID is a 32-bit identifier that is used to dispatch the RPC call to the method of an application and to identify an event.
The assignment of the Message ID is up to the user. The next section describes how to structure the Message IDs in order to ease the organization of Message IDs.
— The Message ID shall uniquely identify a method or an event and the format of its associated PDUs.
In order to structure the different methods and events, they are clustered into services. Services have a set of methods and events as well as a Service ID, which is used for exactly one service. Events are in addition clustered into event groups, which simplify the subscription for multiple events.
— The message ID for RPC calls shall consist of a 16-bit Service ID (high bytes) and a 16-bit Method ID (low bytes).
— The Service ID and the Method ID shall be defined in the interface specification.
— The highest bit of the Event ID shall always be one.
This scheme allows for up to 65536 services with up to 32767 methods and 32767 events each.
— The message ID for events shall consist of a 16-bit Service ID (high bytes) and a 16-bit Notification ID (low bytes).
— The Event group ID and Event ID shall be specified in the interface specification.
— The highest bit of the Event group ID shall always be one.
6.2.2 Length [32-bit]
Length is a field of 32 bits containing the length (in bytes) of the payload, beginning with the Request ID/Client ID and ending with the end of the SOME/IP message. The length does not include the Message.
6.2.3 Request ID [32-bit]
The Request ID allows a client to differentiate multiple calls to the same method.
— The Request ID shall be unique for a single client and server combination.
— When generating a response message, the server shall copy the Request ID from the request to the response message. This allows the client to map a response to the issued request even with more than one request outstanding.
The Request ID needs to be restructured.
— The Request ID shall consist of a 16-bit Client ID (high bytes) and a 16-bit Session ID (low bytes).
The Client ID is the unique identifier for the calling client inside the ECU. The Session ID is a unique identifier chosen by the client for each call.
— The Client ID within each ECU shall be configured by the manufacturer.
— If no response to a message is expected, e.g. for events or notifications, the Session ID shall be set to 0x0000.
— If response messages are expected the Session ID shall be incremented for each method call within the same life cycle (starting with 0x0001, also after wrapping).
— The client shall be responsible for invalidating responses to outdated requests if necessary.
6.2.4 Protocol version [8-bit]
Protocol version is an 8-bit field containing the SOME/IP protocol version.
— The protocol version shall be set to 0x01.
6.2.5 Interface major version [8-bit]
Interface major version is an 8-bit field that contains the major version of the service interface. This is required to catch mismatches in service definitions and allow debugging tools to identify the service interface used (see ISO 17215-3).
6.2.6 Message type [8-bit]
The message type field is used to differentiate between different types of messages.
— The message type shall be set to one of the values listed in Table 2.
— A REQUEST shall be answered by a RESPONSE if no error occurred.
— A REQUEST shall be answered by an ERROR if errors occurred.
— A REQUEST_NO_RETURN, a NOTIFICATION or any ACK message shall not be answered.
Table 2 — SOME/IP Message types
Number Value Description
0x00 REQUEST A request expecting a response (even void)
0x01 REQUEST_NO_RETURN A fire and forget request (client to server)
0x02 NOTIFICATION A notification/event callback expecting no response (server to client)
(0x40) REQUEST ACK Acknowledgement for REQUEST (optional)
(0x41) REQUEST_NO_RETURN ACK Acknowledgement for REQUEST_NO_RETURN (optional)
(0x42) NOTIFICATION ACK Acknowledgement for NOTIFICATION (optional)
0x80 RESPONSE The response message
0x81 ERROR The response containing an error
(0xC0) RESPONSE ACK Acknowledgement for RESPONSE (optional)
(0xC1) ERROR ACK Acknowledgement for ERROR (optional)
Acknowledgement messages (ACK) may be used in cases where the transport protocol (i.e. UDP) does not guarantee message delivery.
All ACKs are optional and do not need to be implemented.
6.2.7 Return code [8-bit]
The return code is used to signal whether a request was processed successfully. For simplification of the header layout, every message transports the field, whether it is applicable or not.
— Response messages (message type 0x80) shall use the return code field to transmit a return code to the request they answer.
— Error messages (message type 0x81) shall use the return code field to transmit a return code to the request they answer, but shall not use the return code 0x00.
— Acknowledgement messages shall reuse the return code of the message they acknowledge.
— All other messages shall set the return code field to 0x00.
— The return codes are based on an 8-bit Std_returnType of AUTOSAR. The two most significant bits are reserved and shall be set to zero (0). The receiver of a return code shall ignore the values of the two most significant bits.
— The currently defined return codes are listed in Table 3 and shall be implemented as described.
Table 3 — SOME/IP return codes
ID Name Description
0x00 E_OK No error occurred
0x01 E_NOT_OK An unspec
ISO 21111-11:2021 Road vehicles — In-vehicle Ethernet — Part 11: Application layer to session layer conformance test plans
ISO 21111-11 ABSTRACT
This document specifies in-vehicle Ethernet application layer, presentation layer, and session layer conformance test plans (CTP) for electronic control units (ECUs). This document is a collection of all conformance test cases which are recommended to be considered for automotive use and should be referred by car manufacturers within their quality control processes.
The document specifies the scalable Service-Oriented MiddlewarE over Internet Protocol (SOME/IP) and Dynamic Host Configuration Protocol (DHCP) version 4 conformance test cases.
ISO 21111-11 Contents
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Symbols and abbreviated terms
4.1 Symbols
4.2 Abbreviated terms
5 Conventions
6 CTP test system set-up and CTC structure
6.1 General
6.2 Test system set-up
6.3 CTC definition
6.4 Terminology used in CTCs
6.5 IUT prerequisites – TCP/IP TestStub
6.5.1 General
6.5.2 TCP/IP TestStub methods (service primitives)
6.5.3 Result codes
6.6 IUT prerequisites – SOME/IP TestStub
6.6.1 General
6.6.2 SOME/IP TestStub methods
6.6.3 SOME/IP TestStub events and fields.
6.6.4 ETS service interface description
7 Application, presentation, and session layers CTCs
7.1 AL – SOME/IP
7.1.1 General
7.1.2 Referenced specification
7.1.3 Test system topology – AL – SOME/IP, serialisation, and service discovery
7.1.4 Test system topology and related CTC configuration
7.1.5 SOME/IP parameters used in CTCs
7.1.6 SOME/IP server CTCs
7.1.7 SOME/IP ETS CTCs .
7.2 SL – Dynamic host configuration protocol version 4 (DHCPv4) client
7.2.1 General
7.2.2 Referenced specification
7.2.3 Test system topology – SL – DHCPv4 client
7.2.4 Test system topology with two interfaces in the IUT
7.2.5 Test system topology and related CTC configuration
7.2.6 DHCPv4 parameters and constants used in CTCs
7.2.7 DHCPv4 client CTCs
Bibliography
ISO 21111-11 Normative Reference
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing methodology and framework — Part 1: General concepts
ISO 21111-1, Road vehicles — In-vehicle Ethernet — Part 1: General information and definitions
ISO 21111-11 Bibliography
[1] ISO/IEC 7498-1:1994, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model
[2] ISO/IEC/IEEE 8802-3:2021, Telecommunications and exchange between information technology systems — Requirements for local and metropolitan area networks — Part 3: Standard for Ethernet
[3] ISO/IEC 9646 (all parts), Information technology — Open Systems Interconnection — Conformance testing methodology and framework
[4] ISO/IEC 10731:1994, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services
[5] ISO 21111-6, Road vehicles — In-vehicle Ethernet — Part 6: Electrical 100-Mbit/s physical entity requirements and conformance test plan
[6] ISO 21111-7, Road vehicles — In-vehicle Ethernet — Part 7: Electrical 100-Mbit/s PHY layer network system specification and interoperability test plan
[7] ISO 21111-8, Road vehicles — In-vehicle Ethernet — Part 8: Electrical 100-Mbit/s component requirements and test methods
[8] IEC 62228-5, Integrated circuits – EMC evaluation of transceivers – Part 5 Ethernet transceivers
[9] AUTOSAR, SOME/IP Protocol Specification, FO Release 1.3.01
https://www.autosar.org/fileadmin/user_upload/standards/foundation/1-3/AUTOSAR_PRS_SOMEIPProtocol.pdf.
[10] AUTOSAR, Specification of Service Discovery, V1.2.0, R4.1 Rev 32
https://www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_SWS_ServiceDiscovery.pdf.
[11] AUTOSAR, SOME/IP Example for a Serialization Protocol, V1.1.0 R4.1 Rev 33
https://www.autosar.org/fileadmin/user_upload/standards/classic/4-1/AUTOSAR_TR_SomeIpExample.pdf.
[12] AUTOSAR, Testability Protocol and Service Primitives, TC Release 1.2.04
https://www.autosar.org/fileadmin/user_upload/standards/tests/1-2/AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf.
[13] AUTOSAR, SOME/IP Service Discovery Protocol Specification, FO Release V1.3.05
https://www.autosar.org/fileadmin/user_upload/standards/foundation/1-3/AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf.
[14] RFC 2131:1997, Dynamic Host Configuration Protocol6 https://tools.ietf.org/html/[rfc2131.
ISO 17215-2 v.s. AUTOSAR
| ISO 17215-2:2014 | AUTOSAR 696 SOME/IP Protocol Specification | ||
|---|---|---|---|
| 6 | SOME/IP | 4 | Specification of SOME/IP Message Format (Serialization) |
| 6.2.1 | Message ID [32-bit] | 4.1.2.1 | Message ID [32 Bit] |
| 4.1.2.2 | Method ID [15 Bit] | ||
| 4.1.2.3 | Event ID [15 Bit] | ||
| 6.2.2 | Length [32-bit] | 4.1.2.4 | Length [32 Bit] |
| 6.2.3 | Request ID [32-bit] | 4.1.2.5 | Request ID [32 Bit] |
| 6.2.4 | Protocol version [8-bit] | 4.1.2.6 | Protocol Version [8 Bit] |
| 6.2.5 | Interface major version [8-bit] | 4.1.2.7 | Interface Version [8 Bit] |
| 6.2.6 | Message type [8-bit] | 4.1.2.8 | Message Type [8 Bit] |
| 6.2.7 | Return code [8-bit] | 4.1.2.9 | Return Code [8 Bit] |
なぜ、ISOで決めていることを、ISOを参照せずにAUTOSARで決めているか理由がわかっていない。Method IDとEvent IDはMessage IDの一部であれば、同じ並びの項目として規定しているのは違和感があるかもしれない。
ISO 21111-11が、ISO SO 27315-2を参照していない理由がわかっていない。
AUTOSAR
660 Specification of SOME/IP Transformer
696 SOME/IP Protocol Specification
800 Requirements on SOME/IP Protocol
801 Requirements on SOME/IP Service Discovery Protocol
802 SOME/IP Service Discovery Protocol Specification
809 Specification on SOME/IP Transport Protocol
参考資料
some-ip.com
自己参照
Requirements on SOME/IP Protocol AUTOSAR (19-11)
https://qiita.com/kaizen_nagoya/items/29e9889061b5314af173
SOME/IP 特許
https://qiita.com/kaizen_nagoya/items/22a1d5380fbf7256fdb0
文書履歴(document history)
ver. 0.01 初稿 20220523
ver. 0.02 ISO 21111-11追記。ISO サイトの誤植訂正。20220524
ver. 0.03 AUTOSAR CP: 809 Specification on SOME/IP Transport Protocol 追記 20220525
ver 0.04 someip.com 追記 2-22-526
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.