Technology
Mission Data System

MDS Objectives
The present state of systems and software engineering practice does not adequately address the needs of software-intensive, mission-critical control systems. This applies broadly across aerospace, energy, transportation, and other sectors. For example, current practice is generally weak in reasoning about key system-level concerns like fault protection and autonomy, both of which have a significant impact on implementation, testing, and operations.
The MDS project was formed in 1998 to address these limitations.
Here are a few of the key issues the MDS team was chartered to address:
- Frequent misunderstandings between system engineers and software engineers caused by mismatched system abstractions; the resultant flawed translation frequently leads to defects.
- Awkward operational mechanisms; system operation is complicated, limiting and error prone.
- Daunting system issues caused by the large number of interacting system states; validation is ad hoc, incomplete and piecemeal.
- Large uncertainty in plans for system development and integration; cost and schedule are frequently underestimated.
In response to these issues, the MDS team developed a principled architectural approach that addresses control issues at a fundamental level, while introducing essential, unifying structure into the engineering and design processes. This approach provides the foundation for a new class of model-based systems and software engineering methodologies and tools needed to manage requirements emerging in the next generation of mission critical systems.
MDS Themes
Model-based Engineering
Models are key to having a common and complete understanding of the system under control, so mathematical modeling has long been a part of control systems engineering. Traditionally, mathematical or conceptual models have been used to inform a design, but typically not in a way that is directly apparent within the implementation (with a few notable exceptions). Making models more broadly explicit in both the design and the implementation helps to ensure consistency, and to clarify dependencies on the models.Software Architectures
Software architectures and architectural patterns define rules governing the entities in a system, their roles, and their interactions. The rules are intended to encourage good practice, avoid known risks, maintain design integrity, and enable higher-level analysis and verification of a system that would not be possible in a less structured design.Principled Methodology
The State Analysis process provides a formal methodology for decomposing complex systems according to the interacting states of the system, and their models of behavior. Based on widely-used principles of model-based systems engineering, control system theory, and software engineering, this process helps to improve collaboration between systems engineers, who define system requirements, and software engineers, who implement them, by providing a framework for the unambiguous and thorough communication of requirements.+ back to MDS Home
Contact Information
Mitch Ingham
M/S 321-5414800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.393.6426
mitch.ingham@jpl.nasa.gov
Bob Rasmussen
M/S 301-4224800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.354.2861
robert.d.rasmussen@jpl.nasa.gov
David Wagner
M/S 301-4904800 Oak Grove Dr.
Pasadena, CA 91109-8099
818.354.1148
david.wagner@jpl.nasa.gov