IPC Safety Work Products List#
Communication IPC Safety WPs
|
status: draft
security: YES
safety: ASIL_B
|
||||
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#
Workproduct Id |
Link to process |
Process status |
Link to WP |
|---|---|---|---|
valid |
Inter-process Communication (doc__com_ipc), Communication (doc__com) |
||
valid |
IPC Requirements (doc__ipc_requirements), Communication Requirements (doc__communication_requirements) eclipse-score/communication |
||
valid |
Communication Assumptions o... (doc__communication_aou), eclipse-score/communication |
||
valid |
Communication Architecture (doc__communication_architecture), eclipse-score/communication |
||
valid |
|||
valid |
covered by safety analysis link above |
||
valid |
partly tailored as several checks are automated, gap analysis tbd, check score vs. communication repo |
||
valid |
partly tailored as several checks are automated, gap analysis tbd, check score vs. communication repo |
||
valid |
<Link to WP> |
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 |
|---|---|
valid |
|
valid |
|
valid |
|
valid |
ID |
Status |
|---|---|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
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#
ID |
Status |
|---|---|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
|
valid |
The original AoUs are in communication repository and are not documented as sphinx-needs, these are “valid” as soon as merged.
Feature Architecture Status#
ID |
Status |
|---|---|
valid |
The main architectural views are in communication repository and are not documented as sphinx-needs, these are “valid” as soon as merged.