AP
6 API Element
Take Radar Service as the example. It is easier to understand.
Instance Identifiers
Used on client/proxy side
a technical binding specific identifier (technical)
ara::com::InstanceIdentifiername is constructed from AUTOSAR meta-model.
The C++ representation of such an "instance specifier" is the class ara::core::InstanceSpecifier (local name in the software developers realm)
ara::core::InstanceSpecifierThe API ara:com provides the translation between these two.
namespace ara {
namespace com {
namespace runtime {
ara::com::InstanceIdentifierContainer ara::com::runtime::ResolveInstanceIDs(ara::core::InstanceSpecifier modelName);
}
} // namespace com
} // namespace araThe above function convert from local name to technical one.
ara::com::InstanceIdentifierContainer represents a collection of ara::com::InstanceIdentifier, which means, meanings one local name one (for software component developer) can mapping to multiple technical bindings.
one local to multiple bindings for skeleton/server is common, the client can use their preferred binding.
one local to multiple bindings for proxy/client is rare, e.g., to support some fail-over approaches. (binding A not work then we can count on binding b)
Service Instance Manifest, ara::core::InstanceSpecifier must be unambiguous within the bundled service instance manifest.
Proxy Class
Proxy class is generated from the service interface description of the AUTOSAR meta model.
Then we can see from the generated “abstract class” or a “mock class” against which the application developer could implemement his service consumer application.
Then see from the example code, we know or class RadarServiceProxy:
Pay attention to static , the generated code, they are the framework help functions (static function for whole class) for Service Proxy in client side.
HandleType
hidden for app dev
platform vendor is responsible
StartFindService
handler, gets called any time the service availability of the matching services changes.
instanceId, type is ara::com::InstanceIdentifier
return FindServiceHandle, which shall be used to stop the availability monitoring and related firing of the given handler.
StartFindServe (with different signature)
static void StopFindService(ara::com::FindServiceHandle handle);static ara::com::ServiceHandleContainer<RadarServiceProxy::HandleType>FindService(ara::com::InstanceIdentifier instanceId);synchronous
does reflect the availability at the time of the method call. No further (background) checks of availability are done.
FindService(overloads)ara::core::InstanceSpecifier
void , ALL instance of the service shall be found
explicit RadarServiceProxy(HandleType &handle);Here we can see the HandleType (hidden from app dev? Implementation side, contains InstanceIdendifier, for Client to specify the service)
HandleType is used to identify a service
Other class instance related operation config (c++ wise)
not copy constructible
not copy assignable
Public Members
Events
Fields
methods
Constructor and Handle Concept
ctor
Signature: explicit RadarServiceProxy(HandleType &handle);
After the call to the ctor you have a proxy instance for communicating with the service. The handle contains the addressing information for the service, which Communication Management binding implementation use to set the contact.
What exactly this address information in HandleType contains is totally dependent on the binding implementation/technical transport layer!
For an application developer, he only need to pay attention to his application implementation, and be independent of Communication Management.
For AUTOSAR Binding Implementation detail. We skip for now.
Finding Services
StartFindService
notifies the caller via a given callback(handler) any time the availability changes
yes
FindService
at the point in time of the call
yes
Both of those methods come in three different overrides:
one taking an ara::com::InstanceIdentifier
one taking an ara::core::InstanceSpecifier
one taking NO argument
For StartFindService:
For StartFindService -> FindServiceHandler,
StartFindService returns a FindServiceHandle, which can be used to stop the ongoing background activity of monitoring service instance availability via call to StopFindService.
For FindService:
Auto Update Proxy Instance
Access to proxy instance within FindService handler
Events
Example code generated:
It is the type of one member in RadarServiceProxy.
Event specific wrapper class. It is used to access events/event data.
Listing 6.7: Proxy side BrakeEvent Class
Service Proxy - Event related Data type RadarServiceProxy - BrakeEvent - RadarObjects
Event Subscription and Local Cache
You have to "subscript" for the event, in order to tell hte Communication Mangement, that you are now interested in receiving events.
For Subscribe, parameter maxSampleCount can be passed. CM then knows it, also "local cache" should be set up, which is also implemented by CM.
Monitoring Event Subscription
LEAVE BLANK.
Accessing Event Data - aka Samples
Event Sample Management via SamplePtrs
SamplePtrsEvent-Driven v.s. Polling-Based access
Explanation: In myRadarProxy->BrakeEvent.GetNewSamples
the first parameter,
F&& f.Function:
&& means, that this overload will be used only for rvalue object. So for this F&&, it depends on F. And F is
void(ara::com::SamplePtr<SampleType const>)the second parameter has default value
Buffering Strategies
Implementation specific. Skip.
Methods
Event-Driven v.s. Polling access to method results
Fields
Just like Event + Method
Skeleton Class
Example Code
Instantiation
Skeleton: a usually rigid supportive or protective structure or framework of an organism.
Service Implementation should subclass from the skeleton class.
Identifier (in the ctor) should be unique.
A static member function Preconstruct checks the provided identifier.
Offering Service Instance
Polling and event-driven processing modes
Procssing Default one is kEvent.
Polling Mode
In kPoll, the Communication Management implementation will not call any of the provided service methods asynchronously.
Event-Driven Mode
Methods
Last updated