Most MBSE methodologies place emphasis on organizing the model correctly before actually modeling the system, but this task should not be approached too narrowly. First, as we discussed in a previous blog, modeling should encompass both the system under development and the project structure, which includes both process and organization. Model organization should facilitate collaboration between team members, allowing them to work in parallel without getting in each other’s way.
Second, to the extent that MBSE methodologies are system-architecture-centric (e.g. SysML-centric), they may neglect the interplay between the many engineering software tools used in system development. Model organization in an MBE environment (Model-Based Engineering) must include an interoperability strategy because system data resides in many different tools and repositories.
In this blog, we shall look at both aspects in more detail, with a philosophy that Methodology drives model organization; Re-use drives model content.
Figure 1 Organize MBE Model activity diagram
Methodology Drives Model Organization
In Figure 1, we try to capture both aspects of the model set-up stage of system development. On the right-hand side are the methodology/organization tasks. We have illustrated these with an example from the IoT space in a previous blog and technote, but in summary, these are:
- Manage Project Requirements – Many organizations start from a complete library of project requirements, and select those relevant to a specific project.
- Model Organization – Modeling the organizational structure makes it easier to allocate the system development tasks to the correct team members.
- Model Project Flow – The methodology or process flow is driven by the project requirements applied to a specific organization.
- Model Work Breakdown Structure – The methodology applied to a specific project determines tasks and milestones.
- Connect Project Management Tools – The WBS captured in b4 is deployed in a variety of external project management tools to track status, manpower, cost and schedule.
Note that several of these steps may employ external tools besides the system architecture modeling tool. For example, the project requirements may be managed in a requirements management tool, the organization manpower stored in a database, and the project management status in an issue tracking tool. The parallel effort described in the next section deals with how to make this happen.
Re-use Drives Model Content
The left side of Figure 1 deals with the content of the model. In an MBE environment, this means both the content of the system architecture model and the content in all the external tools (PLM, ALM, CAD, etc.) relevant to the system. It means deciding both what existing content should be included and how content should be managed going forward.
- Re-use SysML Elements – The appropriate libraries, profiles and plug-ins are incorporated into the system architecture model.
- Re-use External Product Data – Design files, code and bills of materials that can be re-used, with or without modification, is identified in the PLM/ALM/CAD repositories.
- Assign Data Ownership – The interoperability strategy starts with deciding where the master copy of each dataset resides, who is responsible for it, and whether a “link or synch” strategy will connect it within the Total System Model (TSM).
- Define Engineering Change Process – The interoperability strategy continues with specifying how information may be changed across the tool boundaries as the system model evolves.
- Identify MBE Platform – Based on decisions in a3 and a4, the software needed to create, use and visualize the TSM can be selected. Syndeia from Intercax is an example of such a platform.
As we have seen, the process of organizing an MBE project is complex even before the actual system modeling begins. An expansive approach to setting up an environment for effective collaboration is appropriate. In Part 3, we offer a similarly expansive approach to the actual modeling effort, as more participants and tools are incrementally added to building the TSM.