Resources, Projects, References by Subject

Resources, Projects, References by Subject

Foundations and Paths to Stronger SEHow INCOSE and the systems community are visualizing and reaching out to the future. How the INCOSE MBSE Patterns Working Group is applying a stronger foundation based on the System Phenomenon and the history of patterns in the physical sciences and mathematics to enhance and transform the foundation capabilities of Systems Engineering.
MBSE_Transformation_Adoption_Pattern_Project
PBSE Introduction, Basic Subjects, Tutorials, Education
Strengthened Foundations of Systems Engineering and Systems Science
S*Patterns–IP Landscape
Paths to the Futures of Systems Engineering
Legacy_Product_Line_Pattern_Extraction_Project_with_PLE_WG
Model Communities Outreach
The Innovation PatternThe formal systems pattern reference framework that describes systems innovation in all its forms, configurable for planning and analyzing specific plans, situations, and roadmaps. A framework in which Systems Engineering (or any system life cycle management) of any method and organization referencing ISO15288 and the INCOSE SE Handbook, and the use of MBSE Patterns in particular, can be planned, organized, deployed, analyzed, and managed, and continuously advanced over time.
Agile_Systems_Engineering_Life_Cycle_Management_(ASELCM)_Discovery_Project_with_ASE_WG
Innovation_Collaboration_Ecology_Project_with_TIMLM_WG_and_PLE_WG
Patterns in the Public Square–Innovation in Regulated Domains
Augmented Intelligence in Systems Engineering
Systems Engineering as a Complex System
Credibility of Models–Trust in PatternsModels are increasingly used to support more critical and impactful decisions. Models are increasingly used by people or organizations other than those who authored them. Accordingly, trust in the credibility of models will only become more important to manage over time. What are the principles and practices for establishing, representing, communicating, and managing trust in models over their life cycles? How does the credibility of recurring patterns reduce the cost of establishing and maintaining that trust?
Model Wrapper, Model Characterization Pattern
Trusted Model Repository Pattern
Verification_&_Validation_of_Models_Project_with_ASME_Stds_Cmtee
Maps to Frameworks, Schema, ToolsThere a growing lists of architectural frameworks, reference architectures, ontologies, metamodels, and similar underlying semantic constructs, used as the basis for models of systems, automation tooling, product lines, and otherwise. Mapping the S*Metamodel to these provides an expanded means for understanding and using a given framework, schema, or tool. This includes making S*Models and S*Patterns tool agnostic, portable across modeling languages, and for supporting automated reasoning and more basic queries about models in different systems.
Mappings to Frameworks, Schema, and Tools
Semantic Technologies
Domain PatternsS*Patterns are about recurring things within some general or narrow environment, referred to as a domain. The following illustrates S*Patterns across different application domains.
General Land Vehicle Pattern
Oil Filter Product Line Pattern
Critical_Infrastructure_Protection_and_Recovery_Patterns_Project_with_CIPR_WG
Construction Equipment Patterns
Lawnmower Product Line Pattern
Health_Care_Domain_Patterns_Project_with_HC_WG
utilizing_mbse_patterns_to_accelerate_system_verification_v1.6.2.pdf
Embedded Intelligence (EI) Pattern
General Manufacturing Pattern
Interface Patterns
General Mechanical Bracket Pattern
SoS Patterns

INCOSE/OMG MBSE Patterns Working Group

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.