[aadl-modeling]: doubts about error sink

[Peter Feiler]

Q1: Being an error sink does not imply that the component goes into a failstop state.
It just implies that any incoming propagation does not result in any further propagation.
You separately specify in a component error behavior section whether the incoming propagation affects the error state, e.g., transitions from operational to degraded or failstop.

What is the effect of an incoming bad value on CD in terms of a failure mode (error state)? What does CD do? Is CD recording information on storage – (a bad value is persistently stored until overwritten)? Is it performing a computation and produce a result (CD does not have any output)? Does CD display the value – an external observer can see the bad value (you can model this by an abstract feature representing the observation that an observer can make)?

Q2: Consistency rule C12 is currently too strict. I made a modification which will be available in the testing release by tomorrow.

From: Luciana Burgareli [mailto:luciana.burgareli at gmail.com]
Sent: Wednesday, April 12, 2017 11:07 AM
To: AADL Modeling <aadl-modeling at lists.sei.cmu.edu>; Peter Feiler <phf at sei.cmu.edu>; Rovedy Silva <rovedy at gmail.com>; Nanci Naomi <nnarai at gmail.com>
Subject: Re: [aadl-modeling]: doubts about error sink



Hi,

Thanks for your reply.

Question 1: According to our example sent in the previous email, we want to know if using an error sink in the CD component, does the CD component change to the error state (failed) just because it uses sink? Or is it necessary to use a component error behavior  adding a transition to the error state?


We modified  the previous example as attached below.
We left out the "use behavior" of CD component considering that there is no internal fault and no failure caused by incoming propagation from the MSI component.
The consitency checking shows the following errors:

C12: component CD1 is not referenced for state FailStop in component REC_i_Instance
C12: component CD1 is not referenced for state Operational in component REC_i_Instance

Question 2: The CD component is not in  the "composite error behavior" of the component REC  because the component CD has no "use behavior". However the consistency checking generated these two errors. Is our example incomplete?

Best regards,

Luciana, Nanci and Rovedy


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

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

system implementation CD.i
    annex emv2{**
    use types ErrorLibrary;

    error propagations
            Dados_in: in propagation {BadValue};
    flows
            MSIError: error sink Dados_in {BadValue};
    end propagations;

    **};
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;
            annex emv2{**
    use types ErrorLibrary;
    use behavior ErrorLibrary::FailStop;
    composite error behavior
    states
         [(MSI.Operational)]->Operational;
         [(MSI.FailStop)]->FailStop;
    end composite;
    **};

end REC.i;

end Sis;


2017-04-11 10:51 GMT-03:00 Peter Feiler <phf at sei.cmu.edu<mailto:phf at sei.cmu.edu>>:
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:sei.cmu.edu at lists.sei.cmu.edu> [mailto:aadl-modeling-bounces+phf<mailto:aadl-modeling-bounces%2Bphf>=sei.cmu.edu at lists.sei.cmu.edu<mailto: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<mailto: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