communication: Feature request

A feature request for a communication framework.
Currently this is based on IPC communication.

docs/features/communication/ipc/index.rst

@@ -13,4 +13,342 @@
    # *******************************************************************************
 
 Inter-process Communication
-###########################
+===========================
+
+.. document:: Inter-process Communication
+   :id: DOC__IPC
+   :status: valid
+   :safety: ASIL_B
+   :tags: contribution_request, feature_request
+
+
+.. toctree::
+   :hidden:
+
+   requirements/index.rst
+
+
+Feature flag
+============
+
+To activate this feature, use the following feature flag:
+
+``experimental_ipc``
+
+Abstract
+========
+
+This contribution describes a framework to exchange information between processes.
+This framework includes:
+
+- an abstraction layer to enable different communication mechanisms
+- a communication mechanism that enables zero-copy communication
+
+The abstraction layer is designed in a way to ensure full testability for an end-user, while enabling runtime selection
+of the underlying communication mechanism.
+It provides the user with a high-level API to focus on the content of information – and not on low-level synchronization
+primitives.
+The proposed communication mechanism (called LoLa) is optimized for micro-kernel operating systems (like e.g. QNX). By
+utilizing shared memory, it enables low latency communication also for mixed-criticality systems (e.g. processes of
+different safety integrity level). The possibility for mixed-criticality systems is especially enabled by certain
+implementation choices and safety mechanisms that will continue to ensure freedom from interference between separate
+processes.
+
+.. _Motivation:
+
+Motivation
+==========
+
+SCORE is targeting high-performance automotive systems with safety impact. In general, these systems consist of multiple
+processes that are executed on an operating system. To fulfill the system needs, these processes need to exchange
+information in most of the cases.
+
+Key aspects of SCORE and therefore also the IPC communication framework are:
+
+1. High cohesion and loose coupling
+2. Mixed-criticality safety systems
+3. Performance
+
+In the following we will explain and argue each of these three different aspects. Further secondary aspects will follow
+in the section :ref:`Specification` where we also formalize all aspects.
+
+High cohesion and loose coupling
+--------------------------------
+
+Complex systems require high cohesion and loose coupling to remain maintainable.
+A widely adopted architecture to reach this is the
+`service-oriented architecture <https://en.wikipedia.org/wiki/Service-oriented_architecture>`_.
+It separates the system into services, where the interaction happens through a communication framework.
+To seamlessly integrate into this architectural approach, the communication framework shall facilitate a
+service-oriented approach.
+
+Services in regard to the communication framework consist of a selection of events and remote-procedure-calls, which
+make up the service interface.
+This enables a software component to provide a clear API with logical cohesion to other components.
+The producer-consumer pattern is used for communication between services to decouple them and allow more flexible
+scheduling.
+
+.. _mot_mixed_criticality:
+
+Mixed-Criticality safety systems
+--------------------------------
+
+In complex safety-critical systems, applications often have different criticality.
+Communication happens not only on the same criticality level but also between different criticality levels.
+
+For example, a service with low-criticality may provide data to a highly critical application.
+Or the reverse could be the case, where a less critical application depends on data produced by a highly critical one.
+More complex scenarios are also possible, where the same data is consumed by multiple recipients with different
+criticality.
+
+Hence, it is crucial that applications can not only safely communicate on the same criticality level.
+They must be able to also safely communicate between different criticality levels.
+
+Support for mixed criticality is a core feature of a communication framework. Hence, it greatly impacts architectural
+decisions and influences many other aspects. One of them being performance, which is the third primary aspect of a
+communication framework.
+
+Performance
+-----------
+
+In the recent years high-performance automotive systems rely more and more on communication of huge amounts of data.
+This communication must be performant, to enable decomposition of the system.
+With ever increasing complexity of the tasks automotive systems must tackle, this trend will continue in the future.
+Hence, architectural decisions for the communication framework must ensure scalable performance.
+
+In general, good scalable performance can be decomposed into two aspects:
+
+1. High throughput
+2. Low latency
+
+To achieve both, only zero-copy approaches are feasible.
+Further, reliable low-latency communication is only possible with appropriate scheduling.
+Meaning, if a consumer is not scheduled when he receives an event, the latency of the communication is out of the hand
+of the communication framework.
+Thus, the communication framework must be capable to interact with the scheduler to influence the scheduling behavior.
+
+For mixed-criticality safety systems this means, that the original non-duplicated data must be provided to consumers
+with different criticality levels.
+
+The previous three key aspects and further aspects are formalized in the section :ref:`Specification`.
+
+Rationale
+=========
+
+.. _Specification:
+
+Specification
+=============
+
+To provide a clear picture of the base requirements to an IPC communication framework, we formalize the primary and
+secondary aspects in this section. For aspects that are mentioned for the first time, we also provide a rationale.
+For the previously presented primary aspects, please refer to the section :ref:`Motivation` for the rationale.
+
+High cohesion and loose coupling
+--------------------------------
+
+From the principles of a service-oriented architecture we derive the following requirements for the communication
+framework:
+
+1. :need:`FEAT_REQ__ipc__standardized_service_contract`
+2. :need:`FEAT_REQ__ipc__service_reference_autonomy`
+3. :need:`FEAT_REQ__ipc__service_location_transparency`
+4. :need:`FEAT_REQ__ipc__service_abstraction`
+5. :need:`FEAT_REQ__ipc__service_autonomy`
+6. :need:`FEAT_REQ__ipc__service_statelessness`
+7. :need:`FEAT_REQ__ipc__service_granularity`
+8. :need:`FEAT_REQ__ipc__service_discovery`
+
+Additionally, the communication framework must support all architecture types defined by SCORE.
+This leads to additional three requirements:
+
+9. :need:`FEAT_REQ__ipc__time_based_arch`
+10. :need:`FEAT_REQ__ipc__data_driven_arch`
+11. :need:`FEAT_REQ__ipc__request_driven_arch`
+
+Based on this, we specify in the requirement :need:`FEAT_REQ__ipc__service_interface_elements` the elements a service
+interface can consist of:
+
+- :need:`FEAT_REQ__ipc__event`
+- :need:`FEAT_REQ__ipc__method`
+
+To allow more flexible scheduling of the system and as a prerequisite of :need:`FEAT_REQ__ipc__time_based_arch`,
+the communication framework must support caching: :need:`FEAT_REQ__ipc__producer_consumer`
+
+.. _spec_mixed_criticality:
+
+Mixed-Criticality safety systems
+--------------------------------
+
+As discussed in the motivation the communication framework shall support mixed-criticality safety systems
+:need:`FEAT_REQ__ipc__safe_communication`.
+
+In the light of mixed-criticality safety systems and based on the failure modes for communication in the ISO26262,
+the communication framework gains four additional requirements:
+
+1. :need:`FEAT_REQ__ipc__data_corruption`
+2. :need:`FEAT_REQ__ipc__data_reordering`
+3. :need:`FEAT_REQ__ipc__data_repetition`
+4. :need:`FEAT_REQ__ipc__data_loss`
+
+The communication framework does not take timing related failure modes into account, since the overall stack must
+consider such failure modes on a more generic level.
+
+Performance
+-----------
+
+Based on the discussion in the motivation, the specific use cases can be condensed to the overall requirement to support
+zero-copy IPC (:need:`FEAT_REQ__ipc__zero_copy`).
+
+For now, there is no requirement to support zero-copy communication for other protocols.
+While this may be of interest in the future, it remains for now out of scope.
+
+User friendly API for information exchange
+------------------------------------------
+
+Programming languages have their own feature set and idioms.
+It is crucial for any library that it seamlessly integrates into both.
+This means, wherever possible and meaningful, infrastructure of the programming language and accompanying standard
+libraries shall be reused.
+Further, a developer used to the programming language shall have no problems understanding the API.
+It should feel natural to use.
+
+1. :need:`FEAT_REQ__ipc__lang_idioms`
+2. :need:`FEAT_REQ__ipc__lang_infra`
+
+Since SCORE supports multiple programming languages (see :need:`STKH_REQ__260`), this leads to multiple APIs that might
+diverge significantly from each other, but provide the same feature set to the user.
+To support something like this, without reimplementing the full communication stack in both languages, an abstraction
+layer within the communication framework is unavoidable.
+
+:need:`FEAT_REQ__ipc__multi_lang`
+
+Full testability for the user facing API
+----------------------------------------
+
+Our users will be required to proof certain coverage metrics, like line coverage or MC/DC coverage.
+For them to reach full coverage, they need to be easily able to mock or fake parts of the communication systems in their
+unit tests.
+Most of the current solutions (e.g. ara::com) keep this outside their requirements.
+This forces the users to introduce an additional abstraction layer over the communication framework to inject test
+doubles.
+This is additional work for the user, and abstraction layers come with a certain cost in runtime and maintenance.
+Our goal is to provide an API that requires no additional abstraction layer over the communication framework.
+
+:need:`FEAT_REQ__ipc__testability_mock_api`
+
+In some test scenarios users must fake communication.
+Instead of mocking the fine-granular behavior of the framework, users shall be able to simulate communication simply by
+providing an implementation of the communication partner in the test environment. For IPC this does not require big
+architectural decisions. In the light of a robust API that also supports communication between multiple hosts,
+this can be achieved through multi-binding support.
+
+:need:`FEAT_REQ__ipc__testability_fake_binding`
+
+Multi-binding support
+---------------------
+
+In the beginning, SCORE will only provide inter-process communication.
+But this will not suffice for later.
+A communication for high-performance automotive systems with safety impact will require support for communication to
+other VMs or hosts.
+
+Following the principles of service-oriented architecture, we introduce multi-binding support.
+
+:need:`FEAT_REQ__ipc__multi_binding_support`
+
+To enable service location transparency, the public API is designed to be binding-agnostic.
+
+:need:`FEAT_REQ__ipc__binding_agnostic_api`
+
+The framework forwards requests to the public API to the appropriate binding of the service instance.
+Bindings are specified in the deployment configuration.
+
+:need:`FEAT_REQ__ipc__multi_binding_depl`
+
+Some possible bindings are:
+
+- IPC  (see :need:`STKH_REQ__2`)
+- SOME/IP (see :need:`STKH_REQ__160`)
+- DDS (see :need:`STKH_REQ__160`)
+- fake binding (for testing)
+
+Dynamic deployment at runtime
+-----------------------------
+
+Service-oriented architecture has as one of its principles
+`Service reference autonomy <https://en.wikipedia.org/wiki/Service-oriented_architecture#Principles>`_. This can be
+achieved with another of its principles, namely `Service discovery`.
+
+In the light of safety, security and startup requirements, full `Service reference autonomy` through `Service discovery`
+is not easily achievable.
+For this reason, most implementations prefer a limited `Service reference autonomy` and supply partial deployment
+information in advance.
+We too provide partial deployment information through configuration files read at runtime.
+This information is enriched through a runtime `Service discovery` to follow the service-oriented architecture approach.
+
+:need:`FEAT_REQ__ipc__depl_config_runtime`
+
+Tracing
+-------
+
+Based on :need:`STKH_REQ__242` the communication framework must support tracing of communication events.
+In a framework with multiple bindings, this requires a zero-copy binding-agnostic tracing solution in the abstraction
+layer.
+
+:need:`FEAT_REQ__ipc__tracing`
+
+Backwards Compatibility
+=======================
+
+As there is currently no previous solution for communication in SCORE, no backwards compatibility is required.
+
+Security Impact
+===============
+
+Security of communication is important for the security of the overall system.
+To efficiently handle security with the least amount of overhead, each binding must determine the best security approach
+for its circumstances.
+
+Depending on the binding, the security approach may achieve different
+`security goals <https://en.wikipedia.org/wiki/Information_security#Security_Goals>`_.
+
+To provide users a generic concept of security configuration, the chosen solution of every binding must map at least
+to an Access Control List (ACL) concept, but may have additional deployment configuration options.
+
+The ACL of each service instance is defined in the deployment configuration of producer and consumer.
+
+- :need:`FEAT_REQ__ipc__acl_placement`
+- :need:`FEAT_REQ__ipc__acl_per_service_instance`
+
+Entries in the ACL of:
+
+- the producer list the allowed consumers (:need:`FEAT_REQ__ipc__acl_for_producer`)
+- the consumer list the allowed producers (:need:`FEAT_REQ__ipc__acl_for_consumer`)
+
+IPC Security Goals
+------------------
+
+The security approach of the IPC binding achieves the security goals:
+
+- confidentiality (:need:`FEAT_REQ__ipc__confidentiality`)
+- integrity (:need:`FEAT_REQ__ipc__integrity`)
+- availability (per criticality-level) (:need:`FEAT_REQ__ipc__acl_placement`)
+
+Safety Impact
+=============
+
+The safety impact was already exhaustively covered in :ref:`mot_mixed_criticality` and :ref:`spec_mixed_criticality`.
+
+Overall, the communication framework supports use cases up to ASIL-B (:need:`FEAT_REQ__ipc__asil`).
+Future extension to ASIL-D use cases is feasible but not in scope for now.
+
+License Impact
+==============
+
+[How could the copyright impacted by the license of the new contribution?]
+
+
+How to Teach This
+=================
+