message_passing: create feature requirements#516
Conversation
gdadunashvili
requested review from
LittleHuba,
bemerybmw,
castler,
crimson11,
hoe-jo and
limdor
as code owners
gdadunashvili
force-pushed
the
dadu_message_passing_only_feature_requirements
branch
2 times, most recently
from
0f5d355 to
91f5384
Compare
| } | ||
|
|
||
| ScoreReq.FeatReq FriendlyToSingletonFreeBoundedMonotonicMemoryAllocationAndResourceMockInjection { | ||
| description = "bazel-bin/score/message_passing/dependability/dependable_element_message_passing_index_report.html" |
gdadunashvili
force-pushed
the
dadu_message_passing_only_feature_requirements
branch
4 times, most recently
from
8663e71 to
90bc313
Compare
| } | ||
|
|
||
| ScoreReq.FeatReq FriendlyToSingletonFreeImplementations { | ||
| description = "The Message Passing library design (and the design of the interfaces in particular) shall be friendly to singleton-free implementations." |
There was a problem hiding this comment.
Not clear what friendly means. We need to state a testable expectation here
There was a problem hiding this comment.
Can this be replaced with shall allow singleton-free implementation?
There was a problem hiding this comment.
agree with you! Why not write:
The implementation shall not use any singletons
rationale: Resource management and lifecycle aspects for singleton implementations are hard to track.
| ScoreReq.AssumedSystemReq SystemMessagingProtocol { | ||
| description = "The system shall provide a mechanism for inter-process communication via a client-server messaging protocol." | ||
| safety = ScoreReq.Asil.B | ||
| rationale = "Application processes need to exchange requests and responses reliably across process boundaries." |
There was a problem hiding this comment.
reliably - is this a well-known formal definition?
Why I am asking:
With tagging this req. as safety = Asil.B - do we expect, that the following ISO 26262 communication fault modes shall be handled/avoided, when we say reliably? These are the 26262 fault modes for communication:
- Repetition: Sending the same message multiple times.
- Loss: Dropping or failing to receive a message.
- Delay: Receiving a message outside its expected time window.
- Insertion: Unwarranted addition or injection of a message.
- Incorrect Addressing: Delivering a message to the wrong destination.Incorrect Sequence: Messages arriving out of chronological order.
- Corruption: Bit-level errors or payload degradation within the message.
- Masquerading: An unauthorized sender appearing as a valid transmitter.
I do have some doubts with Loss and Delay ... I guess this we can hardly avoid ... at least our current implementation can't avoid ....
| } | ||
|
|
||
| ScoreReq.FeatReq UnidirectionalAndTwoWayCommunicationModes { | ||
| description = "The communication shall support unidirectional and two-way communication." |
There was a problem hiding this comment.
since you already introduced the notion connection above ... I would rephrase it to:
The communication shall support unidirectional and bidirectional communication on a given connection.
| } | ||
|
|
||
| ScoreReq.FeatReq FriendlyToSingletonFreeImplementations { | ||
| description = "The Message Passing library design (and the design of the interfaces in particular) shall be friendly to singleton-free implementations." |
There was a problem hiding this comment.
agree with you! Why not write:
The implementation shall not use any singletons
rationale: Resource management and lifecycle aspects for singleton implementations are hard to track.
| } | ||
|
|
||
| ScoreReq.FeatReq AllowsResourceMockInjection { | ||
| description = "The Message Passing library design shall allwo bounded monotonic memory allocation." |
There was a problem hiding this comment.
allwo -> allow
Why we are only talking about, what the design should allow? Why not require, that the implementation shall apply "bounded monotonic memory allocation"?
| } | ||
|
|
||
| ScoreReq.FeatReq SynchronousCommunicationMode { | ||
| description = "The communication shall support synchronous communication." |
There was a problem hiding this comment.
Do we need to be more concise regarding synchronous and asynchronous communication? TBH: Imho there are different things to distinguish:
- what does synchronous/asynchronous mean in case of
unidirectionalcommunication? - what does synchronous/asynchronous mean in case of
bidirectionalcommunication in the specific case of a request/response (in message passing we call itSendWaitReply)?
I.e. if we would require an asynchronous communication for bidirectional send/reply functionality ... we don't have it currently! So - with this requirement, someone would need to implement in message-passing 2.0. Are we aware?
Even for unidirectional communication, I guess it isn't clear, what asynchronous means? Imho, there are at least 3 different cases:
- The async call to send a unidirectional message, directly returns, after the message_passing layer accepted the message. (the message did not even reach the other/remote receiver process and there is also no guarantee, that it ever does)
- The async call to send a unidirectional message returns, after the message_passing layer was able to transfer the message to the other side. The message did not yet receive the handler for it (it is just queued somewhere) and there is also no guarantee, that it ever does get handled.
- The async call to send a unidirectional message returns, after the message_passing layer was able to transfer the message to the other side and also a suitable handler to process it has been found ... it has not been processed and it might be never processed.
So - again, what is exactly our definition of async vs. sync in this case?
gdadunashvili
force-pushed
the
dadu_message_passing_only_feature_requirements
branch
from
90bc313 to
2d2fa8e
Compare
3 participants
No description provided.