IPC Safety Work Products List#

Communication IPC Safety WPs
status: draft
security: YES
safety: ASIL_B
version: 2

Tailoring#

Additional to the tailoring in the SW platform project as defined in the doc__platform_safety_plan we define here the additional tailoring on feature level.

  • The feature level artefacts are additionally partly tailored as in below list, as we use an “external” SEooC which provides the feature level artefacts as linked below.

  • There is an overlap in two work products between the expectation formulated in the feature request, which defines feature requirements and interfaces and the work products provided in Communication Repository. Both versions are linked below. A comparison of these has to be performed and inconsistencies resolved as part of inspections - see ticket

  • AoU in Communication Repository are provided in a different format as needed by S-CORE documentation (e.g. the safety manual), so a copy of the AoU in docs_as-code format has to be provided. Original and Copy are linked below. It need to be confirmed that those are equal as part of inspections - see ticket

Inter-process Communication Safety Work Products#

Note: Above links to communication repository are to the version as defined in reference integration.

Feature Safety Package#

To create the safety package (according to gd_guidl__saf_package) the following documents and work products status have to go to “valid” (after the relevant verification were performed).

Feature Documents Status#

For all the work product documents the status can be seen by following the “Link to WP”. A summary of the status is also documented in the project’s documentation management plan.

See Communication

Feature Requirements Status#

ID

Status

feat_req__com__acl_for_consumer

valid

feat_req__com__acl_for_producer

valid

feat_req__com__acl_per_service_instance

valid

feat_req__com__acl_placement

valid

feat_req__com__async_support

valid

feat_req__com__bi_directional_comm

valid

feat_req__com__binding_agnostic_api

valid

feat_req__com__asil

valid

feat_req__com__interfaces

valid

feat_req__com__config_notifications

valid

feat_req__com__configurable_queues

valid

feat_req__com__consistent_data

valid

feat_req__com__data_corruption

valid

feat_req__com__data_loss

valid

feat_req__com__data_reordering

valid

feat_req__com__data_repetition

valid

feat_req__com__data_notifications

valid

feat_req__com__depl_config_runtime

valid

feat_req__com__event_type

valid

feat_req__com__testability_fake_binding

valid

feat_req__com__testability_mock_api

valid

feat_req__com__lock_free_access

valid

feat_req__com__lock_free_queue

valid

feat_req__com__method

valid

feat_req__com__multi_binding_depl

valid

feat_req__com__multi_binding_support

valid

feat_req__com__one_way_sharing

valid

feat_req__com__producer_timestamps

valid

feat_req__com__producer_consumer

valid

feat_req__com__readonly_vm

valid

feat_req__com__safe_communication

valid

feat_req__com__service_discovery

valid

feat_req__com__service_instance

valid

feat_req__com__service_instance_names

valid

feat_req__com__service_instance_granularity

valid

feat_req__com__service_location_transparency

valid

feat_req__com__shared_memory

valid

feat_req__com__signal

valid

feat_req__com__stateless_communication

valid

feat_req__com__streamed_data

valid

feat_req__com__data_driven_arch

valid

feat_req__com__multi_lang

valid

feat_req__com__lang_idioms

valid

feat_req__com__request_driven_arch

valid

feat_req__com__time_based_arch

valid

feat_req__com__tracing

valid

feat_req__com__lang_infra

valid

feat_req__com__versioning

valid

feat_req__com__zero_copy

valid

Test and traceability status in communication repository: https://eclipse-score.github.io/communication/latest/docs/sphinx/mw_com_index/traceability_report/feature_requirements.html

Feature AoU Status#

The original AoUs are in communication repository and are not documented as sphinx-needs, these are “valid” as soon as merged.

Feature Architecture Status#

The main architectural views are in communication repository and are not documented as sphinx-needs, these are “valid” as soon as merged.