Reach-Down subcomponent hierarchy does not set property EMV2::OccurrenceDistribution

[brlarson]

Summary

I wanted to set all EMV2::OccurrenceDistribution properties in extensions of my top-level system implementation, so I could easily compare analyses of designs with different reliability devices.

However, reaching down to set EMV2::OccurrenceDistribution properties, does not assign values when used for FTA.

Expected and Current Behavior

	EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureToDetectRate
	  applies to ^func.safety_subsystem.error_detect@post_not_detect_failure;

does not assign the probability to error event post_not_detect_failure.

while
EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureToDetectRate
applies to post_not_detect_failure;
does.

Steps to Reproduce

Try to set EMV2::OccurrenceDistribution property in an EMV2 annex subclause of a top-level system implementation by reaching down through subcomponent to desired error event. (Comment-out properties in iPCA_Error_Detector.i below.)

--extend the main system implementation with assignments for probabilities
system implementation PCA_Pump_System.i2 extends iPCA_Medical_Device::PCA_Pump_System.i
	annex EMV2 {**
	properties
	--patient button failure
		EMV2::OccurrenceDistribution => iPCA_Properties::PatientButtonFailureRate 
		  applies to ^func.sensors_actuators.button@fail;
	--power-on self-test detected failure
		EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureRate 
		  applies to ^func.safety_subsystem.error_detect@post_detected_failure;
	--power-on self-test did not detect failure when it should have
		EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureToDetectRate
		  applies to ^func.safety_subsystem.error_detect@post_not_detect_failure;
	**};
end PCA_Pump_System.i2;

device implementation iPCA_Error_Detector.i
  annex EMV2
  {** 
  use types ErrorLibrary, iPCA_Error_Model;
  use behavior iPCA_Error_Model::ErrorDetector; 	
  error propagations
    --no sound, wrong/false alarm, wrong sound
    hw_error_detections.post_fail: out propagation {UndetectedFault}; 
  end propagations;
  component error behavior
    events
      post_detected_failure : error event;
      post_not_detect_failure : error event;
	  transitions
	    working -[post_detected_failure]-> failed_detected;   
	    working -[post_not_detect_failure]-> failed_undetected;   
  end component;
  properties
	--power-on self-test detected failure
		EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureRate 
		  applies to post_detected_failure;
	--power-on self-test did not detect failure when it should have
		EMV2::OccurrenceDistribution => iPCA_Properties::POSTfailureToDetectRate 
		  applies to post_not_detect_failure;
  **};  --end of EMV2	
end iPCA_Error_Detector.i;

Environment

• OSATE Version: 2.6.1
• Operating System: macOS 10.14.6

[reteprelief]

Hi Brian,

your model fragment does not give me a chance to test out your assertion that values do not get assigned for FTA.
The example is similar to one of our test cases (link below).
Instantiate TMR_Archetype.impl2 and run FTA and you will see that it picks up the assigned probabilities.
Peter

https://github.com/osate/osate2/blob/master/emv2/org.osate.aadl2.errormodel.faulttree.tests/models/FTATests/Issue1837.aadl

[brlarson]

Peter, I ran the example in Issue1837, and it works fine. My model reaches far down the subcomponent hierarchy to set OccurrenceDistribution properties, and there are ample opportunities to mess-up composite state machines on the way up. For now, I am setting all OccurrenceDistribution properties locally, which later can (should) be overridden by properties set in a top-level system implementation.

…

--Brian On Dec 18, 2019, at 12:46 PM, Peter Feiler <notifications@github.com<mailto:notifications@github.com>> wrote: Hi Brian, your model fragment does not give me a chance to test out your assertion that values do not get assigned for FTA. The example is similar to one of our test cases (link below). Instantiate TMR_Archetype.impl2 and run FTA and you will see that it picks up the assigned probabilities. Peter https://github.com/osate/osate2/blob/master/emv2/org.osate.aadl2.errormodel.faulttree.tests/models/FTATests/Issue1837.aadl — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2112?email_source=notifications&email_token=AAJC32X6VUSUZU7IMRBJZR3QZJVYXA5CNFSM4J3AXAPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHHC4YA#issuecomment-567160416>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJC32WTNKO2QODMX4KISSLQZJVYXANCNFSM4J3AXAPA>.

[reteprelief]

Brian, I found the issue. Working on a fix. Peter From: Brian R Larson <notifications@github.com> Sent: Thursday, December 19, 2019 11:53 AM To: osate/osate2 <osate2@noreply.github.com> Cc: Peter Feiler <phf@sei.cmu.edu>; Assign <assign@noreply.github.com> Subject: Re: [osate/osate2] Reach-Down subcomponent hierarchy does not set property EMV2::OccurrenceDistribution (#2112) Peter, I ran the example in Issue1837, and it works fine. My model reaches far down the subcomponent hierarchy to set OccurrenceDistribution properties, and there are ample opportunities to mess-up composite state machines on the way up. For now, I am setting all OccurrenceDistribution properties locally, which later can (should) be overridden by properties set in a top-level system implementation.

…

--Brian On Dec 18, 2019, at 12:46 PM, Peter Feiler <notifications@github.com<mailto:notifications@github.com<mailto:notifications@github.com%3cmailto:notifications@github.com>>> wrote: Hi Brian, your model fragment does not give me a chance to test out your assertion that values do not get assigned for FTA. The example is similar to one of our test cases (link below). Instantiate TMR_Archetype.impl2 and run FTA and you will see that it picks up the assigned probabilities. Peter https://github.com/osate/osate2/blob/master/emv2/org.osate.aadl2.errormodel.faulttree.tests/models/FTATests/Issue1837.aadl — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#2112?email_source=notifications&email_token=AAJC32X6VUSUZU7IMRBJZR3QZJVYXA5CNFSM4J3AXAPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHHC4YA#issuecomment-567160416>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAJC32WTNKO2QODMX4KISSLQZJVYXANCNFSM4J3AXAPA>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<#2112?email_source=notifications&email_token=AAFXHOEUWFPRJJMO4Q6PMLLQZORGZA5CNFSM4J3AXAPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHKHJAY#issuecomment-567571587>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAFXHOGUP5TFWTHJHVMUROLQZORGZANCNFSM4J3AXAPA>.