A method of identifying and analyzing irrational system behavior in a system of systems

Abstract

System of interest (SoI) failures can sometimes be traced to an unexpected behavior occurring within another system that is a member of the system of systems (SoS) with the SoI. This article presents a method for use when designing an SoI that helps to analyze an SoS for unexpected behaviors from existing SoS members during the SoI's conceptual functional modeling phase of system architecture. The concept of irrationality initiators—unanticipated or unexpected failure flows emitted from one system that adversely impact an SoI, which appear to be impossible or irrational to engineers developing the new system—is introduced and implemented in a quantitative risk analysis method. The method is implemented in the failure flow identification and propagation framework to yield a probability distribution of failure paths through an SoI in the SoS. An example of a network of autonomous vehicles operating in a partially denied environment is presented to demonstrate the method. The method presented in this paper allows practitioners to more easily identify potential failure paths and prioritize fixing vulnerabilities in an SoI during functional modeling when significant changes can still be made with minimal impact to cost and schedule.

A Functional Failure Analysis Method of Identifying and Mitigating Spurious System Emissions From a System of Interest in a System of Systems

“…Most existing methods such as requirements management, PRA and FMECA, and other similar techniques from the systems engineering community either only implicitly suggest that SSEs be examined and mitigated at the conceptual stage of design before functional architecture has been solidified or explicitly examine spurious systems emissions after functional architectures have been finalized and component design has begun. While our previous work looks at SSEs [27], it does so from the perspective of defending against the spurious systems emissions rather than preventing the emissions from occurring in the first place.…”

“…The function failure identification and propagation (FFIP) family of methods extends the concept of RBDs to understand how failures propagate through a system, how to detect incipient failures, and what may be done to mitigate such failure events [25,26]. Some work has been done that includes the authors of this paper to understand how to redesign an SoI at the functional level to withstand SSEs that enter the SoI as unanticipated failure initiating events [27]. Our previous work is in contrast with the method advanced in this paper that specifically focuses on not allowing SSEs from a SoI to occur that may negatively affect the rest of a SoS.…”

A graph theory approach to predicting functional failure propagation during conceptual systems design

“…This is done by propagating failures through the system and results in the system's functional health. This work has been extended is a variety of ways 62–70 . Work by O'Halloran et al.…”

“…This work has been extended is a variety of ways. [62][63][64][65][66][67][68][69][70] Work by O'Halloran et al models failure propagation across uncoupled boundaries in early conceptual designs. 16 Related work by Jensen has been focused on functional failure propagation in FBDs and basic functional architectures.…”

Operationalizing digital twins through model‐based systems engineering methods

“…While these motivations are applicable to a wide range of operational systems, there is particular interest in applications for unmanned systems since there is not a “man in the loop” that can overcome technical challenges during operations. In these cases, PHM and notably PHM for autonomous decision making, something that has also been explored in recent years, 63 is of very high value.…”