As a teacher of SysML and MBSE, I regularly have students, who are working engineers, ask, “How do I starting using MBSE?”. There is a perceived need for a template or pattern to follow. My usual answer is, “You already know how to do systems engineering in your organization. Simply apply the new techniques and tools we have taught to your current process.”

While this generally ends the discussion, it isn’t really a satisfactory answer. First, if their current process was good enough, they probably wouldn’t be in the class. It may be ambiguous or overly complicated, or it might relegate the systems engineering function to a subordinate status for administration and documentation.

Second, their current process rarely addresses the wide range of project types systems engineers engage in. The traditional, start-to-finish new system design and deployment process captured in the classic V-model is only one of many scenarios.

Intercax is not a proponent of a particular methodology. However, I will offer a few considerations and tactics to keep in mind for those engaged in applying MBSE within their organizations. In this and three additional blog posts to follow, I will describe these, with special emphasis on the transition from MBSE to MBE and the collaborative application of all the engineering software tools to the system development process.

Systems Engineering Scenarios-

Figure 1: SE Scenarios

In a previous blog, we pointed out that systems engineers work on many different kinds of projects, but that SE methodologies tend to deal with only one. To summarize that earlier discussion, illustrated in Figure 1, some of the common scenarios are:

• New System (Greenfields) Design – The classic process starts with a clean sheet. The SE develops a concept of operations and a top-down system architecture, decomposing it to detailed component design and testing, then integration and verification.
• IoT Integration – Increasingly, the SE is charged with combining off-the-shelf components into a network with higher-level functions. The bottom half of the V-model is truncated.
• Reverse Engineering – An existing system is subjected to modeling, both to document the deeper knowledge not recorded in the detailed design and test records and to develop in-house modeling expertise.
• Variant Evaluation – A system architecture already exists, but alternatives need to be evaluated for next-generation product design.
• Model-Based Acquisition – One organization specifies requirements and functionality, leaving it one or more others to propose a physical architecture to meet the first organization’s needs.
• Failure Analysis and Operations – To validate a design for safety, or to guide troubleshooting the system in the field, the relationships between function and structure must be modeled rigorously.

Choosing a Methodology

Given the range of scenarios above, it seems clear that no single approach meets all needs. In developing a methodology (or evaluating a methodology developed by others), there are some simple questions the SE should ask:

• Will this methodology support the task at hand? – Given the kind of project, we want an appropriate process with the right inputs and outputs. For pre-existing methodologies, we should also look at the kinds of technologies they were developed for. A software development approach may not have all the pieces a full system requires.
• Will this methodology support my organization’s needs? – Most organizations have some structure for major projects, e.g. a set of project requirements or a review schedule. The appropriate methodology addresses those needs.
• Does the methodology create non-value-added deliverables? – At the same time, methodologies that create artifacts to meet internal needs, but have no relevance to the larger organization can waste time and effort without benefit.
• Is the methodology easy to understand? – If the team members don’t understand the approach (or don’t all understand it the same way), the project bogs down. The benefits of a common approach are lost.
• Does the methodology allow for parallel effort? – Approaches with a strict sequential schedule and tight coupling between tasks create bottlenecks. Look for ways where all team members can contribute individually to a common model.
• Does the methodology support the transition of systems engineering into the larger engineering process? – Every project requires the interaction of multiple engineering software tools, and the tools involved are usually pre-determined, not chosen by the SE team or the methodology. An effective approach helps define the loci of transition from SE to domain engineering, and back again.

Next Steps

Parts 2, 3 and 4 will consider some of the implications of these questions at arriving at a practical MBE approach. In Part 2, we will look at the critical first steps of organizing the system model, and the issues that need to be addressed. In Part 3, we will offer a view of the MBE process that emphasizes the expansion of the engineering effort as the project proceeds. In Part 4, we come full circle to the six generic use cases for MBE and how expansion proceeds in each case. Our goal is not a universal methodology for MBSE/MBE. We stick to our original answer, however unsatisfactory, that each organization must adapt the model-based concept to their own needs and expectations. Our role is to offer some guidance to those engaged in this task.

Related posts:

• First Steps in Adopting MBE | Part 1 (this post)
• First Steps in Adopting MBE | Part 2
• First Steps in Adopting MBE | Part 3
• First Steps in Adopting MBE | Part 4

Tweet