This Model-Based Systems Engineering (MBSE) course and the Digital Thread courses featured earlier in this specialization bring together the concepts from across digital manufacturing and design, forming a vision in which the geometry of a product is just one way of describing it. MBSE is where the model resulting from the evolution of system requirements, design, analysis, verification and validation activities is the focus of design and manufacturing. Students will gain an understanding of systems engineering, the model-based approach to design and manufacturing, the Digital Twin, and a roadmap toward a model-based enterprise. Students will be able to explain the value and expectations of systems engineering and model-based systems engineering, and the underlying motivations and opportunities represented by a model-based enterprise. They will develop the knowledge necessary to perform a baseline assessment of an organization’s potential to leverage MBSE. Main concepts of this course will be delivered through lectures, readings, discussions and various videos. This is the eighth course in the Digital Manufacturing & Design Technology specialization that explores the many facets of manufacturing’s “Fourth Revolution,” aka Industry 4.0, and features a culminating project involving creation of a roadmap to achieve a self-established DMD-related professional goal. To learn more about the Digital Manufacturing and Design Technology specialization, please watch the overview video by copying and pasting the following link into your web browser: https://youtu.be/wETK1O9c-CA
Model-Based Definition (MBD)
Loading...
Do curso por University at Buffalo
MBSE: Model-Based Systems Engineering
49 ratings
University at Buffalo
49 ratings
Curso 8 de 9 em Specialization Digital Manufacturing & Design Technology
Na lição
Model-Based Systems Engineering
The purpose of this module is to explain Model-Based Systems Engineering (MBSE) and its applications. Upon completion, learners will be able to assess a process for MBSE opportunities and develop an argument for implementation. The learners will also be able to develop a strategy on how to implement applications of MBSE.
Conheça os instrutores
Ken EnglishDeputy Director
Sustainable Manufacturing and Advanced Robotic Technologies Community of Excellence
[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.
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
