[MUSIC] In the past 20 years, systems have become increasingly complex in terms of size, responsiveness, and number of interactions required to accomplish their goals. Technologies in communication, human computer interaction, and computational power have all advanced, increasing efficiency, but also opening up new vulnerabilities in complex systems. These challenges as well as the necessary responses, increase the scope and complexity of the information required to develop a solution. As a result, authoritative and shared models have been developed, creating the paradigm of model-based systems engineering. [MUSIC] According to INCOSE, model-based systems engineering, also known as MBSE, is the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing through development and later life cycle phases. Model-based systems engineering is still in a dynamic state of development and is a vast topic to fully address. As a result, this course is offering a broad perspective with connections throughout the course that give you the opportunity to learn more about a topic of interest. With this in mind, the INCOSE Systems Engineering Vision 2025 document describes MBSE as, quote, still in an early stage of maturity similar to the early days of CAD and CAE, unquote. A key component of model-based systems engineering is the model-based definition, or MBD. Model-based definition embodies the concept of moving away from paper-based documentation and drawings to digital, 3D CAD representation, manufacturing data, and performance models. As an example of the dynamic state of MBSE, the definition of MBD is still evolving and converging. Standards, like ASME Y 14.41, ISO 16792, and MIL-STD-31000, can provide guidance on how to annotate drawings. But multiple perspectives exist in regards to what makes up a model. A recent definition I heard distinguishes between the representation or the attributes that describe an object, and the presentation, the way in which those attributes are communicated. The same representation could be presented as a 2D drawing, a 3D visualization, as a cloud of surface points, or as a functional black box seeking input and providing output. This is all reminiscent of the blind people describing an elephant analogy. The elephant doesn't change, just each person is interacting with it in different ways. Well-formed, a model should change its presentation depending on what is being asked of it. The Digital Manufacturing and Design Innovation Institute defines a model-based definition as a, quote, complete 3D Digital Product Definition created at the beginning of the product lifecycle to be used throughout the enterprise, reducing costs, improving system performance, and enabling future systems upgrades, unquote. With this definition, the technical data package or TDP, defined in MIL-STD-31000, is a subset of the digital product definition package. And for a more detailed description of a model-based definition, read the NIST publication promoting model-based definition to establish a complete product definition. It is available in the resources section and provides a useful perspective on the state of model-based definition. Two important aspects of building models are verification and validation. The INCOSE System Engineering Handbook uses the following informal definition. Verification ensures you built the system right. Validation ensures you built the right system. In general, systems engineering uses the following conventions for verification and validation. Verification is the determination that each element of the system meets the requirements of a documented specification. On the other hand, validation is the determination that the entire system meets the needs of the stakeholders. Validation only occurs at the top level of the system hierarchy. For a fuller description, the SEBoK points to Wasson's 2006 book, System Analysis, Design, and Development, specifically, pages 691 to 709. For a complete investigation of the concepts of verification and validation from a systems engineering perspective. In contrast, domain practitioners may use slightly different working definitions of verification and validation. The American Society for Mechanical Engineers, ASME, has established the ASME committee for Verification and Validation in Computational Solid Mechanics. In the ASME guide for Verification and Validation in Computational Solid Mechanics, the following definitions are used. Verification, verification is the process of determining that a computational model accurately represents the underlying mathematical model and its solution. And validation is the process of determining the degree to which a model is an accurate representation of the real world from the perspective of the intended uses of the model. In other words, verification is about mathematics, and validation is about physics. There is a nuanced gap between how systems engineers look at verification and validation, also known as V&V, versus how other engineers, especially those performing specific domain-based analyses, view V&V. What stands out to me is that in systems engineering, the scope of verification is on the elements. And the scope of validation is on the system. Whereas the ASME perspective focuses on the accuracy of the model, verification, versus choosing the correct model validation. As a result, there needs to be explicit communication about the applicable meaning of verification and validation when performing MBSE. >> So an aspect of systems engineering that is not often understood is it is meant to be a concurrent practice. And it's meant to be a concurrent practice throughout. I talked about the need to have all the specialists engaged as you're studying the problem and developing the solution. That's true, but you're also simultaneously looking at the requirements, looking at the logical solution, what we call behavior. Looking at the physical solution and looking at quality verification and validation. And you do that at layers of the detail. So in good systems engineering, you're not doing a depth-first search, where you verify at the end. You're doing a lateral search where you design a high-level answer. And when you find that that architecture will solve the problem, albeit at an abstract level, then you go down to the next level of detail and next level of detail and next level of detail. And so you are actually doing continuous V&V throughout. You're moving from a high level of abstraction to a low level of detail. That requires slightly different skills. But it requires more of a mindset to transition to this concurrent intent that was always there in systems engineering as opposed to this waterfall mentality that unfortunately became embedded in our organizations.
