Requirements#
High cohesion and loose coupling#
Support for Time-based Architecture
|
status: valid
security: NO
safety: QM
|
||||
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: QM
|
||||
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: QM
|
||||
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
|
||||
A communication interface that is offered to consumers is called a service instance. Multiple service instances shall be able to offer the same interface. |
|||||
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. Version information of a service instance is binding-specific. Version information is provided in the deployment configuration. 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: - 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. |
|||||
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 IPC
|
status: valid
security: NO
safety: QM
|
||||
IPC communication shall be possible without copying to-be-transferred data. |
|||||
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 SCORE. |
|||||
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: QM
|
||||
The association of a service instance and the appropriate binding shall be specified in the deployment configuration. |
|||||
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: ASIL_B
|
||||
The communication framework shall support an Access Control Lists in the deployment configuration. |
|||||
Access Control List per service instance
|
status: valid
security: YES
safety: ASIL_B
|
||||
The communication framework shall support an Access Control List per service instance. |
|||||
Access Control List for producer
|
status: valid
security: YES
safety: ASIL_B
|
||||
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: ASIL_B
|
||||
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. |
|||||
IPC Confidentiality
|
status: valid
security: YES
safety: ASIL_B
|
||||
The IPC binding shall ensure confidentiality of its communication. |
|||||
IPC Integrity
|
status: valid
security: YES
safety: ASIL_B
|
||||
The IPC binding shall ensure integrity of its communication. |
|||||
IPC Availability
|
status: valid
security: YES
safety: ASIL_B
|
||||
The IPC binding shall ensure availability of its communication, so that the availability is independent per criticality level. |
|||||
Safety Impact#
IPC ASIL level
|
status: valid
security: YES
safety: ASIL_B
|
||||
The communication framework shall support safe communication up to ASIL-B. |
|||||