[aadl-modeling]: doubts about error sink

[Peter Feiler]

Hi,

AADL EMV2 allows users to specify incomplete fault behavior. For example, users can specify fault behavior purely via error propagations and error flows.
Users can then expand the specification by adding component error behavior.
The “consistency checking” action performs coverage checks as to whether all error propagations are handled by a component error behavior specification. We have become aware that the “consistency checking” action sometimes incorrectly reports  a coverage issue (see issue reports for ErrorModelV2 on Github/osate).

Answer to question 1: you can leave the transition specification out in your example as this is the only component error behavior declaration.

Answer to question 2: The error state machine you include by “use behavior” includes an error event. This error event represents a failure of the component itself. If the component has no failure then you can either set the occurrence probability of the error event to 0 or you can define and use an error state machine that does not include a predefined error event – you can always add error events specific to a component in the component error behavior section. You can even leave out the “use behavior” if there is no component failure – unless you need to reflect that an incoming error propagation affects the failure mode (error state) of the component persistently, i.e., you want a transition. In most cases an incoming propagation is just passed on as outgoing propagation without memory in the component itself.

Peter

From: aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu [mailto:aadl-modeling-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Luciana Burgareli
Sent: Monday, April 10, 2017 8:50 AM
To: AADL Modeling <aadl-modeling at lists.sei.cmu.edu>
Subject: Re: [aadl-modeling]: doubts about error sink


Hello,

We sent an email to the list and received no response (details below).
Could someone please help us?

Luciana Burgareli <luciana.burgareli at gmail.com<mailto:luciana.burgareli at gmail.com>> por  lists.sei.cmu.edu<http://lists.sei.cmu.edu>
responder a:    AADL Modeling <aadl-modeling at lists.sei.cmu.edu<mailto:aadl-modeling at lists.sei.cmu.edu>>
para:    aadl-modeling at lists.sei.cmu.edu<mailto:aadl-modeling at lists.sei.cmu.edu>
data:    28 de março de 2017 10:30
assunto:           [aadl-modeling]: doubts about error sink
lista de e-mails:           aadl-modeling at lists.sei.cmu.edu<mailto:aadl-modeling at lists.sei.cmu.edu>

Best regards, Luciana

2017-03-28 10:30 GMT-03:00 Luciana Burgareli <luciana.burgareli at gmail.com<mailto:luciana.burgareli at gmail.com>>:

Hello,

We have doubts about error sink. Our very simple example has a system
sensor that is an error source and a system CD that handle the
error. After the sink of the error, we want that the system CD stay in
the Operational state.

After running the Analysis of Consistency Checks, it resulted four errors:

C2: transition t1 in component CD1 does not reference event Failure
C2: transition FailureTransition in component CD1 does not reference error sink MSIError
C10: transition t1 does not references error event Failure in component CD1
C10: transition FailureTransition does not references error sink MSIError in component CD1

We have the following doubts:
1) We want that the system CD stay in the Operational state. Is it
necessary to insert the transition t1?
2) How to address the event Failure and transition FailureTransition errors of the ErrorLibrary.aadl?

2) Is the event Failure of the ErrorLibrary.aadl used only to
represent intern failures of the component?

Best regards

-----------------------------
package Sis
public

system CD
features
Dados_in: in data port;
end CD;

system implementation CD.i
    annex emv2{**
    use types ErrorLibrary;
    use behavior ErrorLibrary::FailStop;
    error propagations
    Dados_in: in propagation {BadValue};
    flows
    MSIError: error sink Dados_in {BadValue};
    end propagations;
    component error behavior
   transitions
    t1 : Operational-[Dados_in {BadValue}]-> Operational;
    end component;
    **};
end CD.i;
system  sensor
features
dados_sensor: out data port;
annex emv2{**
use types ErrorLibrary;
use behavior ErrorLibrary::FailStop;
error propagations
dados_sensor: out propagation {BadValue};
flows
sensorFail: error source dados_sensor{BadValue};
end propagations;
component error behavior
propagations
FailStop-[]->dados_sensor{BadValue};
end component;
**};
end sensor;

system REC
end REC;

system implementation REC.i
       subcomponents
CD1: system CD.i;
MSI: system Sensor;
connections
C_MSI: port MSI.dados_sensor ->CD1.Dados_in;
end REC.i;

end Sis;


-------------- next part --------------
HTML attachment scrubbed and removed