How does application software pass data within an AUTOSAR-compliant system? The answer depends on what the application wants to communicate with. There are two main methods of communication for AUTOSAR-compliant application software: sender-receiver communication and client-server communication. Let’s begin by discussing application software in AUTOSAR before diving into communication.
AUTOSAR refers to an application as a software component (SWC). SWCs communicate using ports. The types of ports addressed in this post will be sender ports, receiver ports, compound sender-receiver ports, client ports, and server ports. SWCs may also contain runnable entities (runnables). Runnables are functions which process the data that is coming into or leaving the SWC through its ports.
An SWC can broadcast data through a sender port, and another SWC can collect it using a receiver port. With this method of communication, the data from the sender will be stored on the Run Time Environment (RTE). The RTE is a medium which allows application software to communicate with other applications or services defined in the basic software. (We’ll be publishing future blog posts about basic software services soon, so stay tuned). Any appropriate receiver port defined in the application layer is free to read this data from the RTE. In other words, these ports don’t care who writes the information and who reads it. One huge benefit of using AUTOSAR is that the same ports which communicate within one controller can be used to communicate with other controllers as well. Senders and receivers can send simple data types like Boolean values and integers. They can also send more complex data types such as arrays and records.
AUTOSAR restricts dataflow to certain configurations. The sender-receiver interface may be connected in either a 1:n or an n:1 relationship (note that n=1 is valid). This means that one sender may store data to the RTE for many receivers to read, or many senders may send data to the RTE for a single receiver to read. An n:m relationship (multiple senders to multiple receivers) is not allowed in the AUTOSAR standard. However, another type of port, known as a compound sender-receiver, is capable of this configuration (n=m because for every sender there is a receiver). As the name suggests, these ports can both write and read data to and from the RTE.
Another way in which application software can interact is through client-server ports. These ports are similar to function calls in programming languages such as C. A client port may request information from another SWC (i.e., it makes a function call). Kindred to sender-receiver communication, a server port will route data through the RTE. The difference is that the data from a server is only available to the client who requested the data. The client’s call will persist until the requested data is received or a timeout period threshold is reached. The only supported configuration is a single server connected to one or more clients.
The operation which a client requests from a server is defined in the interface used by the ports. A specific interface can contain multiple arguments. Each argument can be defined as in, out, or inout. When the client invokes a server operation, it must provide a value for each outgoing argument. The data returned from the server will also contain a value for each incoming argument defined in the interface (assuming the sender’s response is valid).
A client’s call can either be synchronous or asynchronous. If it is synchronous, then the runnable which invoked the server operation will be blocked until either a valid response is received, an error is returned, or a timeout period has been reached. In the case of an asynchronous call, the invoking runnable is not blocked. It can sit at a wait point, or it can be triggered by the server’s response.
You now know about two ways that application software can communicate in AUTOSAR, so how do you choose which to use? If your sent information requires an immediate response, client-server communication would be the best implementation. Additionally, if you need to know where the information came from, you need to use client-server. If you don’t intend to receive information back after sending data, sender-receiver communication may be appropriate.
We’d love to hear your feedback about this topic or address any questions you may have. Feel free to give the DISTek team a call at 319-859-3600 or just drop us a note here!
