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

[Myron J Hecht]

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] 
-------------- next part --------------
HTML attachment scrubbed and removed