Usually when organizations first adopt the MBSE approach, the focus is on a particular System, usually in the scope of PoC or feasibility study. This System is sometimes a Component or a Subsystem from a standpoint of a much more complex Product. Ultimately, when MBSE scope and maturity reaches a certain level, the question of Configuration and Consolidation has to be addressed.
If the Product is very complex (e.g. ground or aerospace vehicle), having a Consolidated Architectural view (fully consistent Structural and Behavioral views, precise Interface definitions, etc.) on the Product level (e.g. to enable executing the complete architecture) proves very difficult (if not impossible), unviable, very expensive and time consuming.
Referencing practical MBSE projects, a suggestion is to define a Consolidated Architectural definition strictly focused on Elements of Importance that would serve as an integration-aid and constraints to existing and future System Projects that require MBSE based on their complexity.
Some Systems (Functions), (sub)Systems are usually not sufficiently complex and don‘t spawn „their own“ MBSE Projects and are defines as contextual Black Boxes in your Consolidated Architecture.
The most likely scenarios are:
- MBSE Project spawns from a Black-Box element already in the Architectural Definition.
- MBSE Project spawns for a System not in the Architectural Definition and later has to be added (consolidated).
In scenario a) the existing Black-Box definition serves as a Design Constraint with existing information (e.g. Interfaces) coming from Consolidated Architecture. In scenario b) the Consolidated Architecture provides a Context for the new System, which is ultimately added to it. In both scenarios, the methodological process can be iterative.
From a technical (tool) standpoint, there are two main approaches:
- Cross-Project Refactoring
- Cross-Role Communication and Collaboration
In approach a) the Elements are moved between Projects. In approach b) roles communicate to add specific information to corresponding projects. Usually, an intermediate Project is used for review and approval before transferring to the Architectural Consolidation for the next Maturity Release.
Whichever is picked has much to do with potential security concerns in respect with Organization‘s Role and Permission model. Communication model also plays a big part here. Approaches a) and b) are also sometimes combined.
Tip. Keep the Layer number in the Configuration as low as possible. 4 is a sensible limit. Any more will make your Configuration very difficult to manage both technically and time-wise. Examples for top-layer Projects are Profiles (SysML extensions) and Libraries. Layer 2 could be the Architectural Consolidation. Layer 3 could then be System Projects. Layer 4 could be detailed Architectural Solution-Level models and the transitional point to Model Based Design. This is based on a simplified methodological approach which needs to be refined.
This is just an introduction and awareness-hint to a complex topic in MBSE that you could face in your MBSE journey.
If you or your Clients already face this challenge, a workshop with CATIA No Magic should be considered. Based on experience, individual solutions differ quite substantially due to specific Processes and Methods. Our expertise could aid in finding a consistent solution quicker and with less trial-and-error.
