[aadl-modeling]: doubts about error sink

[Luciana Burgareli]

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>:

> 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> por  lists.sei.cmu.edu
>
> responder a:    AADL Modeling <aadl-modeling at lists.sei.cmu.edu>
>
> para:    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
>
>
>
> Best regards, Luciana
>
>
>
> 2017-03-28 10:30 GMT-03:00 Luciana Burgareli <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