Why do we need to define States and Modes? States and modes need to be defined in a system specification/design document to allow:
•Functional and performance requirements that do not need to be achieved
under all conditions of system operation need to be specified relative to the
defined states and modes. (e.g. the detection performance of a sensor may be
specified for each search mode; Built In Test functions may be specified as
being required during an "operational" state or just in a "maintenance" state).
•Requirements to be specified for subsystems that will define their behaviour
relative to systems with which they are integrated. This includes the
specifications of conditions under which systems may transition between the
operating modes or states. The definition of status data exchanged between
subsystems and which components are responsible for overall state
determination (eg. A tracking system may need to pass both its own status and
the status of integrated sensor systems on to a display system which
determines and displays overall system status).
•As a means of defining required redundancy/allowed degradation/availability
that does not presuppose system design characteristics (eg. "The operational
state shall be maintained when at least n of m sensor subsystems are on-line.")
•Critical failures can be defined relative to which states and modes can be
attained. (eg. We can define a MTBCF as being with respect to a failure which
does not allow the "operational" state to occur; or does not allow the
performance requirements of a "self defence mode" to be achieved.
•Special cases of system behaviour may be best defined using state and mode
concepts. (eg. A "safe" state may require all mechanical movements of system
equipment (eg antenna rotation) to be halted until error conditions are cleared.)
Replaced/Superseded by document(s)
Standards for system specifications and system design documents
usually require the definition of the applicable states and modes of the system. However, little in the way of consistent advice of “why” or “how to” is available to the practitioner with the task of defining states and modes. This is particularly true in the domain of complex systems where formal specification methods are
generally not in use and most system definitions are conducted using plain language. A practical approach to defining states and modes is presented which has been found to be useful in defining design and requirements for complex systems including where pre-existing subsystems with extant states and modes need to be incorporated into the functional definition of the overall system.