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

[Glowa, John M]

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


-------------- next part --------------
HTML attachment scrubbed and removed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: VTOL_RBD.png
Type: image/png
Size: 121307 bytes
Desc: VTOL_RBD.png
URL: <http://lists.sei.cmu.edu/pipermail/sae-aadl-users/attachments/20150407/be16c3a9/attachment-0001.png>