Error transition same state causes stack overflow

[simpsoneric]

Summary

When performing a Fault Tree Analysis with a component error behavior where the target state is the same name as the source state, a stack overflow occurs.

Expected and Current Behavior

A syntax error should be generated if the following is written

       error behavior AllGood
            transitions
                BadVal: Operational -[Failure]-> Operational;
       end behavior;

According to AS5506/1A E.8.2 paragraph (4), the correct label for the target state should have been the text same state instead of Operational.

Steps to Reproduce

1. Instantiate sys.i
2. Execute "fault tree analysis"

package simple_unhandled
public
    annex EMV2 {**
        error behavior AllGood
            events
                Failure: error event;
            states
                Operational: initial state;
                Failed: state;
            transitions
                BadVal: Operational -[Failure]-> same state;
        end behavior;
    **};
	system sys
		features
            dinA: in data port;
            dinB: in data port;
			dout: out data port;

        annex EMV2 {**
            use types ErrorLibrary;
            use behavior simple_unhandled::AllGood;
            
            error propagations
				dinA: in propagation  {ItemValueError};
				dinB: in propagation  {ItemValueError};
				dout: out propagation {ItemValueError};

                flows
--                    pA: error path dinA -> dout;
--                    pB: error path dinB -> dout;
                    esrc: error source dout {ItemValueError};
			end propagations;

            component error behavior
                propagations
                    Operational -[ dinA{ItemValueError} ]-> dout{ItemValueError};
            end component;
		**};
	end sys;
	
	system implementation sys.i
	end sys.i;

end simple_unhandled;

Related:

"Help" example for "Transient and Persistent Faults in the Sensor" also describes a state transition with the target label as the source. This also causes a stack overflow.

https://github.com/osate/osate2/blob/master/emv2/org.osate.aadl2.errormodel.help/markdown/images/GPS-TransientSensor.png

Environment

• OSATE Version: OSATE2 2.9.0.vfinal
• Operating System: 4.15.0-124-generic #127-Ubuntu SMP

[jjhugues]

It seems we might be missing a legality or naming rule in the standard to properly flag this error

Could be a naming rule like

“The source state reference and the target state reference cannot identity the same defining state identifier in the namespace of the error behavior state machine containing the reference.”

It would echo the following naming rule from E.8:

"The source state reference and target state reference must identify a defining state identifier in the namespace of the error behavior state machine containing the reference."

@lwrage do you want me to create an errata for this?

[lwrage]

@jjhugues The proposed naming rule is insufficient if you have typed states, e.g., a{e1} -[...]-> a{e2} should be valid. We could also leave everything as is and not explicitly require same state for steady state transitions. It is really necessary only for the situation where the source is all and you want to define a steady state transition (with the same condition) for each state.