Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typeset used as target error type not marked as error #2604

Closed
keh181 opened this issue Mar 3, 2021 · 1 comment · Fixed by #2627 or #2649
Closed

Typeset used as target error type not marked as error #2604

keh181 opened this issue Mar 3, 2021 · 1 comment · Fixed by #2627 or #2649
Assignees
Milestone

Comments

@keh181
Copy link
Contributor

keh181 commented Mar 3, 2021

Summary
Currently, no error marker is placed on a target of an error path when it is associated with a type set or multiple error types.

Expected behavior
OSATE to mark this as an error.

Actual behavior
No error marker is present.

Steps To Reproduce

  1. Copy and paste this model into OSATE
package pkg
public
	device Sensor
		features
			SensorReading: out data port;
			TestReading: out data port;
			PowerSource: requires bus access;
		
			annex EMV2 {**
					use types ErrorLibrary;
					error propagations
					SensorReading: out propagation {ItemOmission, ServiceOmission};
					PowerSource: in propagation {ItemOmission};
					TestReading: out propagation {CommonErrors};
					flows
						ErrorSource: error source SensorReading {ItemOmission} when {SequenceError};
						-- SensorReading should be marked with an error
						ErrorPath: error path PowerSource->SensorReading {ItemOmission, ServiceOmission};
						-- TestReading should be marked with an error
						ErrorP: error path PowerSource->TestReading {CommonErrors}; 
					end propagations;
					
			**};
	end Sensor;
end pkg;
package type_mappings
public
	annex emv2 {**
		type mappings ErrorTest
			use types ErrorLibrary;
			{ItemOmission} -> {CommonErrors}; -- should be marked as error
			{ItemCommission} -> {ItemOmission, ItemCommission}; -- should be marked as error
		end mappings;
	**};
end type_mappings;
package composite_state
public
	
	annex emv2 {**
		error behavior EB
		use types ErrorLibrary;
			events
				PoorValue: error event;
				NoValue: error event;
			states
				Operational: initial state;
				OperationalNonCritical: state {CommonErrors};
				FailedState: state {CommonErrors};
			transitions
				tran1: Operational -[NoValue]->FailedState{ItemOmission};
		end behavior;
		
	**};
	
	system s
		annex EMV2 {**
			use types ErrorLibrary;
			use behavior composite_state::EB;
		**};
	end s;
	
	system x
		
	end x;
		
	system implementation x.i
		subcomponents
			s1: system s;
			s2: system s;
			
		annex emv2 {**
			use types ErrorLibrary;
			use behavior composite_state::EB;
			
			composite error behavior
				states
					[s1.OperationalNonCritical]->Operational{CommonErrors}; -- should be error 
					[s2.OperationalNonCritical]->Operational{ServiceError, EarlyService}; --should be error
					[s1.OperationalNonCritical]->Operational{ServiceError}; -- fine 
			end composite;			
		**};
	end x.i;
end composite_state;
package propagation_test
public
	system s
		features
			InProp: in data port;
			NewAirSpeed: out data port;
			OutProp: out data port;
		annex emv2{**
			use types ErrorLibrary;
			use behavior propagation_test::Simple;
			error propagations
				InProp: in propagation {CommonErrors}; 
 				NewAirSpeed: out propagation {BadValue, ServiceOmission}; 
 				OutProp: out propagation {CommonErrors};
			end propagations;
			component error behavior
				propagations
					Failed-[]->OutProp{CommonErrors}; -- should be error
					Failed-[]->NewAirSpeed{BadValue, ServiceOmission}; -- should be error
					Failed-[InProp{CommonErrors}]->OutProp{ServiceError}; -- good?
			end component;  
		**};
	end s;
	
	annex EMV2 {**
		error behavior Simple
			events
				Failure : error event;
			states
				Operational : initial state;
				Failed : state;
			transitions
				FailureTransition : Operational -[ Failure ]-> Failed;
		end behavior;
	**};

end propagation_test;
package type_transformations
public
	annex EMV2 {**
		type transformations X
			use types ErrorLibrary;
			{NoError} -[{LateDelivery}]-> {CommonErrors}; --should be marked as error because it's a typeset 
			{NoError} -[{ServiceError}]-> {ServiceError, ItemTimingError}; -- should be marked with error 
		end transformations;
	**};
end type_transformations;
@keh181 keh181 self-assigned this Mar 3, 2021
@keh181 keh181 changed the title typeset allowed in source of error path Typeset allowed in target of error path Mar 3, 2021
@lwrage lwrage changed the title Typeset allowed in target of error path Typeset with target end of error path not marked as error Mar 4, 2021
@keh181 keh181 changed the title Typeset with target end of error path not marked as error Typeset used as target error type not marked as error Mar 5, 2021
@lwrage lwrage added this to the 2.9.2 milestone Apr 8, 2021
@lwrage lwrage reopened this May 3, 2021
@lwrage
Copy link
Contributor

lwrage commented May 3, 2021

There's now an exception when a condition in the composite error behavior contains and and. See, for example, the ARP4761 example model included with OSATE.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants