mbse:patterns:patterns
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
mbse:patterns:patterns [2026/07/01 08:41] schindel |
mbse:patterns:patterns [2026/07/01 08:50] (current) schindel |
||
|---|---|---|---|
| Line 27: | Line 27: | ||
| 1.3. Form of Pattern-Based Systems Engineering (PBSE) Targeted by this Challenge Team | 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. | + | The term “pattern” appears repeatedly in the history of design, such as civil architecture, software design, and systems engineering. 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] | + | 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. |
| 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 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. | ||
| Line 60: | Line 60: | ||
| 3. Plan Overview / Description: | 3. Plan Overview / Description: | ||
| - | Phase 1: (Time period to be established) | + | Phase 1: (Challenge Team Year 1) |
| 1. Supplement start-up team membership with other interested team members, sharing and refining charter and gaining team buy-in to this plan. | 1. Supplement start-up team membership with other interested team members, sharing and refining charter and gaining team buy-in to this plan. | ||
| Line 75: | Line 75: | ||
| f. Other target products | f. Other target products | ||
| - | Phase 2: (Time period to be established) | + | Phase 2: (Challenge Team Years 2-3) |
| 4. Create and validate targeted Challenge Team products, prioritized from above | 4. Create and validate targeted Challenge Team products, prioritized from above | ||
| - | Phase 3: (Time period to be established) | + | |
| + | Phase 3: (Conversion of Challenge Team to INCOSE Working Group, Year 3) | ||
| 5. Make Challenge Team products available to INCOSE membership, extending benefits. | 5. Make Challenge Team products available to INCOSE membership, extending benefits. | ||
mbse/patterns/patterns.1782909671.txt.gz · Last modified: 2026/07/01 08:41 by schindel
Page Tools
