SOME/IP - A Service Oriented Architecture (Intrepid Tech Day '19)

so this is a so what is so my P so this is the full full form of this scalable service oriented middleware or IP you know so that II comes from last part of middleware you know somebody you know made of this this acronym for this but essentially it's an architecture of you know a provider and a subscriber so a consumer ECU and a provider is you so can provide or ECU provides a service to an issue which consumes the service there could be a simple function event a set of fields which a provider E

CU offers to any other issue which subscribes to it so that's the basic mechanism so it's a it's a really an automotive specific remote procedure call you know I want to invoke something in a remote ECU so this protocol allows to do that and more and more seeing in recent time you know as we are progressing towards Ethernet we're seeing a lot more usage of you know some IP so it's a here is a simple picture which shows two Network endpoints connected to a switch there is an IP address to each of

these in the endpoint there is there are a couple of ports there three zero four nine nine is a service discovery port and this port is fixed the number is fixed for service discovery we'll talk about service discovery so when when you see SD here it's gonna be several teeth covering so provider ECU offers a service plus it provides its endpoint it is it provides there it's going to provide its service a service could have fields fields conceptually is a set of signals you know I have a set of

signals based on which I can transact with other AC use I can provide those signals through certain methods and I can provide ability to get them or set them or notify in case there is a change so we'll talk about that more consumer ECU is going to subscribe to a service it receives notifications based on the protocol so once a subscriber ECU is registered as a subscriber to the service cannot receive notifications to the events its subscribed there is so there is one model is pub/sub model or p

ublish/subscribe model the other model which also is supported is request respond so I as a as a consumer issue I make a request and the ECU responses to me for that I don't need to really subscribe to it I can just make a request both these models are supported in some IP why some IP I mean why why are we getting into here now after you know years of automotive you know ECU software development all so the basic reason is again you know this was part of my other talk to on you know your XML clas

sical signal based communication like can that is not really sufficient for more complex data communication and control now we are we are transacting lot of complex data structure across over Ethernet and you know they they require a lot of control and signaling between two nodes which are on Ethernet so that is one reason second is a you know a specific vehicle module or an ECU which is very computational capable you know something which is highly capable to do a lot of complex computation can

provide the needed intelligence to remote nodes they all don't need to implement the same you know complex calculations same algorithms but they can still consume the results from a highly computational intensive ECU which probably controls you know a vehicle movement or so on so forth in case of you know ADA's or autonomous systems again Ethernet as in vehicle network has been really a precursor for this it allows to do this it allows so Ethernet allows the classical signal based communication

I can always transact a signal of a PDU on Ethernet plus it can allow me dynamic contract between you know subscriber and publisher a is a or a publisher and you know provider a consumer so the server can always say I'm stopping to offer the service that's the dynamic nature which it you know which in a some IP allows this you know controls bandwidth controls information and that is all possible because of this there are complex service interfaces it methods and events can now be transacted over

Ethernet you know I can invoke specific methods in a remote ECU or you know specific set of events all the events in some IP are grouped under something called event group and we'll know more about this in this presentation and this this can only be possible with a protocol which defines and allows to define this so service oriented middleware protocol and uses TCP or UDP and it is o I P so why continuing further further why so my P you know it allows to add new functions and features so there

are there are there are certain functions and features you can add as a dynamically assigned so ECU inside the vehicle can subscribe you know very good in you know so some IP is not restricted to the in vehicle communication is you inside a vehicle in the v2x world can subscribe to a service outside like accident notification so if for example a vehicle is moving and in ECU which wishes to subscribe the consumer wants to subscribe to accident notification it can do that at one time so the vehicl

e already knows there are you know what kind of lane closures it could see that's my next slide should explain that so let's go to the how it's architected then probably that will answer if not we'll discuss this again so there is another thing is static definitions you know again something which is statically defined has very less capable you know you know possibility of expanding it's you know feature so the some way pay allows you for a dynamic availability of services and you know addition o

f the services so where does so my piece sits in an ECU if we understand that I think it will be easier for us to know what it is so in AUTOSAR some IP has been defined so it's part of the AUTOSAR stack and it's so you can see the green part here is the some IP protocol itself and it's it's over so a door socket adapter so it is a layer about tcp/ip so there is a layer so this is your physical interface layer in orders our model then there is tcp/ip based stack above tcp/ip is a socket adapter a

nd above socket adapter are there are two chains of processes one is so my P which is the protocol itself and there is another which is service discovery we're going to talk about that we're going to talk about all three components of some IP so that is how the stack of so my P is inside ECU so AUTOSAR defines it how to model e an easiest way to see is this picture so scalable service oriented middleware or IP so for simplest view this is broader reach physical layer one hundred base T one or po

ssibly two thousand base T 1 we have Mac villain we have IP v4 we have TCP UDP and we have an application layer so might be yes you cannot run this yes okay yeah that's why this picture explains you need this some some is over only IP you know scale this is or only or IP now why you know there are few things which are unique about some IP you know as described in AUTOSAR one is it is well described and specified you know we need that in to have anything in our vehicle you know it has to be well

described it has to be very very testable you know if I am NOT able to test my so my P there could be bad things you know we are talking about you know Ethernet here so we need so it's testable it is described and specified and it can carry AUTOSAR PDUs this means I can architect my outer sir model and help you to use transact on some IP this is a you know picture to give an overview of people who have not worked on this and they didn't get opportunity yet to look into it but this is how typical

ly an architecture inside a vehicle network or some IP would look like so I have a you know descriptive example here it's a switch and you know I have an example of for ECU is connected one is head unit another I'm just calling it vehicle control unit let's assume there is a front camera ECU there is a short-range radar and let's say there is an r lr r or long-range radar you see each one has I P addresses and port numbers so let's assume front camera ECU provides and service interface of object

recognition this means that is responsible to do all the intelligence to come up with detection of an object and ECU like vehicle control ECU is a consumer of that interface so it's going to consume object recognition so in the service discovery phase of some IP it's going to register to that service object recognition this service let's assume also has even group called object even group one and it has two events objects new position or object is now blurred you know so these are two events as

sociated with it the consumer ECU is going on once its subscribed to it then based on the service discovery protocol it's going to get information either based on request response and fittest pub/sub model it's going to get when the event happens even notification happens so this means anytime there is an object detected vehicle control EC will automatically get the information it will get because it has subscribe to that service similarly I have this defined as a consumer for my short-range rad

ar which allows - Park Assist so here I have - here here I define two fields fields again you know easiest way to understand them is their signals front distance or rear distance and there is a notifier method associated the field this means when there is update in the information of front distance vehicle control a/c you will be given that information because it's subscriber to this to information so this gives us a little you know understanding of what some IP is why it is needed you know tryi

ng to do this on a non discoverable protocol non service despair whole protocol makes it very difficult and non non you know it's not not a progressive path for platform design in ECU's you know having new ECU the new services I can always locate this issue with new service and I can just have this subscribe to without much changes in the system that is definitely you know extension or what you know can or you know our non Ethernet based systems can do again I have this picture here which shows

a very simplistic ECU stack which has so my P again we have Ethernet MAC switch thousand base t1 or what have you then we have a socket adapter stack which underneath of it is TCP UDP which is over IP then you have some I P protocol itself and there is service discovery middleware associated with some IP I'm going to talk about that little bit more and an application would be sitting over some IP stack to consume stack and you know talk to the rest of the network this is just an exemplary you kn

ow it's not a real description of a unit so head unit you know I right now the way this is this head unit example takes actually audio tone control from rear controls that's the example I have here so somebody changing a the one in the rear side of the vehicle the head unit gets that because you know it subscribes to that unit you know so that is how I have this one so this picture actually will explain everything how it goes on the bus really so I have you know I talked about vehicle control EC

U subscribing to front camera ECU and short range radar ECU how does this all work in true sense when vehicle boots up this is a server ECU and this is client easier so this will be vehicle control ECU and this will be either front radar or some other issue so so how does this work so my P protocol will starts the client needs an information it needs to subscribe to a service so it's going to issue a protocol information fine service I will explain the whole message format later how fine service

message appears on the bus for and this are the snapshots sorry from V spy vehicle spy describes all this protocol engine completely in in the message view so in this case fine service I have assumed service ID is 0 1 2 3 4 and other details once now when this service is sent it's not being actually sent to server it's going to be sent on a multicast because the consumer doesn't know who is provider for that service and where the provider is so it's going to send on the multicast that's defined

in some IP again when server sees the presence of this message it's going to go back and offer the service so this is offer service message again the service offered is one two three four it's going to provide the IP endpoint addresses you can see you know when you know this is the address for you know IP address 100 and protocol and put three zero five zero nine what this means is it is telling the consumer ECU to look for service at this point so it's declaring its poor so at this point of ti

me the in the client is going to register this IP address and port from service D theory from this process once that happens it's going to say okay I want to subscribe to one two three four eight all its events or maybe a specific event inside one two three four so it's going to send subscribe event group and when subscribe event group goes out there will be information acknowledgement from the server saying okay I got your subscription request I have stored it so now you're subscribed to me and

whenever that event happened it's gonna send the UDP frame with the payload so this is a classical service discovery pub/sub model of how some IP works and there are lot more details behind it there are lot more complexities behind it but this is very conceptual presentation of how how a house of IP works so for service discovery the port number is fixed right so there are two so in every ECU in some IP there are three sets of ports predefined one is service discovery port and that port number

is fixed to three zero four nine zero so a a a listening ECU has to listen on that port when it is doing service discovery when I'm doing I'm discovering the service I'm subscribing to the service or I am acknowledging the service that has to happen on service disco report that is a fixed port so this port is inside a Cu we have the status so you can think at this port number as identifier of the software stack inside the ECU which does service discovery that's the best way to think about it and

once the service discovery happens you know even in this example you can see that it offers three zero five zero nine location of the port that is the new port number where the service is available it's a different port number at both these port numbers are in the same ECU so in when in some IP three zero five zero one port is the first port where you can provide a service so if you know if I have three things to provide for example a break information GPS information or maybe something like yo

u know phone connected information I have let's set these three services I am providing in my ICU I can have code number three zero five zero one three zero five zero two and three zero five zero three so now if you subscribe to the object information which is at let's say three zero five zero three I'm going to send you three zero five zero three with my IP address I'm going to subscribe you're going to look for that port and that IP for the payload so all these issues so when when when you tal

k about switch in automotive sewage there are two possibilities are there one is actually the only one possibility I know about it's switch being part of a ECU itself so it belongs to let's say center gateway module and your all other ECU is connected to it so this switch and the connection of the ECU's the so when you are looking at the port number of the switch that doesn't matter for so my pits an application layer when i'm gonna send this IP address so the port which this this issue is conne

cted has little meaning for when it comes to application yes I think that's the question because yeah this this is not a physical port this is an application port I call it this reputation Johnny's or switch experts or I think you could I just want to you know I show one more thing here which is the UDP payload you can see that this is the source port this is the destination port and this is the payload here so the transaction is all you deep in this example V spy has all the capabilities to sho

w all the some IP messaging I thought this was a video but I'd somehow it can't play it so in the V spy you know for customers who are already using vehicle spy or they intend to use vehicles by so my P messaging views fully mature now it's available it's a customizable view for example here you cannot see anything which is like normal you know there is no can here you know I have I have this view describing service ID you know so I'm looking at service IDs I'm looking at the instance ID I'm loo

king at the method ID I'm looking at you know type of the message you know what kind of message is that I'm looking at the request ID event groups return code source you know source port destination and destination pool so this traffic is typically you know in our sim in our we have really see used running so my P so this is traffic from that and so V spy is fully capable right now to show detailed message view for some IP the other product which we have and I talked a little bit about in upstai

rs when talking about AR XML is a accom EA comm has special areas to view the so my P configuration in the our XML file so might be being AUTOSAR your XML completely defines completely you know hundred percent of the description of some IP it describes which PDUs are on which port or which sockets in which socket belong to you know what ACO and everything so on so forth and best way to know about it is to use EA comm tool you can there is a there is a separate view for socket connection and the

recipient view for some IP you can just click on this areas for example when you click on this it will show you all the services available all the methods available or you want to add a service you want to add a method or you want to create entirely new service new method with new data types you can do that in your comm and then so also there are views where you can look into details of what method what you know what data and what parameters belong to a specific service all these views are defin

ed based on what customers would like to see really we Spy has again there are two areas in V spy one is the main message view but then there is another details view and you can see that in details view it can show you exactly every part of the frame dissected completely yes so the magic does happen so the first step number one is to actually create an AR XML file which describes some IP right that we need the file we need the information to know which ECU which port what surveys what data someb

ody has to create that what I am saying from many OEMs is either they have an XLS file describing complete details or they have five X file which is in SM standard or they have any XML file so engineering team decides and makes this files and you load this file as a user you know I would load this in vehicles PI and vehicles PI will show me the services methods fields and everything so yes vehicles by will decode and that is in a part of my slide later which is actually probably gonna answer tha

t question also further explain more about you know how automatically everything happens so right now this is message view and there is further you know bits and bytes level information I highlight something I can see what exactly for example you can see here one two three four that's the service ID here which is was in my example and that service IDs here so offers service has a specific protocol name so you know you can see that one too so we speak aspire supports this already to just go furth

er and describe more so that you know we all yes Jenny we so some IP is defined well in Jenny we AUTOSAR specifications are another area should look into what does our specifications do hell everything about so Mikey so so if you look so there are two things one is the configuration and was the stack you know stack of the so might be itself there are there is only one good free stack not free it's a stack available which you can use you can configure that on your Linux machine it's for Linux you

can configure that on a Linux machine and you will have a so my P ECU behavior it's available that is Geneva that is not Geneva that is that is from an OEM I think I can I have the links and I can send it to you so it's Linux based act it's very well written multi-threaded stack and it does everything it actually configures the stack using JSON file so you can have JSON define service and it's going to take and gonna do the behavior so some IP again has three primary component money socket adap

ter one is service the story and one is transformer transformer is basically serializer destabilizer component what is a socket adapter I hear a lot question about this also a socket adapter is a layer in AUTOSAR which describe all the sockets present and available for a specific specific application so a socket connection bundle is this is how it is defined in your XML so you have a socket connection which has a client ECU and a server you see you and there are PD use which are transacting on t

his socket all of this is described in AUTOSAR and it's a typical socket connection bundle has many sockets like this so you can see that this is one socket where a server ECU is issue one is there it refers to this socket which has again a client ECU referred inside that socket and there are PD you described as how they transact on this circuit so socket adapter layer in AUTOSAR is not just for some IP or services curry I should say so my gracious service discovery it is also used by PDA router

it is also used by UDP network management xcp or Ethernet and even though all of these actually use the same socket adapter layer again we have seen the stack few times now already there is tcp/ip layer then there is a physical layer but socket adapter is something allows you to do the service discovery because a service doesn't know where to find it so it's the only sockets going to talk I just want to you know put this in front of your eyes so that the more you see something really so my P th

ese are some of the terms we should just be you know familiar with what is the service it's a functional entity that offers an intensive interface what's an instance of service it's a single you know it's a single instance running for work you know in connection with a client offer service is a service offer message on the bus stop offer is a server is decided to stop offering the service wine services when client is looking for a service event is a message sent by ECU implementing a service ins

tance to an ECU using this service instance so that's an event every event typically is transacted only under event group you cannot have just an event if you want to you know register for an event it has to be registering to an event group fin Gator setter we talked about that methods to get a feel and set a field you know I want to set certain things I want to set a volume I can call into this you know server and set the volume remotely so that's a setter there is notification event which is c

hange event you know field changes the notification message goes out and so on so for some of these terms and conditions he or you know some of these terms you will hear a lot when you're working on some IP what are the specific service discovery rules basically respond to fine offer a service or take back the offer simple basic very and in services curry what is clients role client sends a fine listens for offers and listens for stop offers too so that's a simple client enroll of a in the servi

ce discovery phase again if you look into very basic is the Resaca adopters or will discovery and then based off what is our BSW above it what all things services curry does is it offers you know it has all these functions and these are all the message types actually fine service offer service top service subscribe subscribe you know stop subscribe a can you know neck all these are also available has few slides just describing the message structures will not go into a lot more details you can al

ways read this in the specifications this come from what was our spec and I'm just reproducing it here from the spec itself once you know I have this screenshot which actually shows that we spy knows everything about this so it it can decode all the although every part of the message so there is a header area then there is entries area and there is options area again this is a protocol this is you know you know service discovery related so my paper to call or the message structure there lot more

details will not go but you can see there are service IDs instanceid you know there is TTL information there are versions because you need to know if I want there is a version 1.4 of a service but this issue request service you know 1.3 version of the service probably a field has changed so the version information has to be about the service so that it's correctly doing it then again there are more details about how these messages are formed there are different options and different types encod

ed in there we spy nodes knows everything so you don't have to do it yourself there are options airfield you know you know how I PV for is placed in a 32-bit number you know all those things are available here when you are multi you're doing a multi cuss service discovery that me you know you know how to what to what what will expect for multi cast this is actually the whole frame you can see request ID session ID and there are rules and you know rules about how this you know how this IDs are wr

itten you know there are because for example when you look at the service discover it as a fixed service method id-ff f800 so that is fixed for service discovery okay what else we have in the echo spy for some IP you know to address some of those things you in C code interface you can transact we and what is out for the plan on so might be that also I'm going to talk but in C code interface you can create the messages to respond on a service for example if you want to respond to a find service b

y offering a service you can do that in C code interface I'm not sure how many of you actually know about C code interface in V spy so vehicle spy software has two scripting areas one is function block and a very C code interface C code interface allows you to write C program in vehicle spy at network level so you have all the network entities available for you to program and this is a interface into B into C code you know C code side now for example I have here us some IP frame on which I want

to react in C code interface so I will declare that frame here it will create an event handler for me and I can respond that in C code interface so C code interface supports right now basics in some IP simulation and so does function blocks so this is a sample example of how you could do it there are API is created for you and the great thing about you know C code interface ID is it's a huge message you know it's a 1500 byte payload and you can actually do all the message level or bit byte level

transactions or work you know what what you want to do with the payload inside C code it's sometimes not recommended to do a huge payload work or you know when you want to decode the payload in function blocks function blocks are really good when it comes to you know doing transactions which are with you know specific payloads so C code supports some IP in vehicles PI to a lot extent I'm gonna explain what else we are gonna have it so this is what we are going to have it and the question was yo

u know how magically this all will happen that would be the next step in V spy so we are working towards being able to simulate a complete endpoint through a single click you know for example when I load an XML file and I have three ECU's and they provide services like this there is a let us say auto steering provided service and this ECU consumes SMS and again there is another application endpoint in the same ECU which has a GPS as provided service instance and video is a consume service insert

and that's the end point for the NEP Network endpoint and similarly I have an SMS and GPS which are consumed by this ECU I have audio and GPS so ID is provided by this ECU and GPS is consumed by this ECU and so on so forth so how let's say this I have this network which is all described in the are XML this you can describe in a are XML you can use a comm tool and create the exact same network the next step in V Spy is when we are going to be able to provide you just a single check box ap simula

tion so you can select the ECU or the endpoints which you want to simulate that's where we are going so the question was how magically all this will happen if you have a XML file we'll have it you know is our next thing in Vegas why right now if you have to do this you have to do this manually in C code interface you have to simulate you know the responses in the C code interface okay again just to sum up you know interpret tool support for some IP vehicles by powerful bus analyzer it allows the

whole message be is available you have capabilities in function blocks in C code interface or you know for simulation for basic simulation right now in future we will have ap simulation has I described just now viacom allows you to create complete so I pay architecture and output in the XML file you can use the XML file in your further AUTOSAR workflow that's possible because it's autos are compliant 4.2 you can use interpret Hardware read galaxy and that start to that's my recommendation 400 b

ase t1 if you have multiple issues connected you can you know connect them with you know rats or to all right galaxy and how the network's simulated so that would be the that's our support for some IP I mean there is a question of what we spy has so this all things are possible today some of the latest thing autos are classically are XML standard for point 3.0 that's what we are compliant with iniya calm and that's our target for V spy lot of things in V spy there is a you know short term plan a

nd also a long term plan so you know if you have more information on you know specific things please talk to me after this session and I can explain you what we what direction we want to go just I have you know few more informations about some IP there is a transport layer also dis you know defined now in some IP and there is specification for that also so if you hear about it it's there and this last white I have on some IP and this is very interesting one because this is adaptive AUTOSAR adopt

ive AUTOSAR is the new platform which has lot of new things and it's it's a it supports the new technologies like ADA as an autonomous vehicles here some IP IPC and DDS these are three middlewares already as part of the you know adopt a auto cell stack some IP is here IPC communication which is a local host you know if you have the local local host running then you have a PC and you have DDS which is another middleware and you know that's a separate one and this are all sitting over C++ STL and

POSIX based operating system so adoptee AUTOSAR describes c++ as the next you know ECU programming language there are a lot of other things so if you you know you want to see how it all works you go in the AUTOSAR website you will see a lot you know how how things have been designed considering virtual machines so all these you know all the design and development can be done over a virtual machine and you know it that's that's the direction AUTOSAR is going in thank you that's it if you have que

stions you can ask me now