Feature Requirements#
Coverage: 100.0% (50 of 50 items OK)
[OK] TRLC Assumedsystemreq Communication.SystemErrorHandling
(C++) exceptions shall not be used for error handling. The best way to deal with errors is to try to resolve those component internally. If not possible the caller of the function shall be notified of the error. For (error) returns there is a specific library to be used in S-CORE, it is the Score::Result library which is part of the Base Libraries feature.
[OK] TRLC Assumedsystemreq Communication.InterProcessCommunication
The platform shall support inter-process communication.
[OK] TRLC Assumedsystemreq Communication.IntraProcessCommunication
The platform shall support intra-process communication.
[OK] TRLC Assumedsystemreq Communication.StableApplicationInterfaces
The platform shall provide a framework to mitigate incompatible changes on external interfaces to keep application interfaces stable.
[OK] TRLC Assumedsystemreq Communication.ExtensibleExternalCommunication
The platform shall support external communication via well established protocols e.g. Zenoh, DDS.
[OK] TRLC Assumedsystemreq Communication.SystemSafeCommunication
The platform shall support safe communication.
[OK] TRLC Assumedsystemreq Communication.SecureCommunication
The following security features shall be supported by the platform: Mandatory access control, Secure boot, Secure onboard communication, IPSec and MACSec, Firewall, Certificate installation and storage in HSM or ARM trustzone, Kernel hardening (ASLR, Pointer obfuscation …) in libc and compiler, Identity and Access Management, Secure Feature Activation, Secure software update.
[OK] TRLC Assumedsystemreq Communication.SupportForTimeBasedArchitectures
The platform shall support a deterministic, time-based application execution model that triggers logic based on predefined schedules or polling intervals.
[OK] TRLC Assumedsystemreq Communication.SystemSupportForDataDrivenArchitecture
The platform shall support an event-driven, high-throughput application architecture where execution is triggered by data changes.
[OK] TRLC Assumedsystemreq Communication.SystemSupportForRequestDrivenArchitecture
The platform shall support a request-driven, asynchronous application architecture that processes requests on-demand.
[OK] TRLC Assumedsystemreq Communication.ProgrammingLanguagesForApplicationDevelopment
The platform shall support implementation of applications in the following programming languages up to the highest ASIL level as defined in automotive_safety: C, C++, Rust.
[OK] TRLC Assumedsystemreq Communication.TracingOfCommunication
The platform shall support the tracing of communication events for internal and external communication systems.
[OK] TRLC Featreq Communication.SupportForTimeBasedArchitecture
The communication framework shall provide API to support a time-based architecture.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:17:18
[OK] TRLC Featreq Communication.SupportForDataDrivenArchitecture
The communication framework shall provide API to support a data-driven architecture.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:24:18
[OK] TRLC Featreq Communication.SupportForRequestDrivenArchitecture
The communication framework shall provide API to support a request-driven architecture.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:31:18
[OK] TRLC Featreq Communication.CommunicationInterfaces
A communication interface consists of a combination of any number of the following elements: Event-Types, Methods, Signals.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:38:18
[OK] TRLC Featreq Communication.EventType
An event-type is part of a communication interface and has a name and a data type. The producer can assign a value to it. Consumers can subscribe to value-changed events of the element or poll unseen, cached events.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:45:18
[OK] TRLC Featreq Communication.Method
A method is part of a communication interface and 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, it shall invoke the application routine with the provided parameters, and return its result to the communication partner. A method call shall be possible both synchronously and asynchronously.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:52:18
[OK] TRLC Featreq Communication.Field
A field is a component of a communication interface and is defined by a name and a data type, along with dedicated getter and setter methods. The producer has the ability to assign a value to the field. Consumers can either subscribe to receive notifications when the field’s value changes or poll the cached values of fields that have not yet been seen. Additionally, consumers can retrieve the current value of the field using the getter method or update the field’s value through the setter method.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:59:18
[OK] TRLC Featreq Communication.Signal
A signal is part of a communication interface and has a name. A client can trigger the signal. The service instance offering the trigger can wait for the signal to be triggered or check if the signal was triggered. Signals can not transport data.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:66:18
[OK] TRLC Featreq Communication.ProducerConsumerPattern
Communication shall be cached based on the producer-consumer pattern.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:73:18
[OK] TRLC Featreq Communication.ServiceInstance
Multiple service instances shall be able to offer the same interface.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:80:18
[OK] TRLC Featreq Communication.ServiceInstanceNames
A service instance is offered under one or more unique names by which it can be discovered. Names follow a POSIX path style.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:87:18
[OK] TRLC Featreq Communication.Versioning
The communication framework shall support versioning of service instances. Version information of a service instance is binding-specific.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:94:18
[OK] TRLC Featreq Communication.ServiceLocationTransparency
The interface to access service instances is agnostic to the binding used to communicate with the service.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:101:18
[OK] TRLC Featreq Communication.StatelessCommunication
The communication framework shall support stateless communication.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:108:18
[OK] TRLC Featreq Communication.ServiceInstanceGranularity
The communication framework shall support multiple service instances per software architecture element.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:115:18
[OK] TRLC Featreq Communication.ServiceDiscovery
The communication framework shall provide service discovery to find available services during runtime. Service discovery shall consider version compatibility.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:122:18
[OK] TRLC Featreq Communication.SafeCommunication
The communication framework shall support safe communication involving communication partners on the same or multiple criticality levels.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:129:18
[OK] TRLC Featreq Communication.DataCorruption
Consumers with lower criticality shall not be able to corrupt data consumed by partners with higher criticality.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:136:18
[OK] TRLC Featreq Communication.DataReordering
Consumers with lower criticality shall not be able to modify the order of data consumed by partners with higher criticality.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:143:18
[OK] TRLC Featreq Communication.DataRepetition
Consumers with lower criticality shall not be able to duplicate data consumed by other communication partners with higher criticality.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:150:18
[OK] TRLC Featreq Communication.DataLoss
Consumers with lower criticality shall not be able to drop data before it is consumed by partners with higher criticality.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:157:18
[OK] TRLC Featreq Communication.ZeroCopy
The communication framework shall enable Zero-Copy communication without copying to-be-transferred data.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:164:18
[OK] TRLC Featreq Communication.SupportForMultipleProgrammingLanguages
The communication framework shall provide a public API for each supported programming language of S-CORE.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:171:18
[OK] TRLC Featreq Communication.SupportForProgrammingLanguageIdioms
Each public API shall support the idioms of the programming language it is written in.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:178:18
[OK] TRLC Featreq Communication.UseProgrammingLanguageInfrastructure
Each public API shall use core infrastructure of its programming language and accompanying standard libraries, whenever possible and meaningful.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:185:18
[OK] TRLC Featreq Communication.FullyMockablePublicAPI
The public API shall be fully mockable.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:192:18
[OK] TRLC Featreq Communication.FakeBinding
The communication framework shall provide a fake binding.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:199:18
[OK] TRLC Featreq Communication.MultiBindingSupport
The communication framework shall support multiple bindings.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:206:18
[OK] TRLC Featreq Communication.BindingAgnosticPublicAPI
The public API of the communication framework shall be binding-agnostic.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:213:18
[OK] TRLC Featreq Communication.MultiBindingDeploymentConfiguration
The association of a service instance and the appropriate binding shall be specified in the deployment configuration.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:220:18
[OK] TRLC Featreq Communication.DeploymentConfigurationAtRuntime
Deployment configuration shall be read from an integrity-checked configuration file at runtime.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:227:18
[OK] TRLC Featreq Communication.SupportForTracing
The communication framework shall provide infrastructure to enable binding-agnostic, zero-copy, read-only tracing of communication.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:234:18
[OK] TRLC Featreq Communication.AccessControlListPlacement
The communication framework shall support an Access Control Lists in the deployment configuration.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:241:18
[OK] TRLC Featreq Communication.AccessControlListPerServiceInstance
The communication framework shall support an Access Control List per service instance.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:248:18
[OK] TRLC Featreq Communication.AccessControlListForProducer
The communication framework shall support an Access Control List for the communication partner offering a service instance (producer).
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:255:18
[OK] TRLC Featreq Communication.AccessControlListForConsumer
The communication framework shall support an Access Control List for the communication partner consuming a service instance.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:262:18
[OK] TRLC Featreq Communication.CommunicationASILLevel
The communication framework shall support safe communication up to ASIL-B.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:269:18
[OK] TRLC Featreq Communication.ErrorHandling
(C++) exceptions shall not be used for error handling. The best way to deal with errors is to try to resolve those component internally. If not possible the caller of the function shall be notified of the error. For (error) returns there is a specific library to be used in S-CORE, it is the Score::Result library which is part of the Base Libraries feature.
Source: score/mw/com/dependability/requirements/feature_requirements/feature_requirements_ipc.trlc:276:18