Premium
3.3.1 System Phases, Modes, and States: Solutions to Controversial Issues
Author(s) -
Wasson Charles S.
Publication year - 2011
Publication title -
incose international symposium
Language(s) - English
Resource type - Journals
ISSN - 2334-5837
DOI - 10.1002/j.2334-5837.2011.tb01205.x
Subject(s) - state (computer science) , computer science , problem statement , mode (computer interface) , asset (computer security) , risk analysis (engineering) , systems engineering , management science , engineering , computer security , algorithm , business , operating system
System phases, modes, and states are often one of the most controversial concepts in System Engineering due to a lack of standards for implementation. Yet, the topic serves as one of the most critical guiding principles of System Engineering: Decompose system complexity into manageable levels and entities with acceptable risk that lead to optimal system design solutions . Four issues contribute to the challenges of implementing system phases, modes, and states: Issue #1 – Definitions of “mode(s)” and a “state(s)” Issue #2 ‐ Do “modes” contain “states” or do “states” contain “modes”? Issue #3 ‐ Should specifications specify “modes and states”? Issue #4 ‐ Should specifications flow down “modes and states”? To address these four issues, this paper provides a statement of the problem, identifies sources of the problem, provides clarifying definitions, and provides illustrative examples of “modes” and “states”. Building on the foundational definitions, the paper explores the entity relationships (ERs) between phases, modes, and states and how they can be employed as a problem solving‐solution development framework to identify and link system phases of operation, modes, use cases, various types of states to the system architecture. This paper proposes that due to the abstractness and understanding of the term “state”, communications among engineers becomes confusing and conflicting. Investigation and analysis of this reveals that “states” have at least four contexts of usage: 1) organizational or logistical employment of a system as an asset – i.e., System States, 2) the operating condition of a system– i.e. Operational States, 3) the time and operating environment‐dependent dynamics of a system – i.e., Dynamic States, and 4) the physical arrangement of architectural capabilities to achieve performance‐based outcomes – i.e., Physical Configuration States. Based on a solution to Issues #1 and #2 that fuel the controversy, the paper addresses the final two issues – i.e., Issues #3 and #4 ‐ concerning specifying and flowing down “modes and states” in specifications. We conclude with a summary of recommendations concerning the four issues and provide suggestions for effective SE leadership to lead, apply, and orchestrate the concept of system phases, modes, and states.