Skip to main content
The AIG web pages make heavy use of cascading style sheet features for formatting. You may still browse the text of the site, but for best results, please use a CSS enabled browser. Netscape 6 and Mozilla 5 are good. IE 5 will do.

JPL Header



Navigation Sidebar



Main Content


Technology
Mission Data System

Technology Mission Data System Banner

State Analysis

The State Analysis methodology, which is based on the MDS Control System Architecture, defines a process for identifying and modeling the states of the physical system and their relationships with other states, the form of knowledge and control objectives against these states, and the planning, coordination, execution, and response mechanisms by which these objectives can be achieved in a reliable manner.

State Analysis is a form of model-based engineering, which begins with a model of the behavior of the system to be controlled, including any sensors or actuators needed to interact with this system, and then proceeds with models of needed control system capability. Both sets of models are then iteratively and incrementally refined over the course of development in an interplay that maintains synergy between them. State variables, measurements, commands, and the relationships among them are summarized in State Effects Diagrams, which provide maps into the detailed formal models of the system under control in various forms. The control system is modeled using appropriate mathematical representations, such as differential equations, or discrete modeling abstractions, such as Unified Modeling Language (UML) State Chart diagrams, and with additional means, such as Elaboration Diagrams, which describe goal-based planning elements of the control system design.

One of the basic tenets of State Analysis is careful separation between the control system and the system under control. The need to be explicit about the line between the system to be controlled and the system used to control it is driven by the dependence of the control system design on models of the system under control. This rather obvious point is nonetheless not as carefully defined as one would imagine in most systems, especially from a system point of view where complex interconnected and layered control may be involved. Sometimes this dividing line is the same as the boundary between software and hardware, but usually not, so the ambiguity of this line becomes a source of modeling ambiguity, as well, which tends to erode the integrity of control system designs that make no clear distinction (often in rather insidious ways). State Analysis and the MDS control system architecture enforce this delineation, making the application of models in the control system design much more straightforward and dependable.

Example state effects diagram

State Analysis is a formal process, which raises specific questions at each step, and guides the answers according to the rules of the MDS control system architecture. For example, representative questions asked of a state variable include the following:

  • If there are other affecting or affected states (including failure states), how are those state variables defined, what is their behavior and the nature of their relationships to other states, and exactly how do these states affect one another?
  • If measurements are available, what states (including failure states) contribute to their value, and exactly how do these states affect the value of given measurement samples?
  • Can a state one wishes to control be affected directly by issuing a command or can only it be changed only indirectly through affecting states? If by command, what states (including failure states) can modulate the effect of the command, how does the commanded state change in response to a given command, and what immediate side effects on other states are possible?
  • What types of goals must be defined for this state, including goals that operators introduce to direct system activities, goals expressing constraints for safety, resource management, conflict avoidance, and the like, and sub-goals that may be introduced to support other goals? What is the appropriate expression of modeled behaviors and relationships in the selection of sub-goals and associated temporal constraints? What is the appropriate expression of modeled behaviors and relationships in the projection of future behavior that is required to validate plans?
  • How does the control system determine the current value of this state? Are direct measurements available? Is knowledge of other affecting or affected states needed as evidence to estimate this state?
  • What control logic does the control system use to decide what commands need to be issued to the system under control, in order to achieve specified goals?

Other questions address software representations of state variables, measurements, and commands, the representation of uncertainty in state knowledge, the management of control system data, the transport of control system data among deployments, the selection of planning alternatives, both reactive and deliberative responses to unsuccessful goals (including fault responses), and the model-based pacing of execution through both state-based and time-based events.

The formal process of State Analysis defines these and other specific questions, leading to the model details needed to design a goal-directed control system, where operator intent is explicit at every level of control.


+ back to MDS Home


Contact Information

Kenny Meyer

M/S 301-225
4800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.393.4871
kenny.meyer@jpl.nasa.gov

Bob Rasmussen

M/S 301-225
4800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.354.2861
robert.d.rasmussen@jpl.nasa.gov


LEGAL NOTICE

All MDS Framework artifacts and State Analysis artifacts except for source code and object code have been designated by the California Institute of Technology (Caltech) as Technology and Software Publicly Available (TSPA). Copyright 2005. The copyrights and patents related to this technology are owned by Caltech. United States Government sponsorship acknowledged.

Footer



CL 07-3583