At the dawn of a systems engineering process

This paper investigates the oversimplification of the inherently complex systems engineering process in space life support. The standard systems engineering process steps are described. The International Space Station (ISS) life support system is explained with its goals and performance criteria. Although it is not usually emphasized, the essential function of developing a hierarchy of systems and subsystems is to simplify the design process. The System Complexity Metric (SCM) shows how this divide‐and‐conquer approach also reduces the system complexity. The complete systems engineering process has many detailed steps. It is often simplified because of the effort required and the human limitations on working memory and decision span. Systems analysis demands slow, logical, and focused thinking but is often bypassed in favor of quick, intuitive, subconscious “gut feel.” A study of 100 system designs found examples of 12 specific mental mistakes, such as ignoring stakeholder needs, and these mistakes are essentially oversimplifications of the systems engineering process. An analysis of space life support goals, options, criteria, and processes found 11 examples of oversimplifications in systems engineering, such as neglecting safety and cost. All these 11 oversimplifications could be traced to one or more of the 12 previously identified mental mistakes or other well‐known ones, such as ignoring sunk costs. Oversimplification of the systems engineering process is rarely noticed but is a common and harmful problem. A study of failures in 50 different space systems found that problems in systems engineering caused failures and often led to errors in design, development, and test that further contributed to failure. It seems that more diligent systems engineering could prevent many project problems and failures, but projects seem to be more guided by “gut feel” based on tradition, authority, and consensus than on the logical, rational systems engineering approach.

Completing its final development and early deployment on the Navy's multi-role aircraft, the F/A-18 E/F Super Hornet, the SHAred Reconnaissance Pod (SHARP) provides the war fighter with the latest digital tactical reconnaissance (TAC Recce) Electro-Optical/Infrared (EO/IR) sensor system. The SHARP program is an evolutionary acquisition that used a spiral development process across a prototype development phase tightly coupled into overlapping Engineering and Manufacturing Development (EMD) and Low Rate Initial Production (LRIP) phases. Under a tight budget environment with a highly compressed schedule, SHARP challenged traditional acquisition strategies and systems engineering (SE) processes. Adopting tailored state-of-the-art systems engineering process models allowd the SHARP program to overcome the technical knowledge transition challenges imposed by a compressed program schedule. The program's original goal was the deployment of digital TAC Recce mission capabilities to the fleet customer by summer of 2003. Hardware and software integration technical challenges resulted from requirements definition and analysis activities performed across a government-industry led Integrated Product Team (IPT) involving Navy engineering and test sites, Boeing, and RTSC-EPS (with its subcontracted hardware and government furnished equipment vendors). Requirements development from a bottoms-up approach was adopted using an electronic requirements capture environment to clarify and establish the SHARP EMD product baseline specifications as relevant technical data became available. Applying Earned-Value Management (EVM) against an Integrated Master Schedule (IMS) resulted in efficiently managing SE task assignments and product deliveries in a dynamically evolving customer requirements environment. Application of Six Sigma improvement methodologies resulted in the uncovering of root causes of errors in wiring interconnectivity drawings, pod manufacturing processes, and avionics requirements specifications. Utilizing the draft NAVAIR SE guideline handbook and the ANSI/EIA-632 standard: Processes for Engineering a System, a systems engineering tailored process approach was adopted for the accelerated SHARP EMD prgram. Tailoring SE processes in this accelerated product delivery environment provided unique opportunities to be technically creative in the establishment of a product performance baseline. This paper provides an historical overview of the systems engineering activities spanning the prototype phase through the EMD SHARP program phase, the performance requirement capture activities and refinement process challenges, and what SE process improvements can be applied to future SHARP-like programs adopting a compressed, evolutionary spiral development acquisition paradigm.

This paper describes and expands upon the proposed System of Systems Engineering (SoSE) Process Framework for the Air Force Materiel Command first outlined in IEEE SoSE 2011. Through repeated uses, it became quickly understood that systems-of-systems processes were foundationally similar to but different from basic systems engineering processes. The SoSE Process Framework, supporting processes, and products provide a context to integrate across modern complex systems-of-systems. In defining the SoSE Process Framework we tailor existing systems engineering processes and add a minimal amount of SoS-level engineering to it. The four core SoSE processes, Architecture and Analysis, Test and Evaluation, Management and Governance together can help to successfully deliver integrated capabilities at the SoS and Enterprise level within the U.S. Air Force. The key concept introduced is the alignment of analysis and engineering efforts across the Enterprise System Engineering and Architecting realm, and the synchronization of decision making within the SoSE components. The paper concludes by discussing implications of the SoSE Process Framework, as well as recommendations for actions, products, key stakeholder decisions and future challenges.

Thirty Years of International Symposia on Process Systems Engineering

The systems engineering process, applied across a typical system life‐cycle model, features design, or synthesis, as a core element. Creativity and innovation are required, to varying degrees, in all successful synthesis activities in systems engineering. The process of creativity and innovation in systems engineering is, however, poorly understood and is not adequately fostered. Educational institutions also place little emphasis on creativity and innovation in undergraduate teaching. This deficiency results in an engineering culture that is frequently resistant to the factors which promote creativity and innovation. This paper presents a phase‐model of creativity which maps onto the process of synthesis in the systems engineering life‐cycle. The paper serves as a framework for fostering creativity and innovation in systems engineers, at all levels, as well as for embedding a creativity culture in the systems engineering process.

System Engineering usually has a key technical responsibility on systems acquisition projects. The activities normally viewed as systems engineering include Mission Requirements Analysis, Functional Analysis, Requirements Allocation, Synthesis, Optimization and Specification. This is insufficient in practice. There is a lot of confusion over the relationship of systems engineering functions to the life cycle of system development effort. The National Council on Systems Engineering's (NCOSE) national Systems Engineering Process Description Working Group (SEPWG) has been chartered to prepare a description of systems engineering to clarify its roles. The SEPWG has determined that a new way of thinking about systems engineering is needed. This new paradigm includes understanding of two levels to systems engineering; considering all systems engineering customers; and learning and applying systems engineering to projects. This SEPWG Chair Report identifies some of the problems facing systems engineering, addresses the other development participants with whom Systems Engineers must work, and identifies the overall activities and processes in each aspect of systems engineering as used throughout the system life cycle. This report establishes a “sense of the SEPWG” baseline for efforts still underway for the NCOSE interest group members supporting the SEPWG.

Simultaneous and collaborative development of satellites and Information Systems to support their lifecycle processes

Process systems engineering: From Solvay to modern bio- and nanotechnology.: A history of development, successes and prospects for the future

ABSTRACTGDE Systems has initiated a systems engineering process improvement program to align with industry movement towards systems engineering process maturity, improve risk management, and focus on up‐front system requirements. The approach was to obtain the current state of the practice from the GDE Systems projects and from industry (INCOSE, SPC, etc). This information was used, together with the Systems Engineering Capability Maturity Model, to establish the company systems engineering process. The initial systems engineering policy and company operating manuals were then generated to establish the process requirements and to document the methodology. The projects were then internally assessed to determine their individual level. The results were used to improve the processes and prepare for a formal appraisal at the end of 1997. The formal appraisal was conducted and future actions were planned to meet Level 3, 4, and 5 goals.

Process systems engineering developments in Europe from an industrial and academic perspective

Energy Systems Engineering

The infusion of engineering (CogE) methods and tools into traditional systems engineering processes and practices is becoming an important priority as the systems engineering community begins to tackle system of systems (SoS) problems. As one illustration, the military is interested in creating cognitively-inspired systems (as small as a PDA and as large as a weapon platform) that maximally exploit human potential while also accelerating both human supported and automated decision making. To date, engineering has been successfully applied to the planning and requirements definition phases of systems engineering (also known as front-end analysis) but has yet to be infused into the remaining phases of systems engineering. To span the full systems engineering lifecycle, it is important, first and foremost, to communicate the return-on-investment to the various stakeholders to get their buy in. The second question that needs to be answered is whether or not cognitive engineering is ready for primetime. This paper presents promising technical and management strategies to overcome the challenges in introducing engineering into system-of-systems engineering (SOSE). Specifically, it presents a representative set of engineering methods and tools to span the full SoS life-cycle as well as engineering awareness initiatives to penetrate both the DoD acquisition community and commercial industry.

Application of Systems Engineering to USAF Small Business Innovative Research (SBIR)

Systems engineering (SE) processes applied on projects are often compliance driven with a focus on completeness, rather than value and efficiency. Most projects can benefit by applying better SE process tailoring. We illustrate how the SE process was tailored for the MeerKAT project by following broadly two strategies: customizing the process for the unique properties of the project and optimizing the process by identifying the high value process elements upfront and focusing the SE effort on these high value activities.

The recent financial crisis and the ensuing sovereign debt crisis once again highlighted that understanding the potential instabilities in the financial system is of great societal value. Financial instability typically results from positive feedback loops intrinsic to the operation of the financial system. The challenging task of identifying, modeling, and analyzing the causes and effects of such feedback loops requires a proper systems engineering perspective that is lacking in the remedies proposed in recent literature. We propose that signed directed graphs (SDG), a modeling methodology extensively used in process systems engineering, is an appropriate framework to address this challenge. The SDG framework is able to represent and reveal information missed by more traditional network models of financial system. This framework adds crucial information to the edges in a network in terms of the direction of flows and relationship between the variables associated with the nodes at the two ends of a directed edge, thereby providing a framework for systematically analyzing the potential hazards and instabilities in the system. This article also discusses how the SDG framework can facilitate the automation of the identification and monitoring of potential vulnerabilities. These are illustrated with an example of a bank-dealer case study.