Service-Oriented Communication - SN82.85-P-0001-51S
Model All (CAR)
Comparison of signal-oriented and service-oriented communications
Signal-oriented communications
The significantly increasing options for operation via interfaces such as buttons, touchpads, touchscreens, voice control, gesture control and remote control, as well as other coordinating functions, have shown that signal-oriented communication mechanisms are reaching their limits.
This conventional type of communication requires a customized point-to-point interface for activating an individual actuator.
Service-oriented communications
With Automotive Ethernet, service-oriented communication methods are making their way into vehicle networking. This makes it possible to manage the increasing number of requirements in a more flexible way.
Client/server communication allows all listed control interfaces to request control over an individual actuator via a single interface.
For this purpose, each client sends a request to what is known as the control coordinator (2.1), which has been implemented for 14 systems, particularly from the interior area.
The control coordinator receives the requests in accordance with a server and prioritizes them, whereby the highest-priority request is implemented on an individual CAN interface and routed to the actual actuator. The actuator, in turns, signals its new status, which is sent to all clients over Ethernet as an event.
Methods and events of a comfort function are combined in one service. All services offered over Ethernet together are referred to as the "on-board vehicle API".
There are several benefits to the control coordinator software combining the various elements in this way. It conserves resources on the network, which has less bandwidth, as only one message is sent to the actuator.
In addition, decoupling the interfaces on both networks allows them to undergo further development and versioning independently of each other, which aids scalability and stability.
Another benefit is that the functional quality of the Ethernet interfaces can be improved.
Requests
The further communication design is characterized by conflicting requirements.
The new CAN FD and Ethernet technologies allow a much larger volume of useful data that must be used as effectively as possible in the sense of protocol efficiency.
Communication from the software components (software components - SWCs), meanwhile, is intended to be separate on the transmission side, resulting in much smaller data units (protocol data units - PDUs) in some cases. However, it is only this that makes it possible for software components to be moved easily to other control units if necessary.
The solution is the introduction of a PDU header with a clear identifier and length information (number of transferred bytes). Multiple data units can now be gathered in one container and transferred together in a CAN data unit.
In addition to the introduction of a service-oriented system with the SOME/IP protocol, service discovery and client/server communication, Ethernet requires data to be transferred from the subnetworks to other domains over Ethernet without processing in the gateway.
The benefits of service discovery should not be dismissed in this context. This is achieved by means of virtual services that receive conventional PDUs only with the aid of the AUTOSAR basic software and are provided over Ethernet.
The communication and transfer of data units over internet are implemented by means of the SOME/IP protocol and the AUTOSAR basic software.
SOME/IP is a type of automotive communication software used in AUTOSAR, among other applications.
AUTOSAR (Automotive Open System Architecture) is a standardized open-source software architecture for communications in electronic control units.