INCOSE/OMG MBSE Patterns Working Group

The MBSE Patterns Working Group (formerly the Pattern-Based Systems Engineering (PBSE) Challenge Team) is a component of the INCOSE/OMG Model-Based Systems Engineering (MBSE) Initiative (http://www.omgwiki.org/MBSE/doku.php ). The approved INCOSE Working Group Charter is a 2016 update of the original 2013 team INCOSE/OMG charter. The base INCOSE working group page for the MBSE Patterns Working Group is found here:http://www.incose.org/ChaptersGroups/WorkingGroups/transformational/mbse-patterns.

1. Purpose:

1.1. Conceptual Summary:

As used here, System Patterns are configurable, re-usable System Models that would otherwise be like those expected and found in the practice of MBSE (not limited to, but including, SysML models). Through the availability and use of System Patterns, the outcomes targeted by MBSE models are made more accessible, in terms of ease (and skill) of generation and use, associated modeling cost, schedule, risk, completeness, and consistency, etc. Over time, System Patterns become points of accumulation of organizational learning and expertise. Because they are configurable and re-usable models of families or classes of systems, model-based System Patterns involve some additional methods and disciplines that extend the ideas of MBSE (e.g., Pattern Management, Configuration Rules, model minimality, etc.).

This model-based PBSE approach has been in use for a number of years, applied across enterprises and domains that include mil/aerospace, communications, automotive, medical/health care, advanced manufacturing, consumer products, along with business processes including sales, engineering, production, and general innovation. The first INCOSE PBSE tutorial was provided at IS2005, another given at GLRC2012, another at IS2013, and another at GRLC2013. Attendees at the IS2013 tutorial expressed interest in an ongoing INCOSE PBSE group. A number of papers and tutorials on this approach have been published, some reproduced here.

1.2. Specific Challenge:

The PBSE Challenge Team will advance the availability of model-based System Patterns and related PBSE resources, and awareness of them, increasing the availability and successful use of System Models across the life cycle of systems. Specifically, this will be accomplished by meeting the following challenge:

Generating two or more MBSE models across multiple systems and system domains from single system pattern asset(s) leveraged across them. The specific domains and systems will be chosen based on the team membership’s priority interests, but are currently expected to include at least one multiple-configuration manufactured product line system, as well as the manufacturing system that produces it. This challenge will include quantification of the demonstrated economies or other gains obtained through pattern asset leverage, and the infrastructure (e.g., tools, processes) necessary to support those gains.

1.3. Form of Pattern-Based Systems Engineering (PBSE) Targeted by this Challenge Team

The term “pattern” appears repeatedly in the history of design, such as civil architecture[15], software design[16], and systems engineering[17]. Those “patterns” represent regularities that repeat, modulo some variable aspects, across different instances in space and time. However, in this project when we refer to “Patterns” and “PBSE”, we will mean the use of S*Patterns, and these have the following distinguishing characteristics.

S*Patterns are Model-Based, and that is why this Challenge Team is slotted into the MBSE Initiative. We are referring to patterns represented by formal system models. Among the historical “design patterns”, certain of these were based on descriptions that were not formal system models. Although they are always models, S*Patterns are not dependent on any single system modeling language, and are readily expressed in SysML, IDEF, or other formal modeling languages. Independent of the specific modeling language, S*Models always conform to the underlying S*Metamodel, which is the smallest model sufficient to the purposes of engineering and science.[8]

The S*Metamodel explicates Physical Interactions–state-impacting exchange of energy, force, mass, or information. Such interactions are the basis of substantially all the laws (patterns, regularities) of the physical sciences. Systems Engineering should have as strong a foundation as the other engineering disciplines, which are likewise based upon laws describing physical interactions.

The scope of S*Patterns are “Whole Systems“. An S*Pattern is effectively a formal model of a platform or product line system, or a whole system domain. Earlier examples of historical “design patterns” were frequently about smaller repeating component or subsystem patterns, used as deemed applicable, and in some cases provided detail mostly for the design part of the pattern. By contrast, the scope of S*Patterns includes system requirements, designs, and other S*Model information such as verification, failure analysis, etc.

S*Patterns are formally configurable, using automated algorithms, portable across numerous third-party COTS engineering tools and databases, to rapidly generate many specific system requirement/design configurations (including failure mode analyses) from desired platform or product family features.

2. Measures of Success

Targeted stakeholder and related measures of success are:

System Innovation / Development Teams: Enjoy the benefits of MBSE with lower per-project model-origination and refinement time, effort, skill load, and risk, by employing configured System Patterns as early draft models.

System Modelers: Extend the span of influence of skilled individual modelers by making their models effectively available, applicable, and impactful to more projects, systems, and products.

Product Line Managers, Platform Managers, Portfolio Managers: Improve the effectiveness of families-of-systems disciplines, measured in terms of economic leverage. System Verification Teams: Improve the performance of system verification planning and execution in high risk or complexity systems.

System Life Cycle Groups: Improve satisfaction with the early fit of systems to the learned needs of system life cycle communities, including manufacturing, distribution, end user, operations, and maintenance, over a broad range of issues that should not be re-discovered each generation (functionality, safety, many other aspects).

Tool Suppliers: Improve the ROI demonstrated by tools.

Enterprises: Improve organizational-level learning across individual people and projects, reducing occurrences of re-learning the same lessons and repeating the same mistakes.

3. Plan Overview / Description:

Phase 1: (Time period to be established)

1. Supplement start-up team membership with other interested team members, sharing and refining charter and gaining team buy-in to this plan.

2. Bring team membership to a common level of PBSE understanding, using PBSE Tutorials conducted in recent years at IS, GLRC, and chapter levels, including example System Pattern content.

3. Identify target products for near-term work by the team:

a. Target System Patterns b. Target System Pattern Applications c. Business Process Implications Model of PBSE d. Demonstration of PBSE support in Tools and Information Systems e. PBSE Tutorials f. Other target products

Phase 2: (Time period to be established)

4. Create and validate targeted Challenge Team products, prioritized from above Phase 3: (Time period to be established)

5. Make Challenge Team products available to INCOSE membership, extending benefits.

Leave a Reply

Your email address will not be published. Required fields are marked *