What is MBSE and Why is it needed?
Dr. Manpreet Singh
Senior Engineering Manager | Technical Authority at BAE Systems
In today’s multi-disciplinary, integrated, and multi-application development environment encourages users to adopt an agile practice under stringent project constraints whether cost, time or resource. The ever-changing Engineering landscape forces the implementation of Agility within the traditional engineering environments such as defence, aerospace, energy and automotive industries, where waterfall product development has been long practiced and perfected.
As these products are highly complex with high levels of interdependencies and interrelationships, following a build-based agile iteration is expensive. Moreover, these industries are stringently regulated and exceptionally quality-driven. Hence, agility should bear technologies that allow data-driven decisions, clarity, visibility, traceability, simplicity, and preferably automation to allow fast development without the loss of quality.
Complex product development necessitates inter-disciplinary and inter-supplier/company work. Therefore, users look for ways to be agile in this complex and dynamic environment. At the centre of this complexity lies the discipline of Systems Engineering.
INCOSE defines Systems Engineering as the “transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems, using systems principles and concepts, and scientific, technological, and management methods.”
The terminology of System has a wide-ranging definition incorporating hardware, software, information, processes, people, configurations, training, supply chain, regulators and geographies. One of the principal functions of Systems Engineering is to conduct IVV (Integration, Verification and Validation) of the product development and overall lifecycle management.
The figure above illustrates the lifecycle stages of a waterfall product development method. IVV is designed to follow the product development and the product itself in compliance with the requirements.
Integration asks “can the parts of the system work in harmony to meet the needs?”, Verification asks “are we building the product right?” and Validation asks “are we building the right product?”.
IVV helps minimize late defect discovery by engineering and manufacturing functions orchestrated by systems engineering. It has been proven time and time again that costs increase exponentially with issue discovery near the end. It is good to know about serious issues sooner, rather than later.
Conventionally, Systems Engineering follows a document-based approach. The biggest challenge with this approach is the inability to adapt to changes and complications with collaboration due to a large number of stakeholders and moving parts in the projects that overall slows down the product development process. A brief comparison above is given of the Information based characteristics for MBSE-based and Document-based approaches.
From the left hand side of the diagram above we can see the problems facing the conventional document-based approach. The conventional approach generally incorporates numerous meetings, sharing of documents, emails with attachments, spreadsheets, models and drawings passed on between stakeholders in a document-based systems engineering setting. Configuration control takes a back seat and the impact of not knowing how changes impact different aspects of the product development lead to drastic resource waste. This approach also has a high chance of defects being discovered near the end of the project.
Finally, industries are positioning themselves to transition to IoT/Industry 4.0 which brings about much more interconnectedness and interdependability between products. This inherently will lead to managing and controlling a lot more data – this increase size of data exasperates an already-complicated and burdened situation.
Project Managers know the complexity triangle very well whereby quality is managed by balancing the project scope, cost and time. Systems Engineers aid in alleviating this complexity within a project by bringing ‘modelling’ to replace documents. Model Based Systems Engineering (MBSE) is the conduit which correlates “behaviours”, “requirements” and “structures & relationships” illustrated by “models”. The model stated herewith correlates to an abstracted concept such as a phenomenon, relationship, structure, or system which be illustrated graphically, mathematically, or physically. The model encourages concepts to help in decision-making processes by describing the behaviours, transversals and simulating events. Models are low-fidelity system models, as opposed to high-fidelity engineering models such as CAD, FEA, CFD, etc.
领英推荐
INCOSE defines MBSE as “the formalized application of modelling support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases”.
Herewith, we will investigate the prime components of MBSE: namely, Requirements, Behaviours, People, Structure, Properties, and Interconnections.
Structures are made up of any information (data or metadata) that consist of non-static components within Systems Engineering. Traditionally, the starting point of any project, system, or change in products or systems is requirements – a specific, measurable, attainable, realistic and tangible description of the problem(s) that the system of interest should solve. Behaviour describes the relationships/interfaces between the structures or the components/parts within the structure as well. MBSE allows you to conduct low fidelity simulations to understand the dynamic behaviour of the model. These MBSE models are bounded by parameters based on functional and non-functional requirements. Requirements should give a comprehensive definition of the stakeholder goals, purposes, and success conditions for the system. Behaviours define the relationship between structures or the parts inside the structures. Behaviours also describe what the system must do to meet the requirements. People are in my opinion, one of the most important components within effective MBSE. People must know what structure, framework and process to adopt so that their knowledge and skill-set can be implemented effectively and efficiently. Modern day projects adopting MBSE are working in a highly multi-disciplinary environment in complex multi-stakeholder settings. Properties showcase the performance, physical characteristics and governing rules that constrain the structure and behaviour. Finally, the interconnections showcase the way the structural elements arrange and communicate to achieve the required behaviour under the given constraints.?
MBSE is often implemented using the Object Management Group (OMG) systems modelling language (SysML), a general-purpose graphical modelling language for specifying, analysing, designing, and verifying complex systems that include hardware, software, and other elements. Some of the benefits derived from using MBSE include:
Subsequently, we will briefly look at the process of implementing MBSE can be viewed as the following five inter-related activities.
Product definition incorporates requirements management, parameter management, function and system modelling, and decomposition of those elements into one or more multi-domain architecture(s) that provide a complete virtual product definition on which to base the digital twin.
Connected engineering consists of systems development coordinating the activities of electrical, networking, software, mechanical, electronics, and specialities such as system on chip designers to support cross-functional integration.
Product validation involves continuous engineering throughout the system development process and product lifecycle for design and performance optimization, multi-domain analysis, and multiple levels of virtual and physical testing to arrive at system verification and validation.
Quality engineering ensures that the design complies with all regulations and requirements from applicable industry standards, organisations, and government agencies. This continuous process monitors every design change throughout the development process and lifecycle to arrive at a safe, secure, and reliable solution.
Integrated program planning uses a digital thread to manage all the interconnected and dynamic activities and groups, keeps the digital twin and related models relevant to the process and provides a central repository for all data.
MBSE is much more than just a buzzword. It is an important application that allows us to develop, analyse, and test complex systems. We most importantly need MBSE because it provides a means to coordinate system design activity, satisfies stakeholder requirements and provides a significant return on investment.
One major myth associated with transitioning from document-based to model-based systems engineering is the role requirements have within the MBSE world. MBSE does not intrinsically remove requirements! It should be noted that I stated requirements and not requirement documentation. One of the main reasons for MBSE includes the ability to develop a clear, concise, complete and, consistent set of requirements that communicates the stakeholder expectations to the design team. During the product development lifecycle, MBSE enhances the ability to allocate and trace requirements as well as manage change.
It is not really a question of going from document-based to a model-based environment or methodology. Scope, requirements and design all need to be considered and documented. Therefore, the real change is the method and manner of documentation when transitioning from a document-based to an MBSE approach. Documenting allocation and traceability between levels of the system architecture for complex systems is almost impossible for today’s complex systems.