[aadl]: [aadl-modeling]: Composite Error Behavior - Automation or Enhancements? (UNCLASSIFIED)

Lewis, Bruce CIV (US) bruce.a.lewis.CIV at mail.mil
Wed Apr 8 12:24:25 EDT 2015


Classification: UNCLASSIFIED
Caveats: NONE

We are considering what additions should now be made to the current graphical toolset.  I'll pass this on to Philip.  

Bruce

-----Original Message-----
From: sae-aadl-users-bounces+bruce.a.lewis=us.army.mil at lists.sei.cmu.edu [mailto:sae-aadl-users-bounces+bruce.a.lewis=us.army.mil at lists.sei.cmu.edu] On Behalf Of Myron J Hecht
Sent: Tuesday, April 07, 2015 6:05 PM
To: Glowa, John M
Cc: sae-aadl-users-bounces+myron.j.hecht=aero.org at lists.sei.cmu.edu; AADL Modeling; sae-aadl-users at lists.sei.cmu.edu
Subject: Re: [aadl]: [aadl-modeling]: Composite Error Behavior - Automation or Enhancements?

Hello John 

Have you thought about organizing the model hierarchically, so that you have a power subsystem, a rotor subsystem, a motor subsystem, etc.?  That way, at the top level, the vehicle needs all of the subsystems functional (no composite behavior required), but within each of the subsystems, you could use the composite error behavior to model the redundancy.  By the way, your example shows that if the only model objective is RBD capabilities, AADL may not be the most efficient way to handle it.   

With respect to your question about a graphical depiction of the error model, we had created a state transition diagram, ports, and connection implementation for the previous version of the error annex with an older version of OSATE.  I'd be happy to share what we did if you have a way of taking it further. 

Regards 


Myron Hecht
Sr. Project Leader
The Aerospace Corporation
myron.hecht at aero.org
310-336-3521 



From:        "Glowa, John M" <John.M.Glowa at boeing.com> 
To:        AADL Modeling <aadl-modeling at lists.sei.cmu.edu>, "sae-aadl-users at lists.sei.cmu.edu" <sae-aadl-users at lists.sei.cmu.edu>, 
Date:        04/07/2015 11:52 AM 
Subject:        [aadl]: [aadl-modeling]: Composite Error Behavior - Automation or Enhancements? 
Sent by:        sae-aadl-users-bounces+myron.j.hecht=aero.org at lists.sei.cmu.edu 

________________________________




I'd like to pose this question to the OSATE team and user community as a whole, and ask whether anyone is investigating or aware of methods for simplifying the generation of composite error behavior for complex systems. 
  
Even within our relatively simple model of a rotorcraft propulsion system, the composite error behavior becomes rather cumbersome. 
  
composite error behavior
states
[(mainmotor1.Operational or mainmotor2.Operational) and (tailmotor1.Operational or tailmotor2.Operational) and (gen1.Operational or gen2.Operational) and maincontroller.Operational and tailcontroller.Operational and maingearbox.Operational and tailgearbox.Operational and clutch.Operational and pdu.Operational and estorage.Operational and voltageconv.Operational and mainrotor.Operational and tailrotor.Operational]-> Operational; [mainmotor1.FailStop and mainmotor2.FailStop]-> FailStop; [tailmotor1.FailStop and tailmotor2.FailStop]-> Failstop; [gen1.FailStop and gen2.FailStop]-> FailStop; end composite; 
  
As we move to more fault-tolerant architectures, I expect the complexity to increase. Likely some simplification could be added to the statement using the ormore logical operator as shown in Listing 6 from "Architectural Fault Modeling with the AADL Error-Model Annex". 
  
Has anyone considered adding graphical definition to this behavior in the same way flows can be edited or instantiated from the graphical editor? 
  
John M. Glowa
Project Management Specialist
Joint Multi-Role, Boeing Philadelphia 
  
 [attachment "VTOL_RBD.png" deleted by Myron J Hecht/West/Aerospace/US] 


Classification: UNCLASSIFIED
Caveats: NONE




More information about the Sae-aadl-users mailing list