Requirements#
Communication Requirements
|
status: valid
security: YES
safety: ASIL_B
|
||||
Support for Time-based Architecture
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall provide API to support a time-based architecture. |
|||||
Support for Data-driven Architecture
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall provide API to support a data-driven architecture. |
|||||
Support for Request-driven Architecture
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall provide API to support a request-driven architecture. |
|||||
Communication Interfaces
|
status: valid
security: NO
safety: ASIL_B
|
||||
A communication interface consists of a combination of any number of the following elements:
|
|||||
Event Type
|
status: valid
security: NO
safety: ASIL_B
|
||||
An event-type is part of a communication interface and has:
The producer can assign a value to it. Consumers can subscribe to value-changed events of the element or poll unseen, cached events. |
|||||
Method
|
status: valid
security: NO
safety: ASIL_B
|
||||
A method is part of a communication interface and has:
When a communication partner issues a call to the method with the required parameters:
A method call shall be possible both synchronously and asynchronously. |
|||||
Signal
|
status: valid
security: NO
safety: QM
|
||||
A signal is part of a communication interface and has:
A client can trigger the signal. The service instance offering the trigger can:
Note Signals can not transport data. They are meant to be fast synchronization mechanism with low setup cost. Thus, depending on the location of the communication partners primitives like Linux Signals or QNX Pulses or Hypervisor Signalling APIs may be chosen. |
|||||
Producer-Consumer Pattern
|
status: valid
security: NO
safety: ASIL_B
|
||||
Communication shall be cached based on the producer-consumer pattern. |
|||||
Service Instance
|
status: valid
security: NO
safety: ASIL_B
|
||||
Multiple service instances shall be able to offer the same interface. Note A communication interface that is offered to consumers is called a service instance. |
|||||
Service Instance Names
|
status: valid
security: NO
safety: ASIL_B
|
||||
A service instance is offered under one or more unique names by which it can be discovered. Names follow a POSIX path style. Note The resolution from a service instance name to the protocol-specific identifier is handled by the service discovery. |
|||||
Versioning
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall support versioning of service instances:
Note Multiple service instances can have the same interface and version. |
|||||
Service location transparency
|
status: valid
security: NO
safety: ASIL_B
|
||||
The interface to access service instances 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. |
|||||
Stateless communication
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall support stateless communication. Note
|
|||||
Service instance_granularity
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall support multiple service instances per software architecture element. Note A software architecture element is for example an application, activity, proces, … |
|||||
Service discovery
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall provide service discovery to find available services during runtime. Service discovery shall consider version compatibility. Service discovery shall be handled implicitly (where possible). Note The service discovery may be restricted/impacted by availability of deployment information. |
|||||
Mixed-Criticality safety systems#
Safe communication over criticality levels
|
status: valid
security: YES
safety: ASIL_B
|
||||
The communication framework shall support safe communication involving communication partners on the same or multiple criticality levels. |
|||||
Data Corruption
|
status: valid
security: YES
safety: ASIL_B
|
||||
Consumers with lower criticality shall not be able to corrupt data consumed by partners with higher criticality. |
|||||
Data Reordering
|
status: valid
security: YES
safety: ASIL_B
|
||||
Consumers with lower criticality shall not be able to modify the order of data consumed by partners with higher criticality. |
|||||
Data Repetition
|
status: valid
security: YES
safety: ASIL_B
|
||||
Consumers with lower criticality shall not be able to duplicate data consumed by other communication partners with higher criticality. |
|||||
Data Loss
|
status: valid
security: YES
safety: ASIL_B
|
||||
Consumers with lower criticality shall not be able to drop data before it is consumed by partners with higher criticality. |
|||||
Performance#
Zero-Copy Approach
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall enable Zero-Copy communication without copying to-be-transferred data. Note It has to be evaluated on binding level if a Zero-Copy approach is applicable for the respective binding. |
|||||
User friendly API for information exchange#
Support for multiple programming languages
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall provide a public API for each supported programming language of S-CORE. |
|||||
Support for programming language idioms
|
status: valid
security: NO
safety: QM
|
||||
Each public API shall support the idioms of the programming language it is written in. |
|||||
Use programming language infrastructure
|
status: valid
security: NO
safety: QM
|
||||
Each public API shall use core infrastructure of its programming language and accompanying standard libraries, whenever possible and meaningful. Note This includes error handling. |
|||||
Full testability for the user facing API#
Fully mockable public API
|
status: valid
security: NO
safety: QM
|
||||
The public API shall be fully mockable. |
|||||
Fake binding
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall provide a fake binding. |
|||||
Multi-binding support#
Multi-binding support
|
status: valid
security: NO
safety: QM
|
||||
The communication framework shall support multiple bindings. Note A binding performs the conversion of user communication to the respective communication protocol. It does this either directly or via a gateway approach. |
|||||
Binding-agnostic public API
|
status: valid
security: NO
safety: QM
|
||||
The public API of the communication framework shall be binding-agnostic. Note Binding-agnostic in this context means, that the public API is independent of the binding underneath. E.g., if the binding is exchanged, the public API remains syntactically and semantically unchanged. |
|||||
Multi-binding deployment configuration
|
status: valid
security: NO
safety: ASIL_B
|
||||
The association of a service instance and the appropriate binding shall be specified in the deployment configuration. |
|||||
Cross-VM Extensions#
One-way data sharing into a VM
|
status: valid
security: NO
safety: QM
|
||||
The system shall support one-way data sharing into a Virtual Machine (VM) for vehicle state read-only for the VM (snapshot state). |
|||||
Read-only access for VM
|
status: valid
security: NO
safety: QM
|
||||
The consumer (VM) shall have read-only access to the shared data. |
|||||
Consistent data-sets
|
status: valid
security: NO
safety: QM
|
||||
The system shall support consistent data-sets, allowing the consumer to obtain a consistent version of related data items. |
|||||
Lock-free access
|
status: valid
security: NO
safety: QM
|
||||
Consistent access to data must be lock-free. |
|||||
Producer time stamps
|
status: valid
security: NO
safety: QM
|
||||
Producer time stamps shall be available for related data-sets. |
|||||
Streamed data based on shared queues
|
status: valid
security: NO
safety: QM
|
||||
The system shall support streamed data based on shared queues (stream of events or data). |
|||||
Configurable queues
|
status: valid
security: NO
safety: QM
|
||||
Queues shall be configurable by the client (VM), including the number of elements and buffer allocation. |
|||||
Lock-free queue access
|
status: valid
security: NO
safety: QM
|
||||
Queues shall support lock-free access to data elements. |
|||||
Bi-directional communication
|
status: valid
security: NO
safety: QM
|
||||
The system shall support bi-directional communication via writable data elements by the client. |
|||||
Asynchronous support
|
status: valid
security: NO
safety: QM
|
||||
The system shall provide asynchronous bi-directional support via multiple queues. |
|||||
Shared memory chunks
|
status: valid
security: NO
safety: QM
|
||||
The system shall support multiple chunks of shared memory to allow required access control. |
|||||
Data update notifications
|
status: valid
security: NO
safety: QM
|
||||
Notifications for data updates shall be available (virtual IRQs in a VM). |
|||||
Configurable notifications
|
status: valid
security: NO
safety: QM
|
||||
Notifications shall be configurable by consumers of data (using flags or watermarks in shared memory from client to producer). |
|||||
Dynamic deployment at runtime#
Deployment configuration at runtime
|
status: valid
security: YES
safety: ASIL_B
|
||||
Deployment configuration shall be read from an integrity-checked configuration file at runtime. |
|||||
Tracing#
Support for Tracing
|
status: valid
security: NO
safety: ASIL_B
|
||||
The communication framework shall provide infrastructure to enable binding-agnostic, zero-copy, read-only tracing of communication. |
|||||
Security Impact#
Access Control List Placement
|
status: valid
security: YES
safety: QM
|
||||
The communication framework shall support an Access Control Lists in the deployment configuration. |
|||||
Access Control List per service instance
|
status: valid
security: YES
safety: QM
|
||||
The communication framework shall support an Access Control List per service instance. |
|||||
Access Control List for producer
|
status: valid
security: YES
safety: QM
|
||||
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. |
|||||
Access Control List for consumer
|
status: valid
security: YES
safety: QM
|
||||
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. |
|||||
Safety Impact#
Communication ASIL level
|
status: valid
security: YES
safety: ASIL_B
|
||||
The communication framework shall support safe communication up to ASIL-B. |
|||||