loader image

Test Solutions for Simulink Models & Production Code

Virtual Validation for ADAS/AD

How can I create the needed millions of scenarios?

How can I avoid the test explosion problem?

How can I find out if my tests are passed or failed?

Blog

AUTOSAR – When to use Client/Server or Sender/Receiver communication?

Nabile Khoury

Paris, France

Introduction

In AUTOSAR Classic, communication between software components is vital for building complex automotive systems. AUTOSAR provides various interfaces to facilitate communication and the two fundamental ones are AUTOSAR Sender-Receiver or Client-Server interfaces. Each interface type has distinct characteristics and attributes that make them suitable for different scenarios. In this article, we will present each interface and explore when it is appropriate to use Client/Server or Sender/Receiver communication in AUTOSAR-based systems.

Understanding Sender/Receiver and Client/Server

AUTOSAR interfaces act as gateways for requesting and providing information between software components. Let’s briefly examine the key aspects of each interface type: 

Sender/Receiver Interface

The Sender/Receiver Interface enables the exchange of data elements between components. Data elements work as global variables that store values. This interface type is suitable for scenarios where components need to share data asynchronously, without direct synchronization requirements. A sender component provides the data and one or multiple receiver components access it when they need it.   

Additionally, to manage the communication, AUTOSAR offers various attributes. For instance, a sender component can notify the RTE that it cannot provide a validate data, or it can request acknowledgement feedback when it transmits a data. On the other hand, a receiver component can check things like whether the data has changed before processing it. It could also check the data status to determine whether it’s invalid, outdated or if any general errors occurred when the RTE has conveyed the data. 

Client/Server Interface 

The Client/Server Interface defines operations implemented by server components, which can be invoked by one or more client components. It resembles a function call mechanism, where clients request services from the server. We distinguish three typical types of operations:   

  • Get operation: The “Get” communication allows the server to provide information to the client. It is implemented with an output argument in the server’s operation. 
  • Set operation: The “Set” communication enables the client to push information to the server. It is implemented with an input argument in the server’s operation. 
  • Bi-directional operation: In bi-directional communication, the client can retrieve information, process it, and set a result. In this case, the server operation has both input and output arguments.
 

Additionally, AUTOSAR offers attributes to manage the communication. For instance, the operation call can be either synchronous or asynchronous. In synchronous communication, the client is blocked and waits for the server’s response. In asynchronous communication, the client can continue its execution and trigger a callback once the server’s response is ready. Both types can have a timeout attribute to handle delayed or unresponsive servers. Moreover, since multiple clients can call a single server, the server can define a “Queuelength” attribute that specifies the maximum number of requests to be buffered. If the queue exceeds this limit, the RTE returns a timeout error. 

When is it suitable to use Sender/Receiver or Client/Server communication?

Use cases for Sender/Receiver communication: 

Asynchronous Data Exchange: When components need to exchange data asynchronously, with no strict synchronization requirements, Sender/Receiver communication is appropriate. This interface is suitable for scenarios where the receiver may not immediately access the transmitted data. 

Low Latency: If low-latency communication is crucial, Sender/Receiver communication is a good choice. The receiver component can directly access the data without waiting for a request or response, resulting in faster data access. 

Simple Data Exchange: When the communication primarily involves straightforward data exchange between components, Sender/Receiver communication provides a lightweight solution. It is suitable for scenarios where the communication requirements are minimal, and the focus is on efficient data sharing. 

Use cases for Client/Server communication: 

Service-Oriented Architecture: When the system follows a service-oriented architecture, where server components provide specific services to clients, Client/Server communication is suitable. This interface type enables a clear separation of responsibilities and encapsulation of functionality within server components. 

Complex Operations: If the desired functionality involves complex operations that require multiple inputs and outputs, Client/Server communication provides a structured approach. The server component implements the operation, and clients can invoke it with the necessary parameters, receiving results in return. 

Resource Sharing: When multiple client components need to share and access a common resource or functionality provided by a server component, Client/Server communication is appropriate. It allows for efficient utilization of the server’s capabilities by multiple clients. 

Scalability: Client/Server communication supports scalability as multiple clients can request services from a single server. This makes it suitable for systems that require handling an increasing number of clients and distributing the workload effectively. 

Conclusion

Choosing the appropriate communication interface, whether it is Client/Server or Sender/Receiver, is crucial for designing effective AUTOSAR-based systems. The Sender/Receiver interface is suitable for asynchronous data exchange, low-latency requirements, and simple data sharing scenarios. On the other hand, the Client/Server interface is ideal for service-oriented architectures, complex operations, resource sharing, and scalability. By considering the specific requirements, synchronization needs, and architectural considerations of the system, developers can make an informed decision on which communication interface best fits their AUTOSAR-based project, ensuring efficient and reliable communication between software components.

Nabile Khoury

Paris, France

Senior Application Engineer

Nabile Khoury studied Electronics and Computer Science at the University “Conservatoire National des Arts et Métiers” in Paris. From 2010 to 2016, he worked in automotive companies, mainly in the powertrain department of the French car maker PSA Peugeot Citroën, as software engineer specialized in Model-Based Development involving AUTOSAR and ISO 26262 compliant processes. He then joined BTC Embedded Systems AG where he currently works as a Lead Application Engineer - Autonomous Driving in Paris/France.    

Connect on LinkedIn

Popular Videos

Play Video
Play Video

Request Evaluation License

If you would like to try out our tools, we will gladly provide an evaluation license free of chargeEvaluations include a free launch workshop and also provide an opportunity for you to meet one-on-one with our support and engineering teams.

Schedule a Meeting

Do you have any questions or want to see our tools in action? If so, please use the link below to schedule a meeting, where a member of our engineering team will be happy to show you the features and use cases and directly answer any questions you might have.

Join our newsletter

Your email address will be submitted to the privacy-certified newsletter software Newsletter2Go for technical distribution. For further information go to our privacy policy.

Videos

Discover some of the main features of our products in these short videos.