As we continue in this course about Model Based Systems Engineering, (MBSE) and the digital thread, we now focus on the concept of a Model-Based Enterprise. In the first two modules of the course, Systems Engineering and Model-Based Systems Engineering, the scope was limited to individual product life cycles. In this module, that scope will be expanded to understand the vision for Model-Based Enterprise or (MBE) including potential benefits, and barriers to successful implementation. At the end of the module, you'll be able to identify potential opportunities for the adoption of a Model-Based Enterprise. In the first lesson, we will focus on the definition of a Model-Based Enterprise. At the end of this lesson, you'll be able to identify at least four components of a typical Model-Based Enterprise or (MBE). As we consider the Model-Based Enterprise, we can use this formal definition provided by the Digital Manufacturing and Design Innovation Institute or (DMDII). A Model-Based Enterprise is an integrated and collaborative environment, founded on a Model-Based Definition that is shared across the enterprise, enabling rapid, seamless, and affordable deployment of products from concept to disposal. A product or systems life cycle goes through concept, definition, materials and manufacturing, use and service, and end of life. The model goes through this entire life cycle. We often focus on the visual representation of the product via either a 2D CAD or 3D CAD representation. This representation is simply the geometry and assembly of different components. The best way to approach this is by analogy. If we will go back to mechanical engineering, as they made the transition from drafting to CAD and we constrain ourselves to only thinking about geometry. Then the information model that underpins CAD, is really points and vectors. Now, we visualize that with three primary orthogonal views, top, front and side and as we became more sophisticated, we got to solid modeling and we can rotate. And we can bring in materials, and we can bring in all those all those concepts. Keep that as the anchor analogy. And then think, when I'm engineering a system, what am I really concerned with. In our language, you're concerned with requirements, statements of need. You're concerned with functions or activities. Logically, how am I going to meet those without thinking of the exact technology. Components – what are the physical pieces and how are they going to interconnect? Tests and activities. But you're also thinking of things along the engineering journey. What are the risks? What are the issues? What are the concerns? What are the programmatic? All of these concepts are not new. All of these concepts are what we use to engineer systems today. The difference in model-based is we're simply being crisp about. We're putting a language to it so you and I agree upon what we mean when we use the word requirement. What we mean when we use the word activity, and what we mean when we say that a requirement is satisfied by an activity. If we can understand that and then go back to the analogy of, in CAD, it's all about points and vectors. In systems engineering, it's all about this abstract metal model that is buried deep at the heart of a tool. We don't have to worry about that. We have to let our tools help us through eliciting the right knowledge and representing it the right way. And again, we focus on the systems engineering. But, this whole focus on the knowledge capture and management. When defining a product, there are additional specifications that can be annotated to this geometric representation. These specifications include product manufacturing information, geometric dimensioning and tolerancing, metadata, design intent, different bills of materials or BOM's, materials etc. At the initial development phase, we're looking at concept and definition. During refinement, we're actually producing and then using a product throughout its life. This Model-Based Definition lives digitally along with the product, providing opportunities to augment the geometry with information that supports procurement and supply chain operations, through service and end of life support. A Model-Based Enterprise is the environment in which Model-Based Definition is the primary product definition or design authority. We can think of it as the single source of truth or singularity of product design information. This is not just switching from 2D design to 3D drawings, but to truly reap the benefits of Model-Based Enterprise, the environment must be optimized to use the model as much as possible throughout the enterprise including the supply chain during the entire product life cycle. A single source of truth is one of those heavily used terms in Model-Based Systems Engineering. If we go back and we say that, actually the closest thing to a model actually exists in the head of the engineer. What you're trying to do is to align the metal models of all of the participants on the team, and that's how we get to share cognition. Now, we can't actually deal with that, so, therefore, we have to represent that knowledge, that information in various ways. Classically, that was done in documents. And so, the difference between the previous state where we had multiple documents, and so-called single source of truth in Model-Based Systems Engineering is we're trying to get to one connected data source database, if you call it, if you wish to call it, that represents all of the information of interest. Not only about the system itself, but the engineering journey that brought you to that system. Because the rationale for why you made a decision, the alternatives that you considered, those are critical through the life of the system as it continues to evolve and be supported in the field. So, in Model-Based Systems Engineering, one of the objectives is to get that single source of truth, all the information at a system level in a single repository where it's complete, it's consistent, it's integrated. Everybody can find what they need and the knowledge is managed for the organization and the project. Earlier design paradigms use drawings to communicate requirements of components and systems.A rich language, otherwise known as GD&T, has developed around creating an abstraction of information that can be embedded into the manual drawings to share non-geometric design information. Entire reference books over a thousand pages of specifications have developed on a practice of Geometric Dimensioning and Tolerancing providing those additional pieces of information on a drawing. The digital manufacturing and design paradigm instead, uses computer-based technologies – to build the (MBE) systems architecture with linkages between Product Data Management or (PDM), Product Lifecycle Management or (PLM), Manufacturing Process Management known as (MPM), Manufacturing Execution Systems (MES) and Enterprise Resource Planning or (ERP). In the ideal state, the model represents a single source of truth, with appropriate information presented to different users or subsystems of the MBE architecture at the right time. The evolution to a digital design has led to the use initially of 3D annotated models which have become a part of the Technical Data Package or (TDP). This enables design engineers to formalize the design intent using geometry as well as annotations regarding specifications, dimensions, tolerances, and materials.
