Architecture#
Overview#
An brief overview of communication is described here.
Description#
A description of the communication module is located here
Static Architecture#
As discussed in Rationale, the overall architecture of the communication framework must be layered. This is required, to separate the frontend from the underlying communication mechanisms (also called bindings).
This ensures a stable public API, independent of the underlying binding(s). At the same time, the communication framework can support many different communication protocols in a flexible manner.
Feature Architecture Communication
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
In the following sections we will look on the different architectural elements of the communication framework in more detail.
Frontend#
The frontend is responsible of providing a stable public API to the user. In general, the communication framework (mw::com) follows the client-server, pub-sub and producer-consumer patterns.
Following these patterns, the user interacts with different APIs depending on whether he is producer/server or consumer/client.
A producer creates a Skeleton to communicate with consumers. Each consumer creates a Proxy to connect to a producer. Consumers can find available producers through a service discovery mechanism. This mechanism is tightly bound to the Proxy, to only discover producers offering a compatible implementation of a Skeleton.
Fig. 1 Communication through mw::com#
In addition to these elements, a runtime singleton is used for background tasks to reduce resource consumption. This runtime is invisible to the user. This runtime is responsible for service discovery (explained in Service Discovery), notification reception and other infrastructure tasks.
Compatibility of Skeleton and Proxy is currently defined by them sharing the same communication interface. Additionally, versioning will be taken into account in the future (see Roadmap).
The communication interface for now consists of events. Support for methods and signals will be added in the future (see Roadmap).
Since S-CORE supports strongly typed programming languages, the API of Skeleton and Proxy is also strongly typed. Instead of a code generator, we utilize features like templates in C++ and macros in Rust to “generate” the necessary code at compile time.
But there are some “niche” use cases, where the need to “regenerate” and recompile the Proxy can be detrimental. This is the case when:
signatures are trivial and changes/differences between them are minimal
the communicated data/payload gets handled very generically (loosely typed) anyhow
the communicated data/payload has to get deep-inspected based on additional/separate type-information anyhow
For these cases mw::com provides a GenericProxy that allows introspection of communication interfaces at runtime.
While the frontend is based on a communication model, it is independent from any communication protocol. Therefore, it always forwards user requests to the binding(s) underneath. Which bindings to use is defined in a configuration file.
A multi-binding approach is chosen, where API calls are mapped to a set of selected bindings.
Interface Description#
The public API for the frontend is defined as:
Communication User Interface
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Bindings#
The need for bindings was discussed in Multi-binding support. Bindings reside beneath the frontend layer and accept the forwarded requests
Currently, the available bindings are: