Configure AUTOSAR Adaptive Client-Server Service Communication

R2026b

Method communication enables an AUTOSAR Adaptive software component to invoke a method provided by another software component. A server component provides a method implementation through a server port, and a client component invokes that method through a client port. In Simulink^®, you model method communication as client-server communication with function ports, Function Caller blocks, and Simulink Function blocks. Clients and servers must be modeled by separate software components. For more information about modeling AUTOSAR Adaptive client-server communication, see Model AUTOSAR Adaptive Service Communication and Execution Behavior.

To configure method service communication properties, open the AUTOSAR Component Designer app and Property Inspector. Select a software component client port. On the Service tab, you can configure these communication and execution properties:

• Caller behavior — Determines whether the client invokes the server method synchronously or asynchronously

• Timeout — Specifies the maximum time, in seconds, that a client can wait for a response from the server

• Server response not required — Configure the method for fire-and-forget communication

Configure Synchronous and Asynchronous Client-Server Communication

The Caller behavior service execution property on a client port function element controls whether the client blocks execution while waiting for a server response, or continues executing and polls for server results. To configure the caller behavior, select a client port on the software component boundary. In the Property Inspector, on the Service tab, set Caller behavior to one of these values:

• Allowed delayed server results — Use asynchronous method invocation, in which the client sends a request to the server and continues execution. Each time the function executes, the client checks whether server results are ready. If no new results are ready, the client outputs the most recent value that it received from the server.

• Wait for server results — Use synchronous method invocation, in which the client sends a request and is blocked from execution until the server returns a response.

Open example model adaptive_ActuatorSWC and generate code.

openExample("adaptive_ActuatorSWC");
slbuild("adaptive_ActuatorSWC");

Software component adaptive_ActuatorSWC has client port Velocity with function element getCurrentVelocity. In this example, Caller behavior is set to Allowed delayed server results, which configures the client for asynchronous communication.

When you generate code for adaptive_ActuatorSWC, the generated service header (adaptive_ActuatorSWC_services.h) declares two separate functions for the client method:

/* client service interfaces */
extern void call_Velocity_getCurrentVelocity(void);
extern SlSignalStatus get_result_Velocity_getCurrentVelocity(double *velocity);

The first function, call_Velocity_getCurrentVelocity, initiates the method request to the server. The second function, get_result_Velocity_getCurrentVelocity, checks for results and returns the SlSignalStatus indicating whether the response is available.

In the generated service implementation code (adaptive_ActuatorSWC_comm.cpp), the asynchronous pattern uses ara::core::Future proxy method to manage the pending server response:

ara::core::Future<proxy::methods::GetCurrentVelocity::Output>
    getCurrentVelocity_future;

SlSignalStatus getCurrentVelocity_status = SlSignalStatus::OK;

void call_Velocity_getCurrentVelocity() {
  if (Velocity) {
    if (!getCurrentVelocity_future.valid()) {
      getCurrentVelocity_future = Velocity->GetCurrentVelocity();
    }
  } else {
    getCurrentVelocity_status = SlSignalStatus::COM_NOT_AVAILABLE;
  }
}

SlSignalStatus get_result_Velocity_getCurrentVelocity(double *velocity) {
  if (getCurrentVelocity_future.valid()) {
    if (getCurrentVelocity_future.is_ready()) {
      auto getCurrentVelocity_result = getCurrentVelocity_future.GetResult();
      if (getCurrentVelocity_result.HasValue()) {
        auto getCurrentVelocity_output = getCurrentVelocity_result.Value();
        *velocity = getCurrentVelocity_output.velocity;
        getCurrentVelocity_status = SlSignalStatus::OK;
      } else {
        getCurrentVelocity_status = SlSignalStatus::COM_NOT_AVAILABLE;
      }
    }
  } else {
    getCurrentVelocity_status = SlSignalStatus::COM_NOT_AVAILABLE;
  }
  return getCurrentVelocity_status;
}

The get_result_Velocity_getCurrentVelocity function checks whether the server results are valid, ready, and have a value. If all of these conditions are met, the function extracts the output value from the velocity argument and returns SlSignalStatus::OK. If one or all of these conditions are not met, then the client continues using the most recent value and the status remains SlSignalStatus::COM_NOT_AVAILABLE.

To configure adaptive_ActuatorSWC for synchronous communication, select software component client port Velocity. In the Property Inspector, on the Service tab, change Caller behavior to Wait for server results.

With synchronous caller behavior, the Actuator component blocks execution until the Speedometer server returns a velocity value. Use synchronous communication when the algorithm requires the server result before it can continue computing.

When you generate code with synchronous caller behavior, the generated service header declares a single function that combines the call and result retrieval:

/* client service interfaces */
extern SlSignalStatus call_Velocity_getCurrentVelocity(double *velocity);

In the generated service implementation code, the synchronous pattern calls the server method and blocks any returned values from ara::core::Future until the result is available. The function returns SlSignalStatus::OK when the server responds successfully, SlSignalStatus::TIMEOUT when the configured timeout expires before a response arrives, or SlSignalStatus::COM_NOT_AVAILABLE when the server is not reachable.

Configure Fire-and-Forget Method Communication

Fire-and-forget methods allow a client to send a request to the server without requiring a response. The client invokes the method and immediately continues execution. Use fire-and-forget communication for commands or notifications where the client does not need to know whether the server processed the request successfully.

To configure fire-and-forget communication, select a client port function element on the software component boundary. In the Property Inspector, on the Service tab, in the Communication section, select Server response not required. This attribute can be set only when the Simulink.dictionary.archdata.FunctionElement function prototype has no output Simulink.dictionary.archdata.FunctionArgument objects.

In the exported ARXML, fire-and-forget methods have the FIRE-AND-FORGET element set to true in the CLIENT-SERVER-OPERATION description for getCurrentVelocity:

<CLIENT-SERVER-OPERATION UUID="...">
  <SHORT-NAME>getCurrentVelocity</SHORT-NAME>
  ...
  <FIRE-AND-FORGET>true</FIRE-AND-FORGET>
</CLIENT-SERVER-OPERATION>

Configure Client-Server Communication Error Status

Status arguments allow a client software component to detect and handle communication conditions during server method invocations, such as server timeouts or unreachable servers.

To add a status argument to a client port function element, select the client port on the software component boundary. In the Property Inspector, click Add Argument and select Add Status Argument. This appends a status output to the client function prototype. For example, for client port Velocity with method getCurrentVelocity, the function prototype becomes [velocity,status] = getCurrentVelocity().

This table shows the enumeral values for built-in enumeration data type SlSignalStatus.

Value	Description
SlSignalStatus.OK	No communication errors occurred and the client received valid data from the server within the configured timeout period.
SlSignalStatus.TIMEOUT	The client did not receive valid data from the server within the configured timeout period. The client holds the last valid value that it received from the server.
SlSignalStatus.COM_NOT_AVAILABLE	The communication service is not available, for example when a service has not yet been discovered by the middleware or a connection has been dropped.

In the software component model, use the status argument value in your algorithm to detect communication failures and execute error handling logic. For example, in the adaptive_ActuatorSWC model, an enabled subsystem sends a brake command only when the getCurrentVelocity status argument reports SlSignalStatus.OK and the returned velocity is a positive value.

To configure timeout, select a client port function element on the software component boundary. In the Property Inspector, on the Service tab, set Timeout to the desired value in seconds. Set the timeout to Inf to indicate no timeout, and to allow the client to wait indefinitely. When Timeout is set to Inf, then the service implementation code generated for the model does not contain any timeout handling semantics.