class ara::com::InstanceIdentifier

The class ara::com::InstanceIdentifier represents the unique technical identifier of a concrete service instance in the AUTOSAR Adaptive Platform and enables addressing via specific communication bindings (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 “InstanceIdentifier class”). As a serializable value type, it can be created from strings, compared, and managed in containers ([SWS_CM_11520], [SWS_CM_11523]). While standard applications primarily use abstract model identifiers, the direct use of this technical identifier serves special cases such as multi-binding and fail-over solutions (AUTOSAR_AP_EXP_ARAComAPI p. 25 “InstanceIdentifier Usage”).

more ›

Context

The class ara::com::InstanceIdentifier serves to uniquely identify a concrete service instance on the Adaptive Platform (AdaptivePlatformServiceInstance) in order to distinguish different instances of the exact same service from one another. It encapsulates the technology-specific addressing of the chosen communication binding, but deliberately contains no fully qualified name with service type information. For the regular software developer, direct interaction with ara::com::InstanceIdentifier is generally abstracted: While logical names via ara::core::InstanceSpecifier are primarily used in the software component model (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 “InstanceSpecifier class”), the integrator maps these to the technical bindings and their respective instance IDs via manifest files (AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 “InstanceSpecifier class”).

In the context of so-called multi-binding, a single abstract identifier can be mapped to multiple technical bindings. Resolving via ResolveInstanceIDs() therefore returns a ara::com::InstanceIdentifierContainer that bundles multiple ara::com::InstanceIdentifier (ARAComAPI p. 1 “Figure 6.6: InstanceIdentifier Resolution”, AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 “InstanceSpecifier Resolution”). This enables servers (skeletons) to serve clients over different transport technologies, or clients (proxies) to implement fail-over paths (ARAComAPI p. 1 “Figure 6.6: InstanceIdentifier Resolution”).

Context diagram: Interaction of application, deployment manifest, instance resolution, and service interfaces. Sources: ARAComAPI p. 103 “Figure 6.5: Service Discovery”, AUTOSAR_AP_EXP_ARAComAPI p. 23 §4.2 “InstanceSpecifier class”, AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 “InstanceSpecifier Resolution”

Lifecycle

Instances of ara::com::InstanceIdentifier have full value semantics. They satisfy the requirements equalitycomparable, lessthancomparable, and copyassignable according to ISO/IEC 14882:2014, allowing them to be managed, sorted, and logged in standard containers. The class provides the following constructors and lifecycle functions:

• Exception-free creation via the static factory method Create ([SWS_CM_11520]) with noexcept.
• Explicit constructor based on a string representation ([SWS_CM_11521]), which is expressly not exception safe (not exception safe).
• Copy constructor ([SWS_CM_00056]) and move constructor ([SWS_CM_00053]), both specified as noexcept.
• Copy assignment operator ([SWS_CM_11525]) and move assignment operator ([SWS_CM_00054]), each with noexcept.
• Comparison operators operator== ([SWS_CM_11523]) and operator< ([SWS_CM_11524]) for equality and ordering checks.
• Destructor ~InstanceIdentifier() ([SWS_CM_00055]) with noexcept.

Through the interplay of the string constructor with the method toString() ([SWS_CM_11522]), the class is serializable (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 “InstanceIdentifier class”). This allows persisting, transmitting, and later reusing an identifier. An interpretation of content (introspection) of the serialized string by the application logic is not intended, since the structure depends entirely on the middleware product and binding (AUTOSAR_AP_EXP_ARAComAPI p. 22 §4.1 “InstanceIdentifier class”).

Usage Path

Since ara::com provides overloads for common methods that accept ara::core::InstanceSpecifier directly, manual handling of ara::com::InstanceIdentifier is primarily aimed at advanced use cases such as specialized bindings or targeted fail-over (AUTOSAR_AP_EXP_ARAComAPI p. 25 “InstanceIdentifier Usage”). The typical sequence is divided into the following steps:

1. Resolution: The application translates the abstract model identifier into the assigned technical instance identifiers using ResolveInstanceIDs() (AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 “InstanceSpecifier Resolution”).
2. Selection: From the resulting ara::com::InstanceIdentifierContainer, the application selects the desired ara::com::InstanceIdentifier (ARAComAPI p. 1 “Figure 6.6: InstanceIdentifier Resolution”).
3. Service search: The identifier is passed to the static method FindService(ara::com::InstanceIdentifier instance) of the proxy class (ARAComAPI p. 103 “Figure 6.5: Service Discovery”).
4. Processing: The service search returns a ServiceHandleContainer, based on which proxies are instantiated (ARAComAPI p. 103 “Figure 6.5: Service Discovery”). The instance identifier can be queried via GetInstanceId() (AUTOSAR_AP_EXP_ARAComAPI p. 30 “GetInstanceId”).

Sequence diagram: Resolution of the identifier and targeted service search via the technical InstanceIdentifier. Sources: ARAComAPI p. 103 “Figure 6.5: Service Discovery”, AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 “InstanceSpecifier Resolution”

Error Scenarios

When handling ara::com::InstanceIdentifier, two error situations in particular must be taken into account:

• Invalid string format (InvalidInstanceIdentifierStringViolation): If a serialized identifier passed to Create ([SWS_CM_11520]) or the constructor ([SWS_CM_11521]) is corrupted, non-compliant, or duplicated, this violation occurs. Interpretation: While the exception-free factory method Create presumably reports this via an error object, the non-exception-safe constructor is likely to throw an exception in case of error. Question Q-45a6fdd0859218bd (open)
• Missing mapping during resolution: If the integrator has not defined a mapping for a ara::core::InstanceSpecifier in the deployment manifest, the call to ResolveInstanceIDs() returns an empty list (ARAComAPI p. 1 “Figure 6.6: InstanceIdentifier Resolution”, AUTOSAR_AP_EXP_ARAComAPI p. 24 §4.3 “InstanceSpecifier Resolution”). This usually represents a configuration error.
• Missing service instance: If no corresponding OfferService() was executed on the skeleton side for the specified identifier, the ServiceHandleContainer returned by FindService remains empty (ARAComAPI p. 103 “Figure 6.5: Service Discovery”).