struct <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output

The structure bundles all output arguments of a service interface method on the server side for transmission to the caller. When executing a skeleton method, the service implementation instantiates this data structure, populates its attributes with the calculated results, and passes them back to the communication layer. The middleware then serializes the contained parameters and transmits the response packet to the calling proxy. Since no explicit specification requirements are stored in the payload, the element types are likely to correspond directly to the data types of the output parameters modeled in the service interface. Question Q-55d242e98cd76967 (open)

more ›

Context

The C++ structure <SI-Namespace>::skeleton::<SI>Skeleton::<Method>Output is a generated part of the service portion in module com of the AUTOSAR Adaptive Platform (release R25-11). Within the service interface, this type bundles all output arguments (out parameters) of a defined service method on the provider side. The structure functions as an intermediary layer between the concrete service implementation of the service provider and the communication middleware ara::com. Since C++ function signatures typically only support a single return value, this type provides a structured aggregate in order to return methods with multiple output parameters to the calling runtime environment in a type-safe manner.

Lifecycle

The creation of an instance of <Method>Output takes place in the application context of the service provider as soon as a service method has completed the required calculations. The service implementation instantiates the data aggregate locally, initializes the member variables declared therein with the determined values, and then passes the instance to the communication layer. Handing over to the framework terminates the immediate ownership rights of the application-specific method implementation; the object is transferred to the responsibility of the middleware. The lifetime of the instance is transient and ends as soon as the communication layer has serialized the contained parameters into the downstream protocol payloads and released the buffer. With regard to concurrency, each method call is isolated: Each call context operates on its own instance, so that no synchronization mechanisms are required at the class level as long as the transported values do not share unprotected shared resources.

Usage Path

The typical sequence when using <Method>Output takes place in a fixed interaction sequence between the runtime environment, the skeleton method implementation, and the output structure. After a method query arrives, the middleware forwards the call to the implemented skeleton class. The application logic performs the processing, creates the structure <Method>Output, and fills in all output parameters. The instance is then transmitted to the runtime system, which performs the serialization and sends the response message over the network to the requesting proxy.

Sequence diagram: Call and return path when using the output structure in the skeleton. Sources: No evidence specified in the payload.

Error Scenarios

As a pure data aggregate, <Method>Output has no error handling routines or status methods of its own. Erroneous states arise primarily at the interfaces due to incomplete initialization or precondition violations. If the application-side implementation fails to populate individual member variables correctly before returning, uninitialized values or null states may be serialized. If the functional calculation of the service method fails in advance, no valid <Method>Output instance is transmitted in the regular control flow; instead, the implementation reports the error that occurred via the designated error channels of the service interface. If memory allocation errors occur with dynamic data structures within the output arguments, these must be intercepted within the called method before handing over to the middleware.