By Stephen J. Kapurch
Winston Churchill once famously remarked that the United States and Britain are two great countries separated by a common language. That’s a useful metaphor for thinking about the discipline of systems engineering. If you ask any two systems engineers to define the job, chances are that you’ll get two very different answers.
Part of the reason there’s so much disagreement about the definition of systems engineering is because of the difficulty of measuring its value. If you’re a structural engineer or a thermal engineer, success is easy to measure: the system sustains all the loads and performs as predicted or the spacecraft reenters the atmosphere with no problems. In systems engineering, if you use a good, consistent approach, you reduce the system risk and rework. It’s difficult to calculate the resources you save by doing things right the first time.
A common misconception about systems engineering is that it is an “up-front” activity that takes place only in the requirements definition phase of a program or project life cycle. That view doesn’t properly account for the complexity of engineering and integrating systems. As systems are added and modified over the course of development, the number and complexity of interfaces increases in a nonlinear fashion. Problems resulting from conflicting or missing interfaces are the norm, not the exception. The only way to deal with this type of dynamic environment is by adopting an end-to-end, logical systems approach that emphasizes robust modeling and simulation, verification, and validation testing. These rigorous systems processes must be repeated throughout the life cycle of a system to detect unexpected consequences that can flow from even small design changes.
Given the complexity of the systems that NASA is now designing for the Vision for Space Exploration, it’s essential that we have a shared understanding and a common language that will enable us to do our jobs effectively across organizational lines. To address this need, the Office of the Chief Engineer has undertaken an overall systems engineering excellence initiative. Its objective is not to define what a systems engineer does; rather, it is to transform systems engineering from a task performed by individuals to a logical systems approach performed by multidisciplinary teams.
A systems perspective does not just belong to the person who wears the “systems engineer” badge. Even though you might be a thermal engineer, you need to understand the requirements that are allocated from the system above and flow down to the subsystem below your system. You need to know what your margins are and how you fit into the overall project. That way, when you conduct trade studies or select a design, you understand how your system operates within a bigger whole. Educating just systems engineers is insufficient. NASA as a whole is adopting a systems approach.
This multidimensional problem calls for a multidimensional approach. The Office of the Chief Engineer’s systems engineering excellence initiative has three dimensions: common technical processes, tools and methods, and workforce training and development. By integrating processes, tools, and training, this approach aims to create an engineering culture in which continuous improvement is the norm.
NPR 7123.1 is the result of an extensive, iterative effort to define the common technical processes of systems engineering. The team that developed the document represented all NASA Centers and mission directorates. Before the writing began, the 7123.1 team held a series of workshops with both NASA stakeholders and external experts, including officials from government agencies, private industry, and professional organizations. Their perspectives helped us survey the state of systems engineering both within and outside NASA and identify common practices. Most importantly, though, the workshops made clear that promoting a systems approach across all engineering disciplines will require a change in culture that won’t happen overnight. It will take time, persistence, and support from senior management.
The document itself describes at a relatively high level what to do, not how to do it. The challenge in developing it was to target the right level of detail—neither too detailed nor too general—and create something that adds value. There are important differences in the types of projects that NASA conducts. Within that range, the NPR defines a standard design review approach that conforms to the common life-cycle definition spelled out for programs and projects in NPR 7120.5D, and it lays out a systems engineering process that can be applied to any system, regardless of scope or scale.
Once the team completed a draft, we ran it through four tabletop simulations involving the Constellation program, satellites, ground systems, and research projects. These exercises led to significant changes that made it more practical and user-oriented. It’s no secret that if the document doesn’t help people do their jobs, it’s going to be shelfware.
In short, NPR 7123.1 is part of a larger initiative to develop and implement a common systems engineering framework at NASA. The missions and systems ahead demand a revolutionary advancement in our capability. The only way to get there is through a continuous improvement process that is well understood, consistently applied, and flexible enough to meet the diverse needs of our programs and projects.
About the Author
 |
Stephen J. Kapurch is currently assigned to the Office of the Chief Engineer at NASA Headquarters. In this position he directs the Engineering Excellence Initiative to assess and improve NASA systems engineering processes and the Advanced Engineering Environments Program. |
