mw::com: add AoU DoNotTrustGetSubscriptionStateReturnValue#640
mw::com: add AoU DoNotTrustGetSubscriptionStateReturnValue#640KrishaDeshkool wants to merge 1 commit into
Conversation
KrishaDeshkool
force-pushed
the
add_aou_for_get_sub_state
branch
2 times, most recently
from
c503f61 to
8026eda
Compare
KrishaDeshkool
requested review from
LittleHuba,
bemerybmw,
castler,
crimson11,
hoe-jo and
limdor
as code owners
KrishaDeshkool
force-pushed
the
add_aou_for_get_sub_state
branch
from
9814c18 to
4af5c18
Compare
|
|
||
| /* broken_link_c/issue/79416086 */ | ||
| ScoreReq.AoU NoGuaranteeOnSubscriptionStateCorrectness { | ||
| description = "It shall be ensured that a wrong or outdated subscription state returned by GetSubscriptionState() will not harm a safety goal." |
There was a problem hiding this comment.
It shall be ensured that an application must not rely on a SubscriptionState of kSubscribed or kSubscriptionPending returned by GetSubscriptionState() or reported by the SubscriptionStateChangeHandler.
There was a problem hiding this comment.
For safety critical use cases, an application must treat a SubscriptionState of kSubscribed or kSubscriptionPending (returned by GetSubscriptionState() or reported by the SubscriptionStateChangeHandler) as the same.
Note. On a technical level, we cannot reliably differentiate between these 2 states.
There was a problem hiding this comment.
We can link the requirement "SubscriptionState" https://codebeamer.bmwgroup.net/cb/issue/14034769 (actually link to trlc or the requirement name). The requirement needs to be updated on master (i.e. in trlc) to contain the information about the "active subscription" (https://codebeamer.bmwgroup.net/cb/issue/20003388) i.e. when we can be in kSubscribed / kSubscriptionPending.
| ScoreReq.AoU NoGuaranteeOnSubscriptionStateCorrectness { | ||
| description = "It shall be ensured that a wrong or outdated subscription state returned by GetSubscriptionState() will not harm a safety goal." | ||
| safety = ScoreReq.Asil.B | ||
| note = "The subscription state is updated based on notifications, for which no guarantees are given - see also [NoGuaranteeInAvailabilityOfServices]. The returned state can therefore lag behind or deviate from the actual producer side state." |
There was a problem hiding this comment.
The application can rely on the SubscriptionState being kNotSubscribed until a successful subscription is made which transitions the SubscriptionState into kSubscriptionPending or kSubscribed. The SubscriptionState will then reliably transition back to kNotSubscribed once a successful unsubscription is made. All APIs which are documented to return a certain result in case the current SubscriptionState is kNotSubscribed are reliable.
There was a problem hiding this comment.
i don't think we can put guarantees in AoUs. it's the other way around the Aou is where we state what we do not guarantee something and what the user must take care and any guarantee should be a requirement with evidence behind it (test or manual analysis) IMO
2 participants
No description provided.