SOME/IP Protocol Specification - AUTOSAR
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0Document TitleSOME/IP Protocol SpecificationDocument OwnerAUTOSARDocument ResponsibilityAUTOSARDocument Identification No696Document ClassificationStandardDocument StatusFinalPart of AUTOSAR StandardFoundationPart of Standard Release1.0.0Document Change HistoryDateRelease2016-11-301.0.01 of 50Changed byAUTOSARReleaseManagementDescriptionInitial ReleaseDocument ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0DisclaimerThis specification and the material contained in it, as released by AUTOSAR, is for thepurpose of information only. AUTOSAR and the companies that have contributed to itshall not be liable for any use of the specification.The material contained in this specification is protected by copyright and other types ofIntellectual Property Rights. The commercial exploitation of the material contained inthis specification requires a license to such Intellectual Property Rights.This specification may be utilized or reproduced without any modification, in any formor by any means, for informational purposes only. For any other purpose, no part ofthe specification may be utilized or reproduced, in any form or by any means, withoutpermission in writing from the publisher.The AUTOSAR specifications have been developed for automotive applications only.They have neither been developed, nor tested for non-automotive applications.The word AUTOSAR and the AUTOSAR logo are registered trademarks.Advice for usersAUTOSAR specifications may contain exemplary items (exemplary reference models,"use cases", and/or references to exemplary technical solutions, devices, processes orsoftware).Any such exemplary items are contained in the specifications for illustration purposesonly, and they themselves are not part of the AUTOSAR Standard. Neither their presence in such specifications, nor any later documentation of AUTOSAR conformance ofproducts actually implementing such exemplary items, imply that intellectual propertyrights covering such exemplary items are licensed under the same rules as applicableto the AUTOSAR Standard.2 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0Table of Contents1 Introduction and overview1.11.2Protocol purpose and objectives . . . .Applicability of the protocol . . . . . . .1.2.1Constraints and assumptions1.2.2Limitations . . . . . . . . . .1.3Dependencies . . . . . . . . . . . . . .1.4Document Structure . . . . . . . . . .5.2 Protocol Requirements2.15556668Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . .83 Acronyms and Abbreviations134 Protocol specification144.1Specification of SOME/IP on wire-format (Serialization) . . .4.1.1Header . . . . . . . . . . . . . . . . . . . . . . . .4.1.1.1Message ID [32 Bit] . . . . . . . . . . . .4.1.1.2Length [32 Bit] . . . . . . . . . . . . . . .4.1.1.3Request ID [32 Bit] . . . . . . . . . . . . .4.1.1.4Protocol Version [8 Bit] . . . . . . . . . . .4.1.1.5Interface Version [8 Bit] . . . . . . . . . .4.1.1.6Message Type [8 Bit] . . . . . . . . . . . .4.1.1.7Return Code [8 Bit] . . . . . . . . . . . . .4.1.1.8Payload [variable size] . . . . . . . . . . .4.1.2Event, Field and Eventgroup . . . . . . . . . . . .4.1.3Endianess . . . . . . . . . . . . . . . . . . . . . .4.1.4Serialization of Data Structures . . . . . . . . . . .4.1.4.1Basic Datatypes . . . . . . . . . . . . . .4.1.4.2Structured Datatypes (structs) . . . . . . .4.1.4.3Strings . . . . . . . . . . . . . . . . . . . .4.1.4.4Arrays (fixed length) . . . . . . . . . . . .4.1.4.5Dynamic Length Arrays . . . . . . . . . .4.1.4.6Enumeration . . . . . . . . . . . . . . . .4.1.4.7Bitfield . . . . . . . . . . . . . . . . . . . .4.1.4.8Union / Variant . . . . . . . . . . . . . . .4.2Specification of SOME/IP Protocol . . . . . . . . . . . . . .4.2.1Transport Protocol Bindings . . . . . . . . . . . . .4.2.1.1UDP Binding . . . . . . . . . . . . . . . .4.2.1.2TCP Binding . . . . . . . . . . . . . . . .4.2.1.3Multiple Service-Instances . . . . . . . . .4.2.1.4Transporting large SOME/IP messages(SOME/IP-TP) . . . . . . . . . . . . . . .4.2.2Request/Response Communication . . . . . . . .4.2.3Fire&Forget Communication . . . . . . . . . . . .3 of 50.of. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .UDP. . . . . . . . . 931323839Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.04.2.4Notification Events . . . . . . . . . . . . . . . . . . . . . . . .4.2.4.1Strategy for sending notifications . . . . . . . . . . .4.2.5Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.2.6Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . .4.2.6.1Return Code . . . . . . . . . . . . . . . . . . . . . .4.2.6.2Error Message . . . . . . . . . . . . . . . . . . . . .4.2.6.3Error Processing Overview . . . . . . . . . . . . . .4.2.6.4Communication Errors and Handling of Communication Errors . . . . . . . . . . . . . . . . . . . . . . . .40414142424344465 Configuration Parameters476 Protocol usage and guidelines486.16.26.3Choosing the transport protocol . . . . . . . . . . . . . . . . . . . . . .Transporting CAN and FlexRay Frames . . . . . . . . . . . . . . . . . .Insert Padding for structs . . . . . . . . . . . . . . . . . . . . . . . . . .7 References4 of 5048484950Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.01Introduction and overviewThis protocol specification specifies the format, message sequences and semantics of the AUTOSAR Protocol "Scalable service-Oriented MiddlewarE over IP(SOME/IP)".SOME/IP is an automotive/embedded communication protocol which supports remoteprocedure calls, event notifications and the underlying serialization/wire format. Theonly valid abbreviation is SOME/IP. Other abbreviations (e.g. Some/IP) are wrong andshall not be used.1.1Protocol purpose and objectivesThe basic motivation to specify "Yet another RPC-Mechanism" instead of using anexisting infrastructure/technology is the goal to have a technology that: Fulfills the hard requirements regarding resource consumption in an embeddedworld Is compatible through as many use-cases and communication partners as possible compatible with AUTOSAR at least on the wire-format level; i.e. can communicate with PDUs AUTOSAR can receive and send without modification to theAUTOSAR standard. The mappings within AUTOSAR shall be chosen accordingto the SOME/IP specification. Provides the features required by automotive use-cases Is scalable from tiny to large platforms1.2Applicability of the protocolSOME/IP shall be implemented on different operating system (i.e. AUTOSAR, GENIVI,and OSEK) and even embedded devices without operating system. SOME/IP shall beused for inter-ECU Client/Server Serialization. An implementation of SOME/IP allowsAUTOSAR to parse the RPC PDUs and transport the signals to the application.1.2.1Constraints and assumptionsThis document specifies the SOME/IP protocol on network level. It was created duringelaboration of the AUTOSAR Foundation Standard 1.0.0 which took place in parallelto the development of the AUTOSAR Classic Standard 4.3.0. It already reflects allchanges implied to SOME/IP by the work which was done for AUTOSAR Classic5 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0Standard 4.3.0.Therefore the SOME/IP protocol specified here is not fully backward-compatible to theSOME/IP protocol used in AUTOSAR Classic Standard 4.2.2. The most importantdifferences are: Unicode strings are always preceded by a BOM (see Chapter 4.1.4.3)The older version was not consistent with respect to the usage of BOMs. The current version of SOME/IP mandates that every unicode string starts with a BOM.Everything else is no string but an array of uint8, uint16 or uint32 elements. Message Types have been changed (see [PRS SOMEIP 00055] and Table 4.4):Thetypesforacknowledgements(REQUEST ACK,REQUEST NO RETURN ACK, NOTIFICATION ACK, RESPONSE ACK andERROR ACK) were completely removed because they were defined but neverused in the protocol. Segmentation functionality (SOME/IP-TP) was introduced (see Chapter 4.2.1.4):Large data ( 1400 Bytes) can now be transferred via UDP. SOME/IP-TP cansegment larger data into small chunks which can be transferred via UDP andreassembled at receiver side.1.2.2LimitationsThis document gives a holistic overview over SOME/IP but doesn’t state any requirements towards any implementation of BSW modules.Please be aware that not all parts of SOME/IP may be implemented in AUTOSAR.1.3DependenciesThere are no dependencides to AUTOSAR SWS modules.1.4Document StructureThe SOME/IP PRS will describe the following two aspects of SOME/IP.Specification of SOME/IP on wire-format (Serialization) Structure of Header Format How the different data types are serialized as per SOME/IPSpecification of Protocol for Event and RPC-based communication Transport Protocol6 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0 Rules that govern the RPC for SOME/IP7 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.02Protocol Requirements2.1Requirements TraceabilityFeature[RS SOMEIP 00004][RS SOMEIP 00006][RS SOMEIP 00007]DescriptionSOME/IP protocol shall supportevent communicationSOME/IP protocol shall supportuni-directional RPC communicationSOME/IP protocol shall supportbi-directional RPC communication[RS SOMEIP 00008]SOME/IP protocol shall supporterror handling of RPCcommunication[RS SOMEIP 00009]SOME/IP protocol shall supportfield communication8 of 50Satisfied by[PRS SOMEIP 00925][PRS SOMEIP 00926][PRS SOMEIP 00171][PRS SOMEIP 00924][PRS SOMEIP 00920][PRS SOMEIP 00921][PRS SOMEIP 00922][PRS SOMEIP 00923][PRS SOMEIP 00927][PRS SOMEIP 00928][PRS SOMEIP 00187][PRS SOMEIP 00188][PRS SOMEIP 00189][PRS SOMEIP 00190][PRS SOMEIP 00191][PRS SOMEIP 00195][PRS SOMEIP 00537][PRS SOMEIP 00539][PRS SOMEIP 00576][PRS SOMEIP 00614][PRS SOMEIP 00901][PRS SOMEIP 00902][PRS SOMEIP 00903][PRS SOMEIP 00904][PRS SOMEIP 00905][PRS SOMEIP 00910][PRS SOMEIP 00179][PRS SOMEIP 00180][PRS SOMEIP 00181][PRS SOMEIP 00182][PRS SOMEIP 00183][PRS SOMEIP 00909]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0[RS SOMEIP 00010]9 of 50SOME/IP protocol shall supportdifferent transport protocolsunderneath[PRS SOMEIP 00137][PRS SOMEIP 00138][PRS SOMEIP 00139][PRS SOMEIP 00140][PRS SOMEIP 00141][PRS SOMEIP 00142][PRS SOMEIP 00154][PRS SOMEIP 00160][PRS SOMEIP 00535][PRS SOMEIP 00706][PRS SOMEIP 00707][PRS SOMEIP 00708][PRS SOMEIP 00709][PRS SOMEIP 00710][PRS SOMEIP 00711][PRS SOMEIP 00720][PRS SOMEIP 00721][PRS SOMEIP 00722][PRS SOMEIP 00723][PRS SOMEIP 00724][PRS SOMEIP 00725][PRS SOMEIP 00726][PRS SOMEIP 00727][PRS SOMEIP 00728][PRS SOMEIP 00729][PRS SOMEIP 00730][PRS SOMEIP 00731][PRS SOMEIP 00732][PRS SOMEIP 00733][PRS SOMEIP 00734][PRS SOMEIP 00735][PRS SOMEIP 00736][PRS SOMEIP 00738][PRS SOMEIP 00740][PRS SOMEIP 00741][PRS SOMEIP 00742][PRS SOMEIP 00743][PRS SOMEIP 00744][PRS SOMEIP 00745][PRS SOMEIP 00746][PRS SOMEIP 00747][PRS SOMEIP 00748][PRS SOMEIP 00749][PRS SOMEIP 00750][PRS SOMEIP 00751][PRS SOMEIP 00752][PRS SOMEIP 00753][PRS SOMEIP 00754]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0[RS SOMEIP 00011]SOME/IP protocol shall supportmessages of different lengths[RS SOMEIP 00026]SOME/IP protocol shall define theendianness of header and payload10 of 50[PRS SOMEIP 00162][PRS SOMEIP 00163][PRS SOMEIP 00720][PRS SOMEIP 00721][PRS SOMEIP 00722][PRS SOMEIP 00723][PRS SOMEIP 00724][PRS SOMEIP 00725][PRS SOMEIP 00726][PRS SOMEIP 00727][PRS SOMEIP 00728][PRS SOMEIP 00729][PRS SOMEIP 00730][PRS SOMEIP 00731][PRS SOMEIP 00732][PRS SOMEIP 00733][PRS SOMEIP 00734][PRS SOMEIP 00735][PRS SOMEIP 00736][PRS SOMEIP 00738][PRS SOMEIP 00740][PRS SOMEIP 00741][PRS SOMEIP 00742][PRS SOMEIP 00743][PRS SOMEIP 00744][PRS SOMEIP 00745][PRS SOMEIP 00746][PRS SOMEIP 00747][PRS SOMEIP 00748][PRS SOMEIP 00749][PRS SOMEIP 00750][PRS SOMEIP 00751][PRS SOMEIP 00752][PRS SOMEIP 00753][PRS SOMEIP 00754][PRS SOMEIP 00368][PRS SOMEIP 00369]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0[RS SOMEIP 00027]SOME/IP protocol shall define theheader layout of messages[RS SOMEIP 00028]SOME/IP protocol shall specify theserialization algorithm for data[RS SOMEIP 00030]SOME/IP protocol shall supporttransporting integer data typesSOME/IP protocol shall supporttransporting boolean data typeSOME/IP protocol shall supporttransporting float data typesSOME/IP protocol shall supporttransporting structured data types[RS SOMEIP 00031][RS SOMEIP 00032][RS SOMEIP 00033]11 of 50[PRS SOMEIP 00030][PRS SOMEIP 00031][PRS SOMEIP 00034][PRS SOMEIP 00035][PRS SOMEIP 00038][PRS SOMEIP 00040][PRS SOMEIP 00042][PRS SOMEIP 00043][PRS SOMEIP 00044][PRS SOMEIP 00046][PRS SOMEIP 00052][PRS SOMEIP 00053][PRS SOMEIP 00055][PRS SOMEIP 00058][PRS SOMEIP 00365][PRS SOMEIP 00366][PRS SOMEIP 00367][PRS SOMEIP 00521][PRS SOMEIP 00533][PRS SOMEIP 00701][PRS SOMEIP 00702][PRS SOMEIP 00703][PRS SOMEIP 00704][PRS SOMEIP 00739][PRS SOMEIP 00063][PRS SOMEIP 00569][PRS SOMEIP 00611][PRS SOMEIP 00612][PRS SOMEIP 00613][PRS SOMEIP 00065][PRS SOMEIP 00615][PRS SOMEIP 00065][PRS SOMEIP 00615][PRS SOMEIP 00065][PRS SOMEIP 00615][PRS SOMEIP 00077][PRS SOMEIP 00079][PRS SOMEIP 00300][PRS SOMEIP 00370][PRS SOMEIP 00371][PRS SOMEIP 00705][PRS SOMEIP 00712][PRS SOMEIP 00900]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0[RS SOMEIP 00034]SOME/IP protocol shall supporttransporting union data types[RS SOMEIP 00035]SOME/IP protocol shall supporttransporting one-dimensional andmulti-dimensional array data typesSOME/IP protocol shall supporttransporting array data types with afixed length[RS SOMEIP 00036][RS SOMEIP 00037]SOME/IP protocol shall supporttransporting array data types withflexible length[RS SOMEIP 00038]SOME/IP protocol shall supporttransporting string types with a fixedlength[RS SOMEIP 00039]SOME/IP protocol shall supporttransporting string data types withflexible length[RS SOMEIP 00051]SOME/IP protocol shall providesupport for segmented transmissionof large data12 of 50[PRS SOMEIP 00118][PRS SOMEIP 00119][PRS SOMEIP 00121][PRS SOMEIP 00122][PRS SOMEIP 00123][PRS SOMEIP 00126][PRS SOMEIP 00127][PRS SOMEIP 00129][PRS SOMEIP 00130][PRS SOMEIP 00906][PRS SOMEIP 00907][PRS SOMEIP 00908][PRS SOMEIP 00915][PRS SOMEIP 00916][PRS SOMEIP 00099][PRS SOMEIP 00101][PRS SOMEIP 00099][PRS SOMEIP 00101][PRS SOMEIP 00917][PRS SOMEIP 00918][PRS SOMEIP 00107][PRS SOMEIP 00114][PRS SOMEIP 00375][PRS SOMEIP 00376][PRS SOMEIP 00377][PRS SOMEIP 00919][PRS SOMEIP 00084][PRS SOMEIP 00085][PRS SOMEIP 00086][PRS SOMEIP 00087][PRS SOMEIP 00372][PRS SOMEIP 00373][PRS SOMEIP 00374][PRS SOMEIP 00911][PRS SOMEIP 00912][PRS SOMEIP 00913][PRS SOMEIP 00914][PRS SOMEIP 00089][PRS SOMEIP 00090][PRS SOMEIP 00091][PRS SOMEIP 00092][PRS SOMEIP 00093][PRS SOMEIP 00094][PRS SOMEIP 00095][PRS SOMEIP 00367]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.03Acronyms and AbbreviationsThe glossary below includes acronyms and abbreviations relevant to the SOME/IPspecification that are not included in the [1, AUTOSAR glossary].Abbreviation / Acronym:MethodParametersRemote Procedure Call (RPC)RequestResponseRequest/Response communicationEventFieldNotification EventGetterSetterNotifierServiceService InterfaceEventgroupService InstanceServerClientFire and ForgetUnionDescription:A method, procedure, function, or subroutine that is called/invoked.input, output, or input/output arguments of a method or an eventA method call from one ECU to another that is transmitted usingmessagesa message of the client to the server invoking a methoda message of the server to the client transporting results of amethod invocationa RPC that consists of request and responseA uni-directional data transmission that is only invoked onchanges or cyclically and is sent from the producer of data tothe consumers.A field does represent a status and thus has an valid value at alltimes on which getter, setter and notifier act upon.An event message of the notifier of a field.A Request/Response call that allows read access to a field.A Request/Response call that allows write access to a field.Sends out event message with a new value on change of thevalue of the field.A logical combination of zero or more methods, zero or moreevents, and zero or more fields.the formal specification of the service including its methods,events, and fieldsA logical grouping of events and notification events of fields insidea service in order to allow subscriptionImplementation of a service, which can exist more than once inthe vehicle and more than once on an ECUThe ECU offering a service instance shall be called server in thecontext of this service instance.The ECU using the service instance of a server shall be calledclient in the context of this service instance.Requests without response message are called fire&forget.A data structure that dynamically assumes different data types.Table 3.1: Acronyms and Abbreviations13 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.04Protocol specificationSOME/IP provides service oriented communication over a network. It is based onservice definitions that list the functionality that the service provides. A service canconsist of combinations of zero or multiple events, methods and fields.Events provide data that are sent cyclically or on change from the provider to the subscriber.Methods provide the possibility to the sbscriber to issue remote procedure calls whichare executed on provider side.Fields are combinations of one or more of the following three a notifier which sends data on change from the provider to the subscribers a getter which can be called by the subscriber to explicitely query the provider forthe value a setter which can be called by the subscriber when it wants to change the valueon provider sideThe major difference between the notifier of a field and an event is that evetns areonly sent on change, the notifier of a filed additionally sends the data directly aftersubscription.4.1Specification of SOME/IP on wire-format (Serialization)Serialization describes the way data is represented in protocol data units (PDUs) aspayload of either UDP or TCP messages, transported over an IP-based automotivein-vehicle network.4.1.1Header[PRS SOMEIP 00030] d14 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0The structure of header layout is as shown in the Figure 4.1. c(RS SOMEIP 00027)Figure 4.1: SOME/IP Header Format[PRS SOMEIP 00031] d For interoperability reasons the header layout shall be identical for all implementations of SOME/IP. The fields are presented in transmission orderi.e. the fields on the top left are transmitted first. c(RS SOMEIP 00027)4.1.1.1Message ID [32 Bit][PRS SOMEIP 00034] d The Message ID shall be a 32 Bit identifier that is usedto identify the RPC call to a method of an application or to identify an event. c(RS SOMEIP 00027)[PRS SOMEIP 00035] d The assignment of the Message ID shall be up to the user.However, the Message ID shall be unique for the whole system (i.e. the vehicle). TheMessage ID is similar to a CAN ID and should be handled via a comparable process.c(RS SOMEIP 00027)[PRS SOMEIP 00038] d Message IDs of method calls shall be structured in the IDwith 216 services with 215 methods as shown in Table 4.1c(RS SOMEIP 00027)Service ID [16 Bit]0 [1 Bit]Method ID [last 15 Bit]Table 4.1: Structure of ID4.1.1.2Length [32 Bit][PRS SOMEIP 00042] d Length field shall contain the length in Byte starting fromRequest ID/Client ID until the end of the SOME/IP message. c(RS SOMEIP 00027)15 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.04.1.1.3Request ID [32 Bit]The Request ID allows a provider and subscriber to differentiate multiple parallel usesof the same method, event, getter or setter.[PRS SOMEIP 00043] d The Request ID shall be unique for a provider- andsubscriber-combination (i.e. one subscription) only. c(RS SOMEIP 00027)[PRS SOMEIP 00704] d When generating a response message, the providershall copy the Request ID from the request to the response message.c(RS SOMEIP 00027) Note:This allows the subscriber to map a response to the issued request even with morethan one request outstanding.[PRS SOMEIP 00044] d Request IDs must not be reused until the response is arrivedor is not expected to arrive anymore (timeout). c(RS SOMEIP 00027)4.1.1.3.1Structure of the Request ID[PRS SOMEIP 00046] d In AUTOSAR the Request ID shall be constructed of theClient ID and Session ID as shown in Table 4.2c(RS SOMEIP 00027)Client ID [16 Bits]Session ID [16 Bits]Table 4.2: Structure of Request IDNote:This means that the implementer of an ECU can define the Client-IDs as required byhis implementation and the provider does not need to know this layout or definitionsbecause he just copies the complete Request-ID in the response.[PRS SOMEIP 00702] d The Client ID is the unique identifier for the calling clientinside the ECU. The Client ID allows an ECU to differentiate calls from multiple clientsto the same method. c(RS SOMEIP 00027)[PRS SOMEIP 00703] d The Session ID is a unique identifier chosen by the subscribers for each call. The Session ID allows a subscriber to differentiate multiple callsto the same method. c(RS SOMEIP 00027)[PRS SOMEIP 00532] d The Client ID shall also support being unique in the overall vehicle by having a configurable prefix or fixed value (e.g. the most significantbyte of Client ID being the diagnostics address or a configured Client ID for a givenapplication/SW-C). c()For example:Client ID Prefix [8Bits]16 of 50Client ID [8 Bits]Session ID [16 Bits]Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0Table 4.3: Example of Client ID[PRS SOMEIP 00533] d Request/Response methods shall use session handlingwith Session IDs.Session ID should be incremented after each call.c(RS SOMEIP 00027)[PRS SOMEIP 00521] d When the Session ID reaches 0xFFFF, it shall wrap aroundand start again. c(RS SOMEIP 00027)[PRS SOMEIP 00739] d A subscriber has to ignore a reponse if the session id ofreponse does not equal the session id of request. c(RS SOMEIP 00027)4.1.1.4Protocol Version [8 Bit][PRS SOMEIP 00052] d Protocol Version shall be an 8 Bit field containing theSOME/IP protocol version. c(RS SOMEIP 00027)4.1.1.5Interface Version [8 Bit][PRS SOMEIP 00053] d Interface Version shall be an 8 Bit field that contains theMajor Version of the Service Interface. c(RS SOMEIP 00027)4.1.1.6Message Type [8 Bit][PRS SOMEIP 00055] d The Message Type field is used to differentiate differenttypes of messages and shall contain the following values as shown in Table 4.4c(RS SOMEIP 00027)Number0x00ValueREQUEST0x010x02REQUEST NO RETURNNOTIFICATION0x800x810x20RESPONSEERRORTP REQUEST0x210x22TP REQUEST NO RETURNTP NOTIFICATION0x230x24TP RESPONSETP ERROR17 of 50DescriptionA request expecting a response (evenvoid)A fire&forget requestA request of a notification/event callbackexpecting no responseThe response messageThe response containing an error)A TP request expecting a response (evenvoid)A TP fire&forget requestA TP request of a notification/event callback expecting no responseThe TP response messageThe TP response containing an error)Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0Table 4.4: Message Types[PRS SOMEIP 00701] d Regular request (message type 0x00) shall be answered bya response (message type 0x80), when no error occurred. If errors occur an errormessage (message type 0x81) shall be sent. c(RS SOMEIP 00027)It is also possible to send a request that does not have a response message (message type 0x01). For updating values through notification a callback interface exists(message type 0x02).[PRS SOMEIP 00367] d The 3rd highest bit of the Message Type ( 0x20) shall becalled TP-Flag and shall be set to 1 to signal that the current SOME/IP message is asegment. The other bits of the Message Type are set as specified in this Section. c(RS SOMEIP 00027, RS SOMEIP 00051) Note:Segments of the Message Type Request (0x00) have the Message Type (0x20), segments of the Message Type Response (0x80) have the Message Type (0xa0), and soon. For details see (Chapter 4.2.1.4)4.1.1.7Return Code [8 Bit][PRS SOMEIP 00058] d The Return Code shall be used to signal whether a requestwas successfully processed. For simplification of the header layout, every messagetransports the field Return Code. The allowed Return Codes for specific messagetypes are shown in Table 4.5 c(RS SOMEIP 00027)Message TypeREQUESTREQUEST NO RETURNNOTIFICATIONRESPONSEERRORAllowed Return CodesN/A set to 0x00 (E OK)N/A set to 0x00 (E OK)N/A set to 0x00 (E OK)See Return Codes in [PRS SOMEIP 00191]See Return Codes in [PRS SOMEIP 00191]. Shall not be0x00 (E OK).Table 4.5: Allowed Return Codes for spcific Message Types4.1.1.8Payload [variable size]In the payload field the parameters are carried. The serialization of the parameters willbe specified in the following section.The size of the SOME/IP payload field depends on the transport protocol used. WithUDP the SOME/IP payload shall be between 0 and 1400 Bytes. The limitation to 1400Bytes is needed in order to allow for future changes to protocol stack (e.g. changing to18 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0IPv6 or adding security means). Since TCP supports segmentation of payloads, largersizes are automatically supported.Payload might consists of data elements for events or parameters for methods.4.1.2Event, Field and EventgroupEventgroup is a logical grouping of events and notification events of fields inside aservice in order to allow subscription.[PRS SOMEIP 00040] d Events and notifications are transported using RPC, Eventsshall be structured as shown in Table 4.6c(RS SOMEIP 00027)Service ID [16 Bit]1 [1 Bit]Event ID [last 15 Bit]Table 4.6: Structure of Event ID[PRS SOMEIP 00365](RS SOMEIP 00027)dEmptyeventgroupsshallnotbeused.c[PRS SOMEIP 00366] d Events as well as fields are mapped to at least one eventgroup. c(RS SOMEIP 00027)4.1.3Endianess[PRS SOMEIP 00368] d SOME/IP Header shall be encoded in network byte order(big endian). c(RS SOMEIP 00026)[PRS SOMEIP 00369] d The byte order of the parameters inside the payload shall bedefined by configuration. c(RS SOMEIP 00026)4.1.4Serialization of Data StructuresThe serialization is based on the parameter list defined by the interface specification.The interface specification defines the exact position of all data structures in the PDUand has to consider the memory alignment.Alignment is used to align the beginning of data by inserting padding elements afterthe data in order to ensure that the aligned data starts at certain memory addresses.There are processor architectures which can access data more efficiently (i.e. master)when they start at addresses which are multiples of a certain number (e.g multiples of32 Bit).19 of 50Document ID 696: AUTOSAR PRS SOMEIPProtocol— AUTOSAR CONFIDENTIAL —
SOME/IP Protocol SpecificationAUTOSAR FO Release 1.0.0[PRS SOMEIP 00611] d Alignment of data shall be realized by inserting paddingelements between the preceding data and the data that shall be aligned. c(RS SOMEIP 00028)[PRS SOMEIP 00569] d Alignment shall always be calculated from start of SOME/IPmessage. c(RS SOMEIP 00028)[PRS SOMEIP 00612] d There shall be no padding behind fixed length data elementsto ensure alignment of the following data. c(RS SOMEIP 00028)Note:If data behind fixed length data elements shall be padded, this has to be explicitlyconsidered in the data type definition.[PRS SOMEIP 00063] d The serialization shall not try to automatically align datastructures but shall be aligned as specified in the interface specification.c(RS SOMEIP 00028)[PRS SOMEIP 00613] d The alignment of data behind variable length data elementsshall be a multiple of 8, 16 or 32 Bits. c(RS SOMEIP 00028)4.1.4.1Basic Datatypes[PRS SOMEIP 00065] d The following basic datatypes as shown in Table 4.7 shall besupported:c(RS SOMEIP 00030, RS SOMEIP 00031, RS SOMEIP 2float32DescriptionTRUE/FALSE valueunsigned Integerunsigned Integerunsigned Integersigned Integersigned Integersigned Integerfloating point numberSize [bit]8816328163232float64floating point number64RemarkFALSE (0), TRUE (1)IEEE 754 binary32 (Single Precision)IEEE 754 binary64 (Double Precision)Table 4.7: Supported basic Data TypesThe Byte Order is specified for each parameter by configuration.[PRS SOMEIP 00615] d For the evaluation of a Boolean value only the lowestbit of th
SOME/IP Protocol Specification AUTOSAR FO Release 1.0.0 1 Introduction and overview This protocol specification specifies the format, message sequences and seman-tics of the AUTOSAR Protocol "Scalable service-Oriented MiddlewarE over IP (SOME/IP)". SOME/IP is an automotive/embedded comm
AUTOSAR 3.x AUTOSAR 4.x AUTOSAR 3.x is used in serial production projects by: Audi / Volkswagen / Porsche Daimler Fiat / Chrysler Volvo Trucks (incl. Construction Machines) AUTOSAR 4.x is used in serial production projects by: BMW GM Toyota Volvo Cars AUTOSAR 4.x is generally announced by Ford PSA
Simon Fürst, BMW Group Safetronic 2011 8 Nov. 2011, Sheraton Arabellapark Hotel, Munich. 2 8 Nov. 2011 AUTOSAR and Functional Safety . Basic aspects of AUTOSAR architecture and methodology Safety mechanisms supported by AUTOSAR Technical safety concepts supported by AUTOSAR Relationship to ISO 26262 and Conclusion
AUTOSAR User Group, i.e. the Artop User Group . –It is a group of AUTOSAR members and partners, i.e. users of AUTOSAR, with a special interest in AUTOSAR tools. –Was launched in October 2008 and the members currently are: –Continental –Geensys –Peugeot Citroën (PSA)–BMW Car IT –New members are welcome to join the User Group.
Both, Releases 2.0 and 2.1, are in use by several AUTOSAR members for series produc-tions. 2.2. Overview on AUTOSAR Phase II Three releases had been planned for AUTOSAR Phase II, providing a continuous improve-ment of the specifications and introducing new concepts. Release 3.0 was published early 2008 on the AUTOSAR web site [1]. It included a .
2 Introduction to AUTOSAR Simulink approach to AUTOSAR Overview of Modeling SWCs & Modeling Styles AUTOSAR Design Workflows Bottom Up, Top Down & Round Trip Advanced Topics –Top 5 Startup, Reset, and Shutdown Modeling Basic Software (BSW) Access J-MAAB Type B Architectu
Adaptive Environment - The AUTOSAR Adaptive environment for adaptive design AUTOSAR Builder is based on Eclipse and uses Artop. Artop is an open AUTOSAR tool environment that is available for free. It enables you to build your own tools and integrate from other tool vendors. For more details, see the AUTOSAR Builder Overview document. 1.
AUTOSAR 3.x: First specification: 2007 Mature solution used for series production 2010ff Adaptations necessary OEM-specific extensions AUTOSAR 4.x: First specification: 2009 First mature specification: 2012 (4.0.3) 4.0.3 is the right version for development start in 2012 New functions: safety, Ethernet/IP, multicore, AUTOSAR Status
Anatomy 2-5 Indications 5 Contra-indications 5 General preparation 6 Landmarks 6-7 Performing the block 7-8 Complications 8 Trouble shooting 9 Summary 9 References 10 Appendix 1 11. 6/10/2016 Fascia Iliaca Compartment Block: Landmark Approach 2 FASCIA ILIACA COMPARTMENT BLOCK: LANDMARK APPROACH INTRODUCTION Neck of femur fracture affect an estimated 65,000 patients per annum in England in .
