The “V” Model Reloaded

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.

The International Council on Systems Engineering (INCOSE) Space System Working Group (SSWG) has created the CubeSat System Reference Model (CSRM), a representation of the logical architecture of a CubeSat system, intended to be used by system architects and engineers as a starting point as they develop the logical architecture of the Space and Ground components of the CubeSat mission of interest to them. The CSRM is based on Model-Based System Engineering (MBSE) principles, is System Modeling Language (SysML) compliant, is hosted in a graphical modeling tool, and is intended to introduce quality enhancements and economies associated with reusability. The CSRM has been vetted by System Engineering professionals and has been introduced to the CubeSat mission development team community with favorable results. It has been submitted to the Object Management Group (OMG) as a CubeSat specification, and is being evaluated for that role. The SSWG has created a notional outline describing how the CSRM can be applied to a specific mission development effort; and has also identified possible future efforts to expand the applicability, value, and use of the CSRM by the satellite development community.

Lean Thinking is the paradigm that enabled Toyota to rise to the best and largest auto company in the world. The paradigm includes not only Lean manufacturing but also extraordinary effective Product Development and Systems Engineering, as well as a culture based on Respect for People.Systems Engineering is regarded as a technically sound process but often burdened with waste and inefficiencies. Lean Systems Engineering is a new body of knowledge applying the wisdom of Lean Thinking to Systems Engineering. Systems Engineering and Lean have overlaps and differences, but both represent processes that evolved over time with the common goal of delivering product or system lifecycle value to the customer. Lean Systems Engineering represents synergy of the two, leading to superior systems engineering process.Most emphatically, Lean Systems Engineering is not a re‐packaged FBC or Acquisition Reform“. Lean Systems Engineering does not mean ”less Systems Engineering”; it means more and better Systems Engineering, with better preparations, planning, front‐loading, training, and more common sense, leading to better program execution.Lean Enablers for Systems Engineering is a product designed by 14 experts from industry, academia, and U.S. and foreign governments, supported by 115+ strong Lean Systems Engineering Working Group of INCOSE. Lean Enablers are formulated as 194 “do's” and “don'ts” of Systems Engineering practice focused on Mission Assurance/Product Success and elimination of waste.The workshop will cover three parts: Description of the development process of Lean Enablers for SE Presentation of 194 Lean Enablers organized into six Lean Principles: Value, Value Stream Mapping, Flow, Pull, Perfection, and People. “Validation” of the Lean Enablers by surveys, and by benchmarking with recent studies by NASA and U.S. Government Accounting Office. Early feedback from past tutorials and implementation

<title>ABSTRACT</title> <p>The International Council on Systems Engineering <ext-link ext-link-type="uri" xlink:href="https://www.incose.org/">https://www.incose.org/</ext-link> is a recognized standards body defining a system engineering knowledge-base, but this knowledge falls short of fully recognizing manufacturing in the Systems Engineering (SE) framework. To be inclusive, Manufacturing needs to join in the initiative of Model Based Systems Engineering to be relevant and succeed in the digital transformation in the field of systems engineering. This paper addresses this need in manufacturing by applying Model Based System Engineering (MBSE) to the identification and management of key characteristics so that a more relevant set of Manufacturing requirements can be introduced into the MBSE construct and help realize manufacturing resilience and become a full SE partner.</p> <p><bold>Citation:</bold> “Identification and Management of Key Characteristics in Product Development Using Model Based Systems Engineering,” In <italic>Proceedings of the Ground Vehicle Systems Engineering and Technology Symposium</italic> (GVSETS), NDIA, Novi, MI, Aug. 15-17, 2023.</p>

One of the few things certain about development of complex systems is the requirements for the system will remain uncertain late into the development program. Even though we recognize this, why do many programs assume that requirements will not change (gambling) or treat requirement change as a risk rather than a certainty? An analysis of gas turbine engine control systems requirements shows that typically 50% will change between Critical Design Review and Entry into Service. This requirements uncertainty manifests as technical risk to the programme. This paper evaluates the impact of not managing these uncertainties and describes how applying Systems Engineering principles can reduce this effect.Design iterations produce rework, and without technical risk management, ~50% of the effort will be wasted in producing unacceptable designs. In turn, correction of these errors will create more rework. This results in much iteration and cumulatively twice as much work is required to produce a mature design. With technical risk management, less than 10% of the design effort will result in rework, giving a mature product with far less iteration.Investigation into the source of the product development lifecycle problems indicates many escapes occur during requirements definition and review. Around twice as many changes are driven by errors in requirement definition by the developer, compared to customer‐driven requirements changes. In addition, many of these escapes are detected later in the product development lifecycle than they could have been found, resulting in further escalation of the cost of product development. This paper compares and contrasts the root causes for these escapes during system, software and hardware development and looks at the differences in consequences.The role of the Systems Engineer is critical in addressing these problems. In addition to effective elicitation of requirements from stakeholders, the Systems Engineer must manage volatility and apply robust design principles to protect against the impact of requirements changes. The Systems Engineer must flow requirements effectively from system to sub‐system, from sub‐systems to components and provide the “glue” that results in the integrated system being more than the sum of its parts.Some tools and techniques are presented to help Systems Engineers identify probable sources of uncertainty and provide effective mitigations. An approach is also presented for assessing the technical risk management “maturity” of a project, based upon ‘best practice’ approaches taken from those projects achieving low levels of engineering scrap and rework during their development phase.

ABSTRACTEarly Systems Research and Development (ESR&D) is one of the most crucial phases in the product development process. It both blends and blurs the lines between science and engineering, and requires a risk‐based, disciplined, and graded approach to effectively manage scope, cost, and complexity of the final product. Many leaders, program managers, and scientists are unwilling to involve systems engineering because of the perception that systems engineering is heavily process oriented, adds unnecessary costs, and should be applied only to mature technologies. The value of systems engineering as applied to ESR&D is unclear to these key individuals. The unfortunate result is that system engineering is not applied to ESR&D. This results in R&D efforts that may have solved the wrong problem, selected the wrong architecture, require technical rework, have difficulty transitioning later maturity levels, and result in higher R&D costs and extended development timelines. This article discusses the difficulty of introducing systems engineering to the research and early development process and their inclination perspectives of researchers, engineers, and managers. The article shall offer potential means to manage the cultural transformation of early adoption of right‐sized systems engineering in ESR&D and reverse the attitudinal positions.

Over the years, the world's defense industries have become quite proficient at developing large, complex hardware and software systems. In recent years, the ubiquitous deployment of personal computers has changed the way we work. Additionally, took designed to facilitate systems engineering have recently matured enough to start having a major impact on many major systems development efforts. Finally, the government's faster-better-cheaper acquisition philosophy has started driving prime contractors to a concurrent engineering approach toward systems engineering. This confluence of experts is has had unexpected impacts on both the flexibility and rigor of requirements management processes. While the maturing requirements and design took hold great promise in maintaining requirements traceability throughout the design process, the widespread use of desktop computing systems has inadvertently lulled many experienced systems engineers into sloppy processes because it now appears to be a simple matter to make a requirements change in a softcopy of a requirements document. Without strong process and management support, requirements changes inevitably start being derived in a broad spectrum of incompatible took and formats. This author is currently participating in the design phase of a major classified government satellite development effort. As an integral member of an extremely experienced requirements management team (boasting over 150 years of combined experience in the defense industry), this author has had the opportunity to watch the team navigate straight into many of the systems engineering potholes created when talented engineers implement concurrent engineering using a variety of tools without a consistent process framework. This paper, therefore, specifically addresses process and implementation challenges that arose when establishing a software-assisted concurrent-engineering approach on a large satellite development contract.

As economic pressure continues to mount worldwide, closer cooperation is needed between people, companies and even countries. At the same time, the scale of projects is constantly rising. In order to ensure the success of large-scale projects, the way different teams cooperate is becoming increasingly important. Cooperation between systems engineering and project management is now key in this respect. On the other hand, it is widely recognised that the use of standards can improve the success ratio. Thus, integration using standards or guides from systems engineering and project management can help companies improve their competitiveness. A host of standards or guides have already been published in both domains. The purpose of this paper is to take the most frequently used standards or guides from systems engineering and project management, to compare them and build a bridge between them so as to provide a view shared by systems engineers and project managers enabling them to carry out their projects effectively.

Over the past two decades, our understanding of product development has changed fundamentally. Disciplines that were once clearly distinct from one another, such as mechanical engineering, electrical engineering, and software development, have now become increasingly intertwined. Products are no longer isolated objects, but rather nodes in a network of systems, data, and processes. In this environment, it is no longer enough to manage individual data sets – they must flow, remain consistent, and be available to the right people at the right time. The AI based lifecycle management system of Digital Threads (Digital Thread for short) has therefore established itself as the backbone of modern system engineering. Early approaches to product data management (PDM) focused on central storage of CAD data and the management of versions and approvals. However, with the advent of complex mechatronic systems, networked vehicles, and modular plants, it became clear that this approach was not sufficient. Companies began to realize that it was not enough to simply store geometries; they needed a system that mapped the entire lifecycle of a product, from the initial requirement through development and production to operation and decommissioning. Today, Digital Threads’ AI based lifecycle management system acts as a digital nervous system that connects disciplines such as mechanics, electronics, software, and simulation. While system engineering provides methodical approaches for structuring requirements and architectures, Digital Thread ensures that the associated data are findable, traceable, and up to date. This object oriented approach creates transparency and enables end to end traceability, which is a key requirement of modern systems engineering. Another feature of modern digital thread approaches is the seamless integration of models and product data. Changes in one discipline, for example, in design, can automatically detect and forward all affected areas such as requirements, tests, and functions. This promotes the continuous flow of information and prevents unnoticed consequences of changes elsewhere in the system. The close link between AI based lifecycle management systems for digital threads and system engineering goes beyond technical necessities and promotes cultural change in companies. Organizations must not only introduce technology, but also clearly define processes and responsibilities in order to fully exploit the effectiveness of this system. Clear, transparent handling of changes, systematic management of variants and integration of real time data from operations are key success factors for the implementation of digital threads. The concept of ”‘digital twin’, which enables a continuous connection between the models of real and virtual products, can only be realized through the consistency and transparency offered by the digital threads. This, in turn, promotes more sustainable and data driven decision making processes that can be taken into account throughout the entire product lifecycle, from development to maintenance. Overall, it is clear that AI based digital thread lifecycle management systems not only provide the technical basis for system engineering, but are also an integral element for the successful development and operation of complex, networked systems. They promote innovation, improve quality, and enable companies to make their product development more flexible and efficient.

<div class="htmlview paragraph">A major focus of many implementation discussions on Systems Engineering revolves around developing a large database of information, to be reused later, benefiting the company's product development process. Business needs for agile and flexible responses place pressure on the maintenance of the database during Sustaining Engineering of the product. The business needs of the product management functions are discussed to frame the problem of maintaining the Systems Engineering database. This paper focuses on the maintenance of the Systems Engineering database during Sustaining Engineering activities. The process for ensuring the ‘Systems Engineering Documentation Set’ is being kept current is analyzed and described. Experiences regarding the dynamics of a Matrix Organization for Sustaining Engineering are discussed.</div>

This paper compares two popular design methods used in product development, namely Systems Engineering (SE) and agile methods. The comparison is based on various criteria, such as ease of implementation, object of innovation, software-dependency, customer relations, human centricity, organizational structure, values, and innovative capability, which were developed in a previous paper. The content of the comparison is supported by a literature review and a workshop with industry professionals. The findings show that both SE and agile methods have similarities and differences based on the criteria examined, and the choice of methodology depends on the project's specific context and objectives. While this paper provides only a general overview of each criterion and their compatibility, the results can assist product development teams in selecting the most appropriate approach for their needs. However, more research is necessary to enhance the effectiveness and efficiency of both approaches. This paper is a useful resource for practitioners and researchers interested in understanding the similarities and differences between SE and Agile and making informed decisions regarding their use.

ABSTRACTModel‐based systems engineering (MBSE) with agility can help systems engineering programs which deal with both increasing complexity and frequent changes in environment and usages, shorter time‐to‐market, uncertainty of the needs, and more sophisticated industrial schemes. Agile approaches originated in software engineering can be extended and tailored to a certain extent to complex systems engineering and particularly to MBSE. Main benefits of agility are provision of a minimum viable product as early as possible in the schedule, early capture of changes of needs, enabling to deliver a system answering to the real needs, and securing of the value proposal. It includes also potential reduction in rework of the final system through regular customer feedback throughout development (left shift for the defect correction with early exposure), and efficiency of the use of resources. Concerning MBSE, the use of models as a single source of truth for completeness and consistency is useful to share and secure the design by improving communication within engineering teams and the building and support of the development strategy, and to help to automate some tasks such as model exchange and synchronization. In addition to the benefits of each approach, combining them may help to: ▪ Organize and synchronize the development and validation effort of one or multiple engineering teams. ▪ Faster impact analysis including trade‐off studies/options and hence a faster reaction to evolutions in expectations and constraints, that is, the agility of systems. ▪ Show regularly “end to end” value to the customer and other stakeholders.

Stakeholder needs are the basis for the derivation of technical requirements in systems engineering. However, current definitions of stakeholder needs do not clearly distinguish stakeholder needs from requirements and do not provide a clear characterization. A clear distinction would especially allow the relationship of needs and requirements to be analyzed in the model of SGE - System Generation Engineering. The aim this contribution is the definition and formulation of stakeholder needs in systems engineering, as well as their description in the model of SGE. For this purpose, a systematic literature review is conducted to examine how stakeholder needs are described literature. The definition proposed based on these results is then evaluated in two industrial studies. A case study at a German vehicle manufacturer has shown that the characteristics of the definition can be found in practice and a study at a German industrial machine manufacturer has shown that the definition can help product developers to identify stakeholder needs.

Managing modularity and commonality throughout product and process development has been well recognized as crucial to producing a large variety of products while maintaining low costs and quick response to the market. In recent years we have seen growing consensus and an increasing number of publications related to modularity and commonality, as well as many endeavors in industrial applications. This special issue is dedicated to reporting recent advances in modularity and commonality research. Of particular interest is a comprehensive view of modularity and commonality, encompassing design, production, logistics, and organizational aspects. Based on thorough and strict peer reviews, a total of 10 papers were selected for publication from 48 submissions. These papers represent a snapshot of cutting-edge research and aim to disseminate recent developments in the field of managing modularity and commonality. The paper by Fixson, ‘Modularity and Commonality Research: Past Developments and Future Opportunities’, provides a comprehensive literature review. It substantially extends this editorial discussion on the status quo of approaches and techniques for managing modularity and commonality in product and process development. In the paper, each of the cited references is analyzed along the dimensions’ subject, effect, and research method. The subject of study involves the product, process, organization, and innovation, whereas the set of references indicate that a strong preference is geared towards the product. Also studied is a broad range of effects, with cost issues receiving the most attention. The survey reveals that a variety of research methods have been applied to the study of modularity and commonality, but the distribution of research methods differs substantially in modularity and commonality research. One important avenue for future research lies in studies that incorporate multiple effects of modularity and commonality on various players along the supply chain, that combine multiple research methods, and that follow systems over time. Holtta-Otto and de Weck, in their paper, ‘Degree of Modularity in Engineering Systems and Products with Technical and Business Constraints’, observe that modularity has many benefits, from cost savings due to increased commonality to efficient realization of a higher variety of products. In regard to full modularity, they show how engineering systems and products, whose design is heavily influenced by technical constraints, tend to exhibit rather integral architectures. On the basis of a binary design structure matrix representation of a system or product, they propose a metric of nonzero fraction capturing the sparsity of the interrelationships between components, along with a singular value modularity index indicating the degree of internal coupling. Empirical evidence is presented suggesting that the lightweight variant of the same product tends to be more integral, contributing to higher mass efficiency. Comparative studies of sparsity and modularity reveal that some products are inherently less modular than others due to technological factors. The paper by Thevenot, Simpson, Alizon, and Shooter, ‘An Index-Based Method to Manage the Tradeoff between Diversity and Commonality during Product Family Design’, emphasizes the commonality issue in product family design. This paper examines existing commonality indices with respect to the tradeoff between commonality and diversity inherent in product families. A design for commonality and diversity method is developed based on two new commonality indices: the commonality diversity index and the comprehensive metric for commonality. An example application involving a family of single-use cameras is reported, demonstrating decision making at both the functional and component levels during product family design. With focus on design reuse, Meehan, Duffy, and Whitfield, in their paper, ‘Supporting ‘‘Design for *Author to whom correspondence should be addressed. Email: jiao@pmail.ntv.edu.sg

Large amounts of different materials are used when building and maintaining railway infrastructure, and the environmental impacts from the upstream production stages are significant. Industry’s motivation to innovate is low, new products or methods are rarely used, and the lowest price is the main driver for selecting a tender. Integrated Product Service Offerings, or IPSO, has been put forward in the research literature as a potential concept to, from a life-cycle perspective, reduce the environmental impact of products and services, increase cost efficiency and quality, and act as a driver for change. Therefore, this thesis attempts to answer to the aim: “Can the concept of Integrated Product Service Offerings improve the management of rail infrastructure and if so, what would such an implementation induce in terms of risk factors?” The Swedish rail infrastructure is used as a case to discuss the considerations and feasibility of such an implementation. Theories such as product development, information asymmetry and innovation are used to complement the literature focusing on IPSO. The empirical part of the thesis has been collected using individual interviews, group interviews and a survey approach. The contracts currently used in the railway industry have several advantages, such as being a familiar business model that is straightforward to calculate for the contractors. However, they are not optimal for innovation due to e.g. detailed specifications, standards and technological and market lock-in effects. Technological and market lock-in, in combination with a lack of information transfer between different contracts and actors, are major disadvantages with the current practice. Furthermore, the buyer’s conservative business culture makes it difficult to implement new types of contracts since it is difficult to break old habits. Even though the providers are part of the same mature market, the organizational changes needed for them to fulfill IPSO contracts are not seen as a barrier. A benefit with IPSO is the holistic life-cycle perspective that provides incentives for dematerialization, resulting in a more resource-efficient and durable infrastructure. IPSO requires improved information transfer, something which stimulates innovation as well as processes for evaluation of the contracts. Further benefits are potential incentives to get contractors involved in the design phase, where the major decisions about the life-cycle are made, in order to reduce the infrastructure's environmental impact and total life-cycle cost. The contractors hope that IPSO contracts will make the buyer focus less on e.g. the initial purchasing price and more on the total life-cycle cost in relation to quality in order to get the best solution. The actors see themselves as parties with opposing interests. At the same time, IPSO will most likely imply more long-term cooperation, something that calls for common interests, shared risks and flexibility. The innovation possibilities with IPSO could benefit from loosening up the material handling monopoly that the buyer currently holds. Since the buyer is a dominant actor within the industry, this organization has major possibilities to introduce changes that the other actors would have to conform to. Several challenges with IPSO are discussed, and most of them are derived from the risk and uncertainty aspects that come with long-term contracts and inexperience with a new business model. On one hand, the contractors request more flexibility; on the other hand, they are reluctant to take on more responsibility that could lead to increased risk. However, risk does not have to be seen as something completely negative, as it depends on how the contractors choose to deal with it. They can either develop the necessary skills and competence needed to identify and handle the risk in a strategic manner, foster a competitive advantage, or take the problems as they come in a more ad hoc way. A way to reduce risk and uncertainty seems to be to focus on transparency and information sharing between the actors and the contracts. This would also open up IPSO contracts for reinvestments, where the current lack of information concerning the condition of the facilities results in reluctance for IPSO contracts. This research has focused on IPSO for rail infrastructure management, using the Swedish rail infrastructure as a case to discuss the considerations and feasibility of such an implementation. The conclusions, therefore, are valid for rail infrastructure in other geographical locations as well.