Pattern Based System Engineering

Developed by William Schindel.

Model Based System Engineering

William has developed a way to create engineering patterns from sets of related engineering models.

This image is a schematic of Model Based System Engineering]] (MBSE) . I need to add illustrations of the PBSE process.

Bill suggested that civil society would benefit from patterns of key systems.

Canvas 1 Layer 1 . It is important to remember that this is an underlying metamodel. Practical S*Models are represented using whatever modeling languages and tools may be of value. Stakeholder World Language The State of a system determines what behavior it will exhibit in future Interactions. The State of a system may be changed by those Interactions. State (available behaviors) (Functional) Interaction means the exchange of energy, force, mass, or information between system components, each of which plays a (Functional) Role in that Interaction. Functional Interaction (Interaction of systems) System A Feature is an aspect of the behavior or performance of a system that has stakeholder value, described in the concepts and terminology of that stakeholder, and serving as the basis of selection of systems or system capabilities by or on behalf of the Stakeholder. Features are parameterized by Feature Attributes, which have subjective stakeholder valuations. Feature A Stakeholder is an entity having a value stake in the behavior or performance of a system. Stakeholder An Interface is an association of a System (which has the Interface) with one or more Input- Outputs (which flow through the Interface), Interactions (which describe behavior at the Interface), and Systems of Access (which provide the medium of transport between Interfaces). Interface Input-Outputs are exchanges of energy, force, mass, or information between system components, during an Interaction. Input / Output A Design Component is described solely by its identity or existence, not its behavior; that behavior is described by the Functional Role(s) allocated to that Design Component. Design Components are parameterized by Design Component Attributes that have only identity or existential valuations, but no behavioral aspects. (physical system) Design Component attribute System of Access attribute attribute Requirements Statements are prose or other descriptions of the behavior of Functional Roles during Interactions. They are the prose descriptive equivalent to the Roles they describe, and are parameterized by Requirements Attributes which are identical to the related Role Attributes. Technical Requirement Statement High Level Design Detail Level Requirements High Level Requirements Technical World Language Functional Roles are described solely by their behavior, and parameterized by Role Attributes which have objective technical valuations. ( logical system ) Functional Role Interaction (Interaction) attribute Matrix A Couplings describe the quantitative value dependencies (parametric couplings) between Stakeholder Feature Attributes and Functional Role Attributes, quantifying fitness space or trade space. “A” Matrix Couplings Matrix B Couplings describe the quantitative value dependencies (parametric couplings) between Functional Role Attributes and Physical Design Component Attributes. “B” Matrix Couplings Stakeholder Requirement Statement attribute attribute Design Constraint Statement WB “BB” and “WB” mean “Black Box” and “White Box”. WB BB BB