Hi all, At the end we need evidence that measures identified in the safety analyses have been implemented and tested. Normaly the traceability is the domain of RM tools. However, to check if the identified mechanisms can be traced to TSC it is helpful to see the traced requirements at the measure collection. * Add a profile property at 'Safety Mechanism' * Enter the following OCL-Script: self.oclAsType(safetyModel::Measure).mediniGetTracedElements(safetygoals::SafetyRequirement) (thank you Jan for your support) * Apply and Close This works well. Another script can be used to show links to external documents (OCL: self.oclAsType(safetyModel::Measure).mediniGetTracedElements(projectmodel::PJExternalDocument).oclAsType(projectmodel::PJExternalDocument).uri) Unfortunately, both scripts do not work together without prior checking the type of trace. Kind regards Günter

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Measure Collection: show the traces to safety requirements

medini_1026949627

Hi all,

At the end we need evidence that measures identified in the safety analyses have been implemented and tested. Normaly the traceability is the domain of RM tools. However, to check if the identified mechanisms can be traced to TSC it is helpful to see the traced requirements at the measure collection.

Add a profile property at 'Safety Mechanism'
Enter the following OCL-Script:
self.oclAsType(safetyModel::Measure).mediniGetTracedElements(safetygoals::SafetyRequirement)
(thank you Jan for your support)
Apply and Close

This works well.

Another script can be used to show links to external documents (OCL: self.oclAsType(safetyModel::Measure).mediniGetTracedElements(projectmodel::PJExternalDocument).oclAsType(projectmodel::PJExternalDocument).uri)

Unfortunately, both scripts do not work together without prior checking the type of trace.

Kind regards

Günter

Find more posts tagged with

medini

medini legacy

Accepted answers

All comments

medini_1024169437

Hi Günter,

unfortunately mediniGetTracedElements only accepts a single class. So you have to pass a generic base class and then filter afterwards. Here an example with Requirement and Goal, you can adapt and change for Document:

self.oclAsType(safetyModel::Measure).mediniGetTracedElements(ecore::EObject)->select(e | e.oclIsKindOf(safetygoals::SafetyRequirement) or e.oclIsKindOf(safetygoals::SafetyGoal))

Note that for 21.2 there will be some improvements in this area which I will explain in a separate article, once the release is out.

Regards
Jan

medini_1024169437

I forgot to mention that ecore::EObject is the most common base class you can use. In JS it more difficult because EObject is not exposed. With 21.2 there will be Metamodel.Any instead to compensate.

Jan

medini_1033829014

Hi Günter,

thank you for this implementation hint, it is a valuable contribution towards better traceability (which is what safety assessors usually are looking for!).

I've been thinking about similar issues a couple of times, and one thing that keeps puzzling me is how to deal with the fact that safety mechanisms in the collection are rather (proto)types of mechanisms, as opposed to individual instances of that mechanism. Example: "Range Check" is a typical pattern to secure an analog input, and you can attribute a certain DC w.r.t. certain failure types to it (say, 90%). However, if your design is using 4 analog inputs, you will need to implement four separate instances of the range check, which means four disctinct requirements and four corresponding groups of design elements in the HW and SW architecture. With your derived profile property, you have already improved a lot by collecting all requirements that belong to a certain SM; but still it is guesswork which requirement belongs to which particular row in the FMEDA.

My ideal solution would be to have one day a type/instance concept for SMs natively in medini. What I could imagine as an immediate solution is to add a reference property to the FMEDA sheet where you reference the concrete requirements for each failure mode of each (e.g.) analog input (which describes the realization of an SM, like range check) - see screenshot below. From these requirements I'd create (just as you suggest) a trace link to the SM in the mechanisms collection. If you want more automation, this even gives you two additional options (either or):

a) You write yourself a script that auto-populates the SM column in the FMEDA sheet by looking up the SMs from your collection that are referenced by the traces from the requirements you put in the reference attribute, or

b) You still populate the FMEDA by hand, but make yourself an OCL validation rule that the SM for which you calculate your metrics is actually the same that is traced to the requirement you put into the reference attribute

This will give you an additional level of integrity checking, assuring that you really have implemented one instance of the SM for each of your channels that may be subject to a certain failure mode.

medini_1026949627

Hi Bernhard,

My recommendation is to add the additional SMs manually (e.g. rang checks for each analog input). I do not believe that the effort is to big. In the other case you need to convince your assessor that your scripts have been validated.

Kind regards

Günter

medini_1033829014

Hi Günter,

valid argument for convincing the assessor! But this basically applies to any kind of self-made profiling, validation rules or scripting from which you want to take credit as an evidence in the safety case. Including yours ;-)

So what you mean is to duplicate the SM in the collection, like this?

This is certainly a very clear way to ensure traceability: to handle each instance of an SM as one entry. I see just two small inconveniences:

1. As the ID column is used in our catalog as a reference to the ISO section, you get default entries ("SM1" etc.) when you duplicate a line and you have to overwrite it, which won't create any trouble (the user ID doesn't have to be unique, under the hood medini uses its own unique IDs)

2. If you make adjustments to parameters like DC, you will have to adjust for each copy of the SM separately (which can even turn into an advantage if the same type of SM has different DC for different channels in your design)

But otherwise a good solution. For the technical aspects about different types I leave the discussion to Jan, who is the right specialist (I'm rather the safety process guy...)

Best regards

Bernhard

medini_1026949627

Hi Bernhard,

you are right. In the past I didn' use the catalog, but we referenced it. So we added each SM manually. However, overwriting the ID is absolute acceptable.

According to traceability I think it is sufficient to see the traces to the requirements. The trace to external documents like safety manual is mentioned at least at the properties or could be added as additional "Reference" by an additional profiling variable.

medini_1061189784

Hi

Hoping to revive this thread with a question.

Is it possible in the derived value to add the ASIL of the TSR? I cannot figure it out in OCL.

Thanks

Reece

medini_1024169437

Reece, you refer to the original post of Günter with the derived "trace" column or Bernhards example?

In any case, I think it is not immediately supported as the cell that renders the traced elements doe snot show the ASIL.

On the other hand... one may use OCL tuples to create a tuple of requirement and requirement ASIL, with the hope that the table renders the tuple nicely.

I would have to try that ... or maybe someone else did already.... Marian? :-)

Happy Scripting

Jan

medini_1061189784

Hi Jan

The approach taken by Gunter is the one I'm interested in. Just to concatenate the ASIL of the requirement in the table cell, a tuple may work but still unsure how to do that for each requirement. I tried to use the concat method but it doesn't return as Boolean.

medini_1063548292

HI Reece,

Jan was right, I tried to "convince" the cell decorator of derived properties to provide a specific output.

DO you want to rally list the properties or also keep the navigation to Model browser feature from the given cell ?

If the last on is your case then the closes you could get is to use collect and create sequence {asil,req}

--exmaple (OCL propfile porp.) to collect the asil ,object of Requirement
 safegoals::SafetyRequirement.allInstances()->asSequence()->subSequence(1,3)
->sortedBy(rt|rt.asil)->collect(r:safegoals::SafetyRequirement|Sequence{'ASIL '+r.asil,r})

That would result in UI:

Now note on Tuple:

available only in OCL ( AQL does not support Tuple)
simple example Tuple{key1=value,key2=value,keyN=valueN}

one can use collect() to create set of Tuples out of given Collection (Set or Sequence)

--code in derived profile property (OCL) user_concat ( Requirment Class)
 Tuple{asil=self.asil,object:self}
---------------------------------------------------------
-- example to create tuple out of collected req in a Collection
--let sreqs:Seqeuence(safetygoals::SafetyRequirement)= safetygoals::SafetyRequirement.allInstances()->asSequence()
in
sreqs->collect(req:safetygoals::SafetyRequirement|Tuple{asil=req.asil,object:req})

-- example to create tuple out of collected req in a Collection, using tuple with specified types 
--let sreqs:Seqeuence(safetygoals::SafetyRequirement)= safetygoals::SafetyRequirement.allInstances()->asSequence()
in
sreqs->collect(req:safetygoals::SafetyRequirement|Tuple{asil:String=req.asil,object:safetygoals::SafetyRequirement=req})

The problem is with the cell renderer. The current implementation of decorator simply does not recognize the Tuple object and therefore will only show partial information.( most likely it is not parsing the Tuple content but only the tuple object as such, second and maybe more difficult task would be that the cell would need actually refer its content as a table ( column = tuple key).

However as you can se when one will access the content of the profile property it is possible to get the any content of a Tuple ( example with JS read-back property)

However I tired to even use a simple Tuple containing only the self but that one did render only empty

Tuple{object=req}

The only way how to access the tuple propertiesis using JS profile property:

--JS deirved porperty user_readback
--received is a TUple object us method getValue(String) to get value 
self.getProfilePropertyValue('user_cat_attributes').toArray().map(r=>r.getValue('obj'))

You an also query them in another profile property or even in he OCL interactive console ... :

However a strangely enough t trying to get value of a specific key a(OCL&OCL interactive console).

So in conclusion the Tuples are supported but due to current limitation it will not render the tuple properly

So to achieve the capabilities of being able to navigate to object and provide custom label provider is not possible in a profilePropety cell.

You can only create your own string sequence , concat all the information yo need ( asil, id, name) .

or you will need to setup 2 properties one to collect the requirements and second one to get the asil of those reqirements

Marian

medini_1061189784

Hi Marian,

Thanks for the detailed response.

Navigation to the elements in the model browser is not required. It's just to enable us to see which SMs have an ASIL D TSR traced to it. I believe this is still going to be a limitation on the cell renderer as it only displays 3 requirements (at least with the code you provided).

medini_1063548292

Hi Reece,

Sorry I did not know what exactly you are trying to achieve. The code I provided was just some generic one with collection my own example requirements....

So to get the indication (true/false) whether any of the traced requirements is ASIL D very easy

Note you can extend the condition to match other cases ASIL C(D), QM (D), ...

self.mediniGetTracedElements(safetygoals::SafetyRequirement)
--only D , exluding C(D), QM(D)
->exists(e|e.asil.matches('D.*'))

Note you can also use a graphical interpretation instead of plain true/ false (Article)

if self.mediniGetTracedElements(safegoals::SafetyRequirement)
->selectByKind(safegoals::SafetyRequirement)
--only D , exluding C(D), QM(D)
->exists(e|e.asil.matches('D.*')) then 
--icon image 
'[+]'
else 
--icon image 
'[!]'
endif

If you want the list the actual requirements with asil D as well ...

self.mediniGetTracedElements(safetygoals::SafetyRequirement)
--only D , exluding C(D), QM(D)
->select(e:safetygoals::SafetyRequirement|e.asil.matches('D.*'))

If you want to have the list of ASIL-REQ info also possible...

self.mediniGetTracedElements(safetygoals::SafetyRequirement)
->selectByKind(safetygoals::SafetyRequirement)
--match D exclude C(D), A(D) QM (D) ... 
->select(e|e.asil.matches('D.*?') )
->collect(e:safetygoals::SafetyRequirement| 'ASIL '+e.asil+'\t['+e.identifier+']'+e.name)

Overall it could look like this ... just pick the one you wan to use...

Marian

medini_1061189784

Thanks a bunch Marian. That is exactly what we needed!

medini_1024169437

Great indeed Marian,

we will have a look on our end why the Tuple is not supported as I hoped it.

Jan