[MUSIC] This is the first lesson of the course on Model-Based Systems Engineering in the Digital Thread, part of the Digital Manufacturing and Design specialization. As you may remember from other courses in this specialization, my name is Ken English, and I'm serving as a guide to navigate this new approach to making products. The ultimate goal of this course is to equip you with the ability to perform a readiness assessment for the digital thread. Systems engineering has been around for some time, but has undergone some major advances over the past ten years, with technologies and standards creating an environment of harmonization and convergence. Understanding model-based systems engineering, or MBSE, and the model-based enterprise, MBE, will give you a new perspective on product design. As we go through the first module of this course, you will focus in on the core concepts of systems engineering. [MUSIC] >> I'm David Long, president of Vitech. And I was actually born to be a systems engineer. My father was a systems engineer, and while he did not push me into the field, the way he taught me to see the world was through a systems lens. And so it really dates back to that time. If you're a true systems engineer, you struggle to see the world in any other way. My father grew up in the aerospace industry with an organization by the name of TRW, now part of Northrop Grumman, and is the father of what we today know as model-based systems engineering. He did the earliest work back during the late 60s ad early 70s for ballistic missile defense. Continued that research on through, well, the 90s when we founded Vitech Corporation together, and on to his death in 2010. Since then, I've picked up the ball and moved it forward. Systems engineering to me is a critical aspect of the 21st century as systems become more complex. And that's the journey, to continue to move it forward to deal with ever more complexity in an ever better way. >> As products have become increasingly complex, the connections between components becomes increasingly important. The connections can be physical or functional. If you think about a simple system, it is easy to see how adding individual subsystems creates more and more potential connections. Each of these connections are opportunities for waste, errors, and rework that can result in projects that are late, over budget, and have reduced capabilities in terms of performance, maintenance, and future upgrade ability. The practice of systems engineering has evolved to mitigate the risk associated with complex system development. Many resources exist for systems engineering. As you go through this module, I'd like to point you towards four in particular that can augment the material in this unit. First is the International Council on Systems Engineering, or INCOSE, Systems Engineering Handbook. Second is the Systems Engineering Body of Knowledge, SEBoK, at SEBoKwiki.org. This is an excellent reference site developed by INCOSE to broadly share systems engineering knowledge in a domain or problem independent way. The 2015 edition of the ISO/IEC/IEEE 15288 standard systems and software engineering, system life cycle processes, often referred to as 15288. Finally, the NASA Systems Engineering Handbook, updated in 2016, which provides an excellent view into how systems engineering principles are put into practice by an organization focused on designing and building highly complex systems. Using these resources, you will find that systems engineering is a mindset that results in an interdisciplinary perspective on how to design and manage complex systems over their life cycles. >> Well, model-based systems engineering, under that name, grew up about ten years ago and at that point, it was actually an effort to close the gap between systems and software engineering. As systems had more and more software content, we found that the communication gap was beginning to impair system development and system performance. In those early days, it was all about closing the system software gap. Over the last ten years INCOSE, the International Council on Systems Engineering, has progressively invested more time and more energy to move the community forward. What we see now is model-based systems engineering is much bigger. It's not about the software component, it's about the systems engineering component on all fronts. And perhaps the biggest change is model-based systems engineering is now becoming the linchpin to, you can call it model-based engineering, digital thread, digital tapestry, but really connecting to digital engineering so that we can better deliver capabilities to these complex problems we face. >> Let's start off our exploration of systems engineering with the question of, what is a system? In the 15288 standard, Section 5.2.1, systems are described as, quote, man-made, created, and utilized to provide products or services in defined environments for the benefit of users and other stakeholders. Appendix C of the INCOSE Systems Engineering Handbook, 4th edition, has defined a system as an integrated set of elements, sub-systems, or assemblies that accomplish a defined objective. These elements include products, hardware, software, firmware, processes, people, information, techniques, facilities, services and other support elements. These are definitions of systems in the, quote, real world, unquote, which need to be distinguished from representations and abstractions that represent concepts. Some other concepts around systems engineering are, a system boundary. A system boundary defines the scope of a system, creating a distinction between the system and the environment, or context, in which a system exists. The system architecture. A system architecture is defined as, quote, the fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution, unquote. A system is made up of individual elements. System elements can be either atomic, meaning they cannot be broken down further, or can be systems in their own right. Or they can be decomposable into further subsystem elements. As you explore systems engineering, you'll realize that a challenge exists. When have you sufficiently decomposed a system? This level can typically be determined when you can treat the element as a black box, where you do not need visibility into an element to understand it. Another way of thinking about this is, that if you can confidently make, buy, or reuse the item and there's no need for additional understanding, you have sufficiently decomposed the system. System elements are organized into a structure or hierarchy. A system hierarchy is defined in the 15288 standard as, the system life cycle processes are described in relation to a system that is composed of a set of interacting system elements, each of which can be implemented to fulfill its respective specified requirements. For very broad perspectives, a system of systems is also a hierarchy of elements. But the elements are independent, managerially and or operationally. Systems of systems can also be defined by when the integration of the independent systems gives results that otherwise usually are not possible.
