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

[Peter Feiler]

Myron,

Good observation about possibly using an extra layer of abstraction for the redundancy.

John,

Myron had a graphical way of specifying the error behavior state machine.

If your interest is to perform reliability analysis based on reliability block diagrams (RBD) aka Dependence Diagrams (DD), I can see us using the graphical representation of the system - as you had attached - and then either explicitly select the subsystems of interest or utilize a flow to identify the elements involved in the flow for inclusion in the RBD. We can then derive the compositional logic.

We are currently working on simplified user interfaces for safety modeling - this could be an interesting candidate.

Peter

From: sae-aadl-users-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu [mailto:sae-aadl-users-bounces+phf=sei.cmu.edu at lists.sei.cmu.edu] On Behalf Of Myron J Hecht
Sent: Tuesday, April 7, 2015 7: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<mailto:myron.hecht at aero.org>
310-336-3521



From:        "Glowa, John M" <John.M.Glowa at boeing.com<mailto:John.M.Glowa at boeing.com>>
To:        AADL Modeling <aadl-modeling at lists.sei.cmu.edu<mailto:aadl-modeling at lists.sei.cmu.edu>>, "sae-aadl-users at lists.sei.cmu.edu<mailto:sae-aadl-users at lists.sei.cmu.edu>" <sae-aadl-users at lists.sei.cmu.edu<mailto: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<mailto: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