search

saeaadl / emv2

AADL Error Model V2 annex language
0 stars 0 forks source link

Rework propagation path list #77

Open joeseibel opened 2 years ago

joeseibel commented 2 years ago

In section E.7.3, Semantics (2), the standard contains a list of all of the possible propagation paths. This list has a number of problems and should be reworked.

First of all, the items that talk about propagations to or from connections don't work. For example, the third item says, "a processor to every connection bound to that processor and vice versa." This doesn't work because there is no syntax to specify a propagation to or from a connection, which is being addressed in issue #71. Once that issue has been resolved, this list should be updated.

Most of the items in the list are related to bindings. This can be expressed more concisely and clearly by referring to the binding properties. Instead of having items like, "a processor to every thread bound to that processor and vice versa," the standard could say, "a source of a processor binding (via the Actual_Processor_Binding property) to the target of the binding and vice versa." This type of language could similarly be repeated for Actual_Memory_Binding, Actual_Connection_Binding, and Actual_Function_Binding. See #72.

There is an item which reads, "a component to each component it has an access connection to and vice versa, subject to read/write restrictions." This statement is mostly fine, but I'm not sure the discussion of read/write restrictions should be here. Suppose a device writes to a bus, is it not possible for an error to be propagated the other way, from the bus to the device?

The item which reads, "a component from any of its outgoing features through every connection to components having an incoming feature to which it connects," is fine and I would leave it as is.

For subprograms, see #75. Also, do we want to support propagations via subprogram call sequences?

The last two items talk about propagations between elements that are bound to a shared component. First of all, there is no syntax for this. There is no way to specify that a thread propagates certain errors to other threads that are bound to the same processor. Errors can be propagated from a thread to the processor it is bound to and from the processor to all the threads that are bound to it, but there is no syntax for direct thread to thread propagations. I would suggest that this is not worth supporting and that these last two items should be removed.

brlarson commented 1 year ago

All these suggestions seem reasonable. Can we see the re-worked list?