Create a POC for implementing Control API using mw::com

[NicolasFussberger]

What

Goal:

• Get experience using mw::com
• Evaluate if ControlClient can be implemented using mw::com
• Collect the pros & cons

Acceptance Criteria (DoD)

• POC available
• Description with the result is available

How

No response

[NicolasFussberger]

High-level design

LaunchManager mw::com POC implementation
Control API mw::com POC implementation
Smoketest with mw::com

Service Design

Option 1 (implemented in the POC)

Combine fire&forget method to request run target change, with asynchronous event containing the result of this request.
Note: Asynchronous methods (methods returning Future) are not available in mw::com as of now.

We might want to have a service instance per client with this design, we cannot differentiate clients on the server sides - events would be sent to all clients. Unclear if a client-specific request_id can be created (e.g. there might be a SOME/IP client on a different machine).

Option 2

Combine a synchronous method with an asynchronous event.
The synchronous method is used to send the request and LaunchManager returns a unique request_id.
Later the event is published with the result, containing the unique request_id.
Problem: The synchronous method might block for some time, if remote connection is configured instead of an IPC call.

Summary

ControlClient can be implemented with mw::com. Various alternative designs exist.

Evaluation

Discovered Problems

Dependency Chain:

• mw::com depends on baselibs
• LaunchManager also depends on baselibs
  --> There can be conflicting versions. We may not be able to update to the latest baselibs version if mw::com is not updating

Proxy/Skeleton creation requires InstanceSpecifier

• We can adapt Control API to provide the InstanceSpecifer in the constructor
• We can pass the InstanceSpecifier to LaunchManager via CLI

mw::com json configuration file

• The user of ControlAPI needs to manually call e.g. score::mw::com::runtime::InitializeRuntime(argc, argv) to pass a non-standard file path so the mw::com runtime can find the mw::com json file.
• The LaunchManager needs to be started with additional CLI flags "--service-instance-manifest " to forward the mw::com json file to the mw::com Runtime.
• The integrator needs to take care to provide these configuration files. We can provide a starting point, but not necessarily the complete file (StateManager application might use other mw::com services as well).

Summary

Criteria	Existing custom IPC	mw::com POC
Use Cases	Local IPC only	Local IPC + Remote commnication (required?)
Resource Consumption	+ Low, can be further optimized for the specific use case	- Higher (see below) Relatively high resources for the small amount of communication required
Lifecycle Code Complexity	- High Usage of low-level posix primitives to implement shared memory communication	+ Low Usage of high level constructs from mw::com
Integration	0 No effort for IPC Remote communication requires custom implementation on top of Control API	- Manual creation of json files. Providing additional CLI flags for locating the json files. Integrator needs to configure internal communication when using Control API

Improvement Ideas:

• If mw::com would provide a configuration API (even just taking a json string instead of file) maybe we could hardcode the configuration for the common default case. Still providing the possibility to configure via json alternatively for advanced cases (e.g. SOMEIP binding).
• To be investiagted if resource consumption using mw::com can be reduced. E.g. do we need the service discovery thread within the launch manager when we are only offering a service instance?

Some Performance Metrics

Metrics gathered with the mw::com POC implementation for ControlClient API on Linux (Docker), comparing the /proc/pid/status file for LaunchManager and StateManager. This is not a detailed analysis and should only give a rough impression.

• Thread stack size has been set to 64kb
• LaunchManager configured with 12 worker threads
• Single mw::com service instance is used

Summary for LaunchManager + Dummy StateManager

	Existing custom IPC	mw::com	Delta
Total RSS (physical)	7.5 MB	13.2 MB	+5.8 MB
- Private heap (RssAnon)	0.6 MB	0.9 MB	+0.2 MB (non-shareable)
- Mapped libs (RssFile)	6.8 MB	12.4 MB	+5.6 MB (shareable)
Heap reserved (VmData)	2.2 MB	3.0 MB	+0.9 MB
Binary size (VmExe)	2.9 MB	6.7 MB	+3.9 MB
Threads	17	24	+7 (LaunchManager +4, StateManger +3)

Detailed data separating LaunchManager and Dummy StateManager

Metric	Existing custom IPC LM	mw::com LM	Existing custom IPC SM	mw::com SM
VmRSS (physical RAM)	4,000 kB	6,836 kB	3,640 kB	6,716 kB
RssAnon (heap/stack)	464 kB	564 kB	180 kB	312 kB
RssFile (mapped files/libs)	3,532 kB	6,272 kB	3,456 kB	6,392 kB
RssShmem (shared memory)	4 kB	0 kB ??	4 kB	12 kB
VmSize (virtual)	204,084 kB	274,040 kB	71,864 kB	75,900 kB
VmPeak (peak virtual)	204,088 kB	339,580 kB	137,400 kB	141,288 kB
VmData (heap)	1,756 kB	2,292 kB	456 kB	808 kB
VmStk (main thread stack)	64 kB	64 kB	64 kB	64 kB
VmExe (code segment)	1,484 kB	3,508 kB	1,484 kB	3,364 kB
VmLib (shared libs)	2,304 kB	2,304 kB	2,304 kB	2,304 kB
Threads	15	19	2	5