From 8aea350947a4d5315707dd36256b316eb1d53515 Mon Sep 17 00:00:00 2001 From: Ulrich Huber Date: Wed, 22 Jan 2025 14:12:03 +0100 Subject: [PATCH] communication: Feature request A feature request for a communication framework. Currently this is based on IPC communication. --- docs/features/communication/ipc/index.rst | 340 ++++++++++++- .../communication/ipc/requirements/index.rst | 473 ++++++++++++++++++ 2 files changed, 812 insertions(+), 1 deletion(-) create mode 100644 docs/features/communication/ipc/requirements/index.rst diff --git a/docs/features/communication/ipc/index.rst b/docs/features/communication/ipc/index.rst index ce7b68d1..01bfdb35 100644 --- a/docs/features/communication/ipc/index.rst +++ b/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 `_. +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 `_. 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 `_. + +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 +================= + diff --git a/docs/features/communication/ipc/requirements/index.rst b/docs/features/communication/ipc/requirements/index.rst new file mode 100644 index 00000000..653085e7 --- /dev/null +++ b/docs/features/communication/ipc/requirements/index.rst @@ -0,0 +1,473 @@ +.. + # ******************************************************************************* + # Copyright (c) 2024 Contributors to the Eclipse Foundation + # + # See the NOTICE file(s) distributed with this work for additional + # information regarding copyright ownership. + # + # This program and the accompanying materials are made available under the + # terms of the Apache License Version 2.0 which is available at + # https://www.apache.org/licenses/LICENSE-2.0 + # + # SPDX-License-Identifier: Apache-2.0 + # ******************************************************************************* + +Requirements +############ + +High cohesion and loose coupling +================================ + +.. feat_req:: Standardized service contract + :id: FEAT_REQ__ipc__standardized_service_contract + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall provide the means to define service interfaces in a reusable manner. + +.. feat_req:: Service reference autonomy + :id: FEAT_REQ__ipc__service_reference_autonomy + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Service discovery solely requires an identifier to find appropriate services. + Any deployment information is only supplied in a configuration file read at runtime. + Note: If deployment information is missing, this may have impact on the service discovery. + +.. feat_req:: Service location transparency + :id: FEAT_REQ__ipc__service_location_transparency + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The interface to access services is agnostic to the binding used to communicate with the service. + Note: Deployment information may require manual changes based on where the service is located. + +.. feat_req:: Service abstraction + :id: FEAT_REQ__ipc__service_abstraction + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Communication with a service shall only happen via the interface of the service. A communication partner shall + not require knowledge about internals of the service to interact with it. + +.. feat_req:: Service autonomy + :id: FEAT_REQ__ipc__service_autonomy + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall provide the means to define independent communication interfaces. + +.. feat_req:: Service statelessness + :id: FEAT_REQ__ipc__service_statelessness + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support stateless communication. + Note: + - In case of events, the producer is not aware of its consumers. + - In case of RPC, the skeleton is not aware of the proxy, this request originated from. + +.. feat_req:: Service granularity + :id: FEAT_REQ__ipc__service_granularity + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall allow multiple services per SW component. + +.. feat_req:: Service discovery + :id: FEAT_REQ__ipc__service_discovery + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall provide service discovery to find available services during runtime. + Note: The service discovery may be restricted/impacted by availability of deployment information. + +.. feat_req:: Service interface elements + :id: FEAT_REQ__ipc__service_interface_elements + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2,STKH_REQ__282,STKH_REQ__283 + :status: valid + + A service interface consists of a combination of any number of the following elements: + - Events + - Methods + +.. feat_req:: Event + :id: FEAT_REQ__ipc__event + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__282 + :status: valid + + An event in a service interface is an element that has: + + - a name + - a type + + The service offering the event can assign a value to it. + Consumers can subscribe to changes to the value of the element or poll unseen, cached values. + +.. feat_req:: Method + :id: FEAT_REQ__ipc__method + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__283 + :status: valid + + A method in a service interface is an element that has: + + - a name + - a specified application routine with a given set of parameters and a return type + + When a communication partner issues a call to the method with the required parameters: + + 1. it shall invoke the application routine with the provided parameters, and + 2. return its result to the communication partner + + A method call shall be possible both synchronously and asynchronously. + +.. feat_req:: Producer-Consumer Pattern + :id: FEAT_REQ__ipc__producer_consumer + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__2,STKH_REQ__281 + :status: valid + + Communication shall be cached based on the producer-consumer pattern. + +.. feat_req:: Support for Time-based Architecture + :id: FEAT_REQ__ipc__time_based_arch + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__281 + :status: valid + + The communication framework shall provide API to support a time-based architecture. + +.. feat_req:: Support for Data-driven Architecture + :id: FEAT_REQ__ipc__data_driven_arch + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__282 + :status: valid + + The communication framework shall provide API to support a data-driven architecture. + +.. feat_req:: Support for Request-driven Architecture + :id: FEAT_REQ__ipc__request_driven_arch + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__282 + :status: valid + + The communication framework shall provide API to support a request-driven architecture. + +Mixed-Criticality safety systems +================================ + +.. feat_req:: Safe communication over criticality levels + :id: FEAT_REQ__ipc__safe_communication + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support safe communication involving communication partners on the same or multiple + criticality levels. + +.. feat_req:: Data Corruption + :id: FEAT_REQ__ipc__data_corruption + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Consumers with lower criticality shall not be able to corrupt data consumed by partners with higher criticality. + +.. feat_req:: Data Reordering + :id: FEAT_REQ__ipc__data_reordering + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Consumers with lower criticality shall not be able to modify the order of data consumed by partners with higher + criticality. + +.. feat_req:: Data Repetition + :id: FEAT_REQ__ipc__data_repetition + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Consumers with lower criticality shall not be able to duplicate data consumed by other communication partners with + higher criticality. + +.. feat_req:: Data Loss + :id: FEAT_REQ__ipc__data_loss + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Consumers with lower criticality shall not be able to drop data before it is consumed by partners with higher + criticality. + +Performance +=========== + +.. feat_req:: Zero-Copy IPC + :id: FEAT_REQ__ipc__zero_copy + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2,STKH_REQ__282 + :status: valid + + IPC communication shall be possible without copying to be transferred data. + +User friendly API for information exchange +========================================== + +.. feat_req:: Support for multiple programming languages + :id: FEAT_REQ__ipc__multi_lang + :reqtype: Non-Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__260 + :status: valid + + The communication framework shall provide a public API for each supported programming language of SCORE. + +.. feat_req:: Support for programming language idioms + :id: FEAT_REQ__ipc__lang_idioms + :reqtype: Non-Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__260 + :status: valid + + Each public API shall support the idioms of the programming language it is written in. + +.. feat_req:: Use programming language infrastructure + :id: FEAT_REQ__ipc__lang_infra + :reqtype: Non-Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__260 + :status: valid + + Each public API shall use core infrastructure of its programming language and accompanying standard libraries, + whenever possible and meaningful. + +Full testability for the user facing API +======================================== + +.. feat_req:: Fully mockable public API + :id: FEAT_REQ__ipc__testability_mock_api + :reqtype: Non-Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2 + :status: valid + + The public API shall be fully mockable. + +.. feat_req:: Fake binding + :id: FEAT_REQ__ipc__testability_fake_binding + :reqtype: Non-Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall provide a fake binding. + +Multi-binding support +===================== + +.. feat_req:: Multi-binding support + :id: FEAT_REQ__ipc__multi_binding_support + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support multiple bindings. + +.. feat_req:: Binding-agnostic public API + :id: FEAT_REQ__ipc__binding_agnostic_api + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2 + :status: valid + + The public API of the communication framework shall be binding-agnostic. + +.. feat_req:: Multi-binding deployment configuration + :id: FEAT_REQ__ipc__multi_binding_depl + :reqtype: Functional + :security: NO + :safety: QM + :satisfies: STKH_REQ__2 + :status: valid + + The association of a service instance and the appropriate binding shall be specified in the deployment configuration. + +Dynamic deployment at runtime +============================= + +.. feat_req:: Deployment configuration at runtime + :id: FEAT_REQ__ipc__depl_config_runtime + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + Deployment configuration shall be read from a configuration file at runtime. + +Tracing +======= + +.. feat_req:: Support for Tracing + :id: FEAT_REQ__ipc__tracing + :reqtype: Functional + :security: NO + :safety: ASIL_B + :satisfies: STKH_REQ__242 + :status: valid + + The communication framework shall provide infrastructure to enable binding-agnostic zero-copy tracing of + communication. + +Security Impact +=============== + +.. feat_req:: Access Control List Placement + :id: FEAT_REQ__ipc__acl_placement + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support an Access Control Lists in the deployment configuration. + +.. feat_req:: Access Control List per service instance + :id: FEAT_REQ__ipc__acl_per_service_instance + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support an Access Control List per service instance. + +.. feat_req:: Access Control List for producer + :id: FEAT_REQ__ipc__acl_for_producer + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support an Access Control List for the communication partner offering a service + instance (producer). + An entry in the ACL corresponds to an allowed consumer. + +.. feat_req:: Access Control List for consumer + :id: FEAT_REQ__ipc__acl_for_consumer + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support an Access Control List for the communication partner consuming a service + instance. + An entry in the ACL corresponds to an allowed producer. + +.. feat_req:: IPC Confidentiality + :id: FEAT_REQ__ipc__confidentiality + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The IPC binding shall ensure confidentiality of its communication. + +.. feat_req:: IPC Integrity + :id: FEAT_REQ__ipc__integrity + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The IPC binding shall ensure integrity of its communication. + +.. feat_req:: IPC Availability + :id: FEAT_REQ__ipc__availability + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The IPC binding shall ensure availability of its communication, so that the availability is independent per + criticality level. + +Safety Impact +============= + +.. feat_req:: IPC ASIL level + :id: FEAT_REQ__ipc__asil + :reqtype: Functional + :security: YES + :safety: ASIL_B + :satisfies: STKH_REQ__2 + :status: valid + + The communication framework shall support safe communication up to ASIL-B.