Simons started out in the early ’90s at NASA as a software engineer. After discovering an interest in systems analysis and operations, he joined NASA’s space-based Tracking and Data Relay Satellite System, and later obtained a master’s in operations research from George Washington University.
Simons moved again within NASA, developing ground data processing systems for earth-observing satellites that processed raw data into products for scientific interests. On one occasion, Simons devised a process for this enterprise—known as the Earth Sciences Data Information System Project—to deliver raw earth science data to an outside agency, allowing weather scientists to provide timely analysis to the general public.
It was while doing modeling and simulation at NASA on the Earth Sciences Data Information System project that Simons truly cut his teeth on systems engineering and fell in love with the discipline. “I saw that systems engineering could help organizations efficiently build and develop systems.”
In the early 2000s, Simons went to work for The MITRE Corporation, a federally funded research and development corporation based in McLean, Virginia that handles a mix of federally funded research and development projects for U.S. government agencies. At MITRE, just as he had at NASA, Simons held a number of positions, working in everything from Wide Area Networking to Service-Oriented Architecture to IT systems and even laser technology.
While at MITRE, Simons again returned to school to get a master’s in systems engineering from Johns Hopkins. After receiving his degree, Simons was asked to co-instruct a course in product management for their systems engineering program.
Meanwhile at MITRE, Simons learned Vitech’s model-based systems engineering tools CORE and GENESYS, and continued to work on complex systems, including a study for the FAA about consolidating facilities for air traffic service and how that affected voice communications. “When I first used CORE, I thought, why didn’t I have this product when I was at NASA?! It would have saved me a lot of pain and suffering.” At that time in the 1990s, most organizations used document-centric systems engineering processes. With CORE, the processes were more automated.
At its inception, systems engineering faced a largely complicated world. This meant that even systems with large numbers of elements might be loosely connected at the system level. Elements and subsystems could be separately and serially engineered and then assembled into larger systems without a lot of interaction between their designers and the architects of the overall system. The looseness of the system couplings allowed systems engineers to get away with organizing their work in siloes, both among the systems engineering domains themselves and among the various disciplinary engineering sectors. Even the use of separate models reflected the discontinuity and disconnection of the design discipline. That was the world of MBSE 1.0.
That world has evolved and continues to do so at a rapid pace. The complicated has now become complex. Linear cause and effect has given way to loops and adaptation. Systems engineering itself must evolve to keep pace with the context. We have lost the luxury of indulging in loose coupling in the design elements and the disciplinary engineering gaps alike. No longer can the engineering of detailed designs take place in a disconnected and serial manner. Engineering must become connected and concurrent. Models must enable and embody that sense of connection. That evolution is MBSE 2.0.
One of the evolutionary struggles for systems engineering in general and model-based systems engineering in particular is figuring how to incorporate the disparate inputs into the system design while at the same time maintaining an integrated system-level view of the design. It is absolutely necessary to see all the facets and perspectives of the system design in order to understand how it will behave and how its behavior will (or will not) satisfy the needs that drive its creation. At the same time, the system-level view must account for and incorporate all of the relevant streams contributing to the design in order to provide an accurate, high-fidelity picture of the system’s functioning in its intended context.
In introducing MBSE 2.0, this presentation will address the importance of a proven systems metamodel in assuring the completeness and efficacy of the design model. The systems metamodel makes possible the holistic view of the design that is critical to producing an effective solution. It provides the map to take the design from what is known to what is not. In order to do that it must be robust and have a track record of proven success at providing the framework for describing the design in its “as is” and “to be” states.
The challenge of connecting the variety of analytic and architectural models so that their critical insights can inform the design will also be a subject of discussion in this session. Concurrency in the engineering processes is critical both for the speed of delivery and for the “when needed” availability of engineering insights across the enterprise. Establishing the connective tissue that will allow connected and concurrent engineering is critical to the construction of a responsive and effective engineering enterprise. The session will explore the needs and mechanisms for making that happen.
MBSE 2.0 is a response to the challenge of complex, transdisciplinary problems. It will enable the systems engineer to evolve the engineering enterprise to position it for design success in a rapidly changing environment. This presentation will show the way along a path forward in that evolution.
