Where Do Systems Come From, and Where Do They Go?

Transcription

1 Where Do s Come From, and Where Do They Go? S*s in Model-Based s Engineering: Emergence of Purpose, Fitness, Value, Resilience ISSS2016 Plenary VIII Panel: Prospects for Scientific ic Synthesis Bill Schindel schindel@ictt.com

2 Contents Introduction: Sources of this Perspective 1. The S*Metamodel, in Evolving s Engineering Practice 2. Interactions and The Phenomenon 3. Emergence of Value, Fitness, Purpose, and Resilience in an Ecology of Interactions 4. of Innovation 5. Where s Come From and Go: Trajectories in S*Space 6. Science-based s for Socio-technical s Conclusions and Invitation to Collaboration References 2

3 A Engineer s Viewpoint: 40+ years in engineered systems, founding multiple systems businesses. Aero, Telecom, Automotive, Health Care, Consumer Products, Advanced Manufacturing, Education, all manner of technologies, including living systems. Last twenty years providing systems engineering assistance to Fortune 100 companies, pioneering & introducing -Based s Engineering Methodology, based on S*Metamodel, and recognizing engineering as a social enterprise. Many S*s across many domains, informed by existing or emerging sciences. INCOSE (International Council on s Engineering): Co-chair of INCOSE MBSE s Working Group. Member, INCOSE Agile s Discovery Project lead team. INCOSE MBSE Transformation Lead Team. INCOSE Chapter President, Crossroads of America. ISSS-INCOSE Connections and MOU: Through INCOSE Science Working Group (SSWG), met David Rousseau, John Kineman, Len Troncale, Jennifer Wilby. Member of a SSWG MBSE s Project, inspired by Len Troncale. Academics: Applied Mathematics background in engineering contexts. SOURCES OF THIS PERSPECTIVE Short early stint as a young tenured faculty member, math & engineering, before businesses. Just wrapped up 30+ years as trustee, including board academic affairs committee chair, twice chairing successful presidential searches. ASEE series on teaching systems competencies for all engineering undergraduates. 3

4 1. A Phase Change in s Engineering A change of paradigm, to a model-based foundation: Even the INCOSE Board of Directors has recognized as a strategic objective. The traditional engineering disciplines (ME, ChE, CE, etc.) were closer to such a model-basis when they originated as applications of physical sciences, but SE originated in a different way. And, the 10,000 member INCOSE community is not all doing the same systems engineering! Includes pre-modeling, traditional SE methods of ~50 yrs SE based on use of explicit system models (~10 yrs+) MBSE based on S*Metamodel (~20 yrs+) SE based on configurable, reusable system models (~20 yrs+) SE (Most practitioners) (s Engineering) MBSE (Most growth) (Model-Based s Engineering) MBSE by S*Methodology (Using S*Metamodel) PBSE (S*-Based s Engineering) 4

5 The S*Metamodel in s Engineering Until recently, unlike the other, science-based engineering disciplines, what many SEs considered the foundation of MBSE system models was: not based on natural phenomena from science,... but instead the underlying data models of modeling languages & toolsets (perspective contributed by IT world), which is not the same as underlying model of the world they describe. Today, still trailing the burden of some of that history, versus a stronger foundation. Not a good basis for a science-based engineering discipline! Still in flux, but now starting to return to traditional science-based roots in nature and mathematics, and strengthening model-based foundations. The S*Metamodel figures into that foundation, as follows... 5

6 Stakeholder World Language Stakeholder Requirement Statement Stakeholder S* Hierarchy for -Based s Engineering (PBSE) S*Metamodel for Model-Based s Engineering (MBSE) High Level Interaction (Interaction) State Interface of Access Configure, Improve Specialize General Product Lines or Families Technical World Language Detail Level High Level WB BB Technical Requirement Statement Constraint Statement (logical system) (physical system) A Coupling B Coupling Input/ Output Class Every S*Metaclass shown is embedded in both a containment hierarchy and an abstraction (class) hierarchy. Individual Product or Configurations Class Hierarchy Explicit S*s vs. Informal or Dark s PBSE: -Based s Engineering MBSE: Model-Based s Engineering Containment Hierarchy Metamodel: An underlying relational framework, model of models. S* covers the smallest model framework necessary for engineering & science purposes. S*Models are system models that conform to the S*Metamodel. S* is agnostic as to modeling language (e.g., SysML, UML, OPM, etc.) and modeling tools (can be used with potentially any of them, through profiling, and have mapped into many). Above is an informal summary of key subset; the formal S*Metamodel is described in UML. 6

7 Extracts from Terrestrial Vehicle S* 7

8 S* Hierarchy for -Based s Engineering (PBSE) Improve Configure, Specialize General Product Lines or Families S*Metamodel for Model-Based s Engineering (MBSE) Stakeholder Stakeholder World Requirement Language Statement High Level Technical World Language BB Technical Detail Level Requirement WB Statement High Level Constraint Statement Stakeholder Interaction State (Interaction) Interface A Coupling Input/ Output (logical system) (physical system) B Coupling of Access Class Every S*Metaclass shown is embedded in both a containment hierarchy and an abstraction (class) hierarchy. S* construction and use over several decades, many domains, technologies, multiple INCOSE WGs. Individual Product or Configurations Class Hierarchy Containment Hierarchy Medical Devices s Manufacturing Process s Embedded Intelligence s Product Service s Life Cycle s Agile s Engineering Life Cycle Construction Equipment s Commercial Vehicle s Space Tourism Vision s Packaging s s Lawnmower Product Line s of Innovation (SOI) Multiple Consumer Orbital Satellite Products s Product Distribution s Production Material Handling s Transmission s Plant Operations & Maintenance s Engine Controls s Precision Parts Production, Sales, and Engineering Oil Filter Military Radio s Higher Education Experiential Commercially applied across wide range of domains and technologies for 20+ years. Used by INCOSE MBSE s Working Group and its joint projects with other INCOSE 8 WGs, including Agile s WG, Product Line Engineering WG, & of s WG.

9 Two entirely different hierarchies are involved: Generalization Hierarchy Containment Hierarchy More General S* Hierarchy for -Based s Engineering (PBSE) S*Metamodel for Model-Based s Engineering (MBSE) Stakeholder World Language High Level Stakeholder Requirement Statement Stakeholder Interaction (Interaction) State Interface of Access Configure, Improve Specialize General Product Lines or Families Technical World Language Detail Level High Level BB Technical Requirement WB Statement Constraint Statement (logical system) (physical system) A Coupling B Coupling Input/ Output Class Every S*Metaclass shown is embedded in both a containment hierarchy and an abstraction (class) hierarchy. Individual Product or Configurations Class Hierarchy Whole More Specific Containment Hierarchy Part 9

10 Stakeholder World Language Stakeholder Requirement Statement Stakeholder S* Hierarchy for -Based s Engineering (PBSE) S*Metamodel for Model-Based s Engineering (MBSE) High Level Interaction (Interaction) State Interface of Access Configure, Improve Specialize General Product Lines or Families Technical World Language Detail Level High Level WB BB Technical Requirement Statement Constraint Statement (logical system) (physical system) A Coupling B Coupling Input/ Output Class Every S*Metaclass shown is embedded in both a containment hierarchy and an abstraction (class) hierarchy. Individual Product or Configurations Class Hierarchy Interaction (Interaction) Containment Hierarchy s: Model system Purpose, Value, Fitness, from the perspective (often subjective, conflicting) of Stakeholders. State Interactions: Model (state dependent) objective technical behavior, as physical exchanges of energy, of force, mass, 10 Interface information, Access resulting in change of state.

11 2. Interactions and the s Phenomenon s engineering has passed through a different path than the other engineering disciplines which were better connected to underlying phenomenabased physical sciences... 11

12 Phenomena-Based Engineering Disciplines The traditional engineering disciplines have their technical bases and quantitative foundations in the hard sciences: Engineering Discipline Mechanical Engineering Chemical Engineering Electrical Engineering Civil Engineering Phenomena Scientific Basis Representative Scientific Laws Mechanical Phenomena Chemical Phenomena Electromagnetic Phenomena Physics, Mechanics, Mathematics,... Chemistry, Mathematics.... Electromagnetic Theory Newton s Laws Periodic Table Maxwell s Equations, etc. Structural Phenomena Materials Science,... Hooke s Law, etc. 12

13 The Traditional Perspective Specialists in individual engineering disciplines (ME, EE, CE, ChE, etc.) sometimes argue that their fields are based on: real physical phenomena, physical laws based in the hard sciences, and first principles, sometimes claiming that s Engineering lacks the equivalent phenomena based theoretical foundation. Instead, s Engineering is sometimes viewed as: Emphasizing process and procedure Critical thinking and good writing skills Organizing and accounting for information But not based on an underlying hard science and phenomena. 13

14 The Phenomenon In the perspective described here, by system we mean a collection of interacting components: Causes behavior during External Actors State Interaction Causes changes in Where interaction involves the exchange of energy, force, mass, or information,... Through which one component impacts the state of another component,... And in which the state of a component impacts its behavior in future interactions. 14

15 The Phenomenon Phenomena of the hard sciences are in each case instances of the following Phenomenon : behavior emergent from the interaction of behaviors (phenomena themselves) a level of decomposition lower. In each such case, the emergent interaction-based behavior of the larger system is a stationary path of the action integral: External Actors Reduced to simplest forms, the resulting equations of motion (or if not solvable, empirically observed paths) provide physical laws subject to scientific verification. 15

16 The Phenomenon Instead of s Engineering lacking the kind of theoretical foundation that the hard sciences bring to other engineering disciplines,... It turns out that all those other engineering disciplines foundations are themselves dependent upon the Phenomenon. The underlying math and science of systems provides the theoretical basis already used by all the hard sciences and their respective engineering disciplines. Examples: Chemistry, arising out of electron & other interactions The gas laws, arising out of particle & other interactions 16

17 The Phenomenon A traditional view: s Engineering s Engineering Traditional Engineering Disciplines Traditional Engineering Disciplines Traditional Physical Phenomena Our view: Emerging Engineering Disciplines Emerging Engineering Disciplines Traditional Engineering Disciplines Traditional Engineering s Disciplines Engineering Discipline s Engineering Discipline The Phenomenon Traditional Physical Phenomena (a) Not the perspective of this paper, but a common view (a) Not the perspective of this paper, but a common view The Phenomenon (b) The perspective argued by this paper (b) The perspective argued by this paper It is not s Engineering that lacks its own foundation instead, it provides what has been viewed as the foundation for the other disciplines! 17

18 3. Emergence of Purpose, Value, Fitness in an Ecology of Interactions Fitness, Value, Innovation, in S* Space Performance Interaction Selection (or De-Selection) Interaction 18

19 S*s Emphasize Complete Stakeholder- Models s: Model system Purpose, Value, Fitness, from the perspective (often subjective, conflicting) of Stakeholders. Scope of S*Model includes all system stakeholders, and therefore all the values / fitness measures of all of them even when they conflict. Space is the scoreboard for all decisions, actions, judgements concerning the subject system--including ethical and other aspects. What systems engineers call trade space, model of value conflicts. S*s: s express selectable options/partitions, configuring system based on capabilities, challenges, situations. s form the basis of system selection, and are formed by it. s also express all risks the only risks are stakeholder risks. And, s also express all the (negative) Effects, of MBSE version of Failure Modes, Effects, and Criticality Analysis (FEMCA), risk analysis. 19

20 4. The of Innovation (SOI) : This pattern models Innovation itself, not just the innovated thing and it is highly non-linear, iterated, & exploratory. Includes Purpose- Discovery Loop Pivoting is not just for entrepreneurs. 20

21 The of Innovation (SOI) : Feedback Signaling Path in Logical Architecture Similar to Formal Cause Similar to Final Cause Similar to Efficient Cause Similar to Material Cause 21

22

23 Learning & Knowledge Manager for LC Managers of Target (substantially all ISO15288 processes) Project Portfolio Infrastructure Life Cycle Model Human Resource Quality Knowledge Process Acquisition Supply Life Cycle Manager of LC Managers (substantially all ISO15288 processes) Stakeholder Needs, : Top Business, Mission Analysis Architecture Verification (by Analysis & Simulation) Validation Stakeholder Needs, Analysis : Subsystem 3 Learning & Knowledge Manager for Target s (and s) (substantially all ISO15288 processes) Project Planning Risk : Subsystem 2 : Subsystem 1 Business, Mission Analysis Architecture Verification (by Analysis & Simulation) Validation Analysis Project Assessment and Control Configuration Level, Acquisition, Fabrication Implementation Decision Verification (by Test) Information Verification (by Test) LC Manager of Target (and s) (substantially all ISO15288 processes) Realization: Top Realization: Subsystem 3 Realization: Subsystem 2 Realization: Subsystem 1 Integration Quality Assurance Process Measurement Integration Solution Validation Solution Validation Operation Service Life Transition Disposal Maintenance Target Environment More General Universal systems nomenclature, domain-independent. Emergence of s from s: S* Class Hierarchy of Relational Modeling Paradigm Entity- Relationship Paradigm E R E=Entity R= Relationship Minimal S*Metamodel: of (Elementary), Material Cause Emergence & of of Innovation, Fitness, Value, Purpose, Stakeholders, Agility, Final Cause, Formal Cause, Efficient Cause, Intelligence,, Science, Living s S*Metamodel Core EI, SOI, Fitness, Value S*Purpose, Fitness, Value of Innovation 3. of Innovation (SOI) Organizational Project-Enabling Processes Agreement Processes Core S*Metamodel 2. Target (and ) Life Cycle Domain of Innovation (SOI) Logical Architecture (Adapted from ISO/IEC 15288:2015) Project Processes Technical Processes 1. Target Agile Sys Life Cycle ISO Life Cycle Mgmt More Specific Emergence & of Domain Specific s Domain Specific Terrestrial Vehicle Domain Aircraft Flight Control Manufacturing Medical Device Product Service Distribution Space Tourism Socio-Technical Domain-specific languages, frameworks, ontologies. Generator of new systems ; also maintainer, destroyer

24 ISO15288 and INCOSE SE Handbook describe a framework of ~32 roles of system Life Cycle (LC). of Innovation (SOI) Logical Architecture Organizational Project-Enabling Processes Project Portfolio Infrastructure Life Cycle Model Human Resource Quality Knowledge Process Agreement Processes Acquisition Supply Stakeholder Needs, (Adapted from ISO/IEC 15288:2015) : Top Business, Mission Analysis Architecture Verification (by Analysis & Simulation) Validation Stakeholder Needs, Analysis Project Planning Risk : Subsystem 3 : Subsystem 2 : Subsystem 1 Business, Mission Analysis Architecture Verification (by Analysis & Simulation) Validation Analysis Project Processes Project Assessment and Control Configuration Technical Processes Level, Acquisition, Fabrication Decision Information Realization: Top Realization: Subsystem 3 Realization: Subsystem 2 Realization: Subsystem 1 Verification (by Test) Verification (by Test) Integration Quality Assurance Process Measurement Integration Solution Validation Solution Validation Service Life: Top Operation Transition Disposal Maintenance Implementation 3. of Innovation (SOI) Learning & Knowledge Manager for LC Managers of Target Life Cycle Manager of LC Managers 2. Target (and ) Life Cycle Domain Learning & Knowledge Manager for Target s (Substantially all the ISO15288 processes are included in all four Manager roles) LC Manager of Target 1. Target Target Environment They appear repeatedly, in different ways in the SOI & ASELCM s

25 INCOSE Agile Life Cycle : Application of of Innovation (SOI) A complex adaptive system reference model for system innovation, adaptation, sustainment, retirement. Whether 100% human-performed or automation aided. Whether performed with agility or not, compliant or not, informal, scrum Whether performed well or poorly. Includes representation of pro-active, anticipatory systems. 3. of Innovation (SOI) Learning & Knowledge Manager for LC Managers of Target Life Cycle Manager of LC Managers 2. Target (and ) Life Cycle Domain Learning & Knowledge Manager for Target s LC Manager of Target 1. Target 24 (Substantially all the ISO15288 processes are included in all four Manager roles) Target Environment

26 3. of Innovation (SOI) Learning & Knowledge Manager for LC Managers of Target Life Cycle Manager of LC Managers 2. Target (and ) Life Cycle Domain Learning & Knowledge Manager for Target s LC Manager of Target 1. Target (Substantially all the ISO15288 processes are included in all four Manager roles) Target Environment 1: Target system of interest, to be engineered or improved. 2: The environment of (interacting with) S1, including all the life cycle management systems of S1, including learning about S1. 3: The life cycle management systems for S2, including learning about S2. Most of the challenges discussed this week in ISSS sessions are 2 and 3 problems, not 1 problems. 25

27 5. Where Do s Come From and Go? Life Cycle Trajectories in S*Space Configurations change over life cycles, during development and subsequently Trajectories (configuration paths) in S*Space Effective tracking of trajectories History of dynamical paths in science and math Differential path representation: compression, equations of motion 26

28 Maps vs. Itineraries -- SE Information vs. SE Process The SE Process consumes and produces information. But, SE historically emphasizes process over information. (Evidence: Ink & effort spent describing standard process versus standard information.) Ever happen?-- Junior staff completes all the process steps, all the boxes are checked, but outcome is not okay. Recent discoveries about ancient navigators: Maps vs. Itineraries. The geometrization of Algebra and Function spaces (Descartes, Hilbert) Knowing where you really are, not just what step you are doing. Knowing where you are really going, not just what step you are doing next. Distance metrics, inner products, projections in system configuration S*Space. 27

29 Maps vs. Itineraries -- SE Information vs. SE Process Project Portfolio Infrastructure Life Cycle Model Human Resource Quality Knowledge Process Acquisition Supply : Top Business, Mission Analysis Stakeholder Needs, Validation Architecture Verification (by Analysis & Simulation) Analysis Project Planning Risk : Subsystem 3 : Subsystem 2 : Subsystem 1 Business, Mission Analysis Stakeholder Needs, Validation Architecture Verification (by Analysis & Simulation) Analysis Project Assessment and Control Configuration Level, Acquisition, Fabrication Implementation Decision Information Realization: Top Realization: Subsystem 3 Realization: Subsystem 2 Realization: Subsystem 1 Verification (by Test) Verification (by Test) Integration Quality Assurance Process Measurement Integration Solution Validation Solution Validation Service Life: Top Operation Transition Disposal Maintenance of Innovation (SOI) Logical Architecture (Adapted from ISO/IEC 15288:2015) Project Processes Organizational Project-Enabling Processes Technical Processes Agreement Processes Model-based s in S*Space. Interactions as the basis of all laws of physical sciences. Relationships, not procedures, are the fruits of science used by engineers: Newton s laws, Maxwell s Equations. Immediate connection to Agility: knowing where you are--starting with better definition of what where means. There is a minimal genome (S*Metamodel) that provides a practical way to capture, record, and understand the smallest model of a system. Not giving up process: MBSE/PBSE version of ISO/IEC

30 Simple Geometric/Mathematical Idea: Subspace Projections 29

31 Life Cycle Trajectories in S*Space, and S*Subspaces Stakeholder Subspace Sub-subspaces Summary of S*Metamodel Defines Configuration Space High Level Detail Level Stakeholder World Language Technical World Language WB Stakeholder Requirement Statement BB Technical Requirement Statement Stakeholder Interaction (Interaction) (logical system) A Coupling State Interface Input/ Output of Access Technical Behavior Subspace Continuous Subspace A Coupling Discrete Subspace High Level Constraint Statement (physical system) B Coupling Physical Architecture Subspace Configuration Space (S*Space) Sub-subspaces 30

32 Agility as Optimal Trajectory Control in S*Space: Finding the Best Next Increment Direction Stakeholder Subspace 2. Target (and ) Life Cycle Domain Learning & Knowledge Manager for Target s Repository, Knowledge of Families of: Target Target Life Cycle Domain Actor Target Provides Observations to Provides Knowledge to LC Manager of Target Configured Models Repository, Configured Instances of: Target Target Life Cycle Domain Actor Target Observes Observes Manages Life Cycle of 1. Target Target Target Target Life Cycle Domain Actor Optimal Control Coupling S1 Attribute S1 Attribute S1 Attribute S2 (Actor) Attribute S2 (Actor) Attribute S2 (Actor) Attribute LC Manager Attribute LC Manager Attribute LC Manager Attribute Invisible Hand Visible Hand Clumsy Hand Optimal Hand Balanced Hand Technical Behavior Subspace Physical Architecture Subspace Configuration Subspace for Target Current Confguration Trajectory Options Next Increment Series of Configurations, Along (Possibly Agile) Trajectory Backlog Item 31

33 Recent Generations of Science & Engineering (s) 6. Progressively larger scale patterns support larger-scale system sciences and emerging engineering disciplines including very real higher-level entities, emergent parametrics, forces, states, energies, etc. Current Challenges Inviting Future Science & Engineering 32

34 Conclusions and Invitation 1. Across decades of use over diverse domains, the S*Metamodel has been shown capable of compactly representing minimal S*Models sufficient for the purposes of systems engineering in particular, in reusable configurable S*s. 2. The Phenomenon re-connects our understanding to the same modeled physical interactions paradigm that is the underlying historical basis of the laws of the hard sciences. 3. In the tradition of the physical sciences, these larger scale patterns encode what we learn from scientific and other endeavors, providing the basis of larger scale science and engineering disciplines. 4. As several have noted this week, we may not necessarily need more science as it relates to 1 but we argue that 2 and 3 are woefully in need of more attention, as firstclass systems in their own right the interventions are needed there, not just for 1 and some S2/S3 science is needed. 5. INCOSE and ISSS are especially about 2 and 3--interested parties are invited to join the INCOSE MBSE s Working Group and participate in the related activities. 33

35 References 1. Schindel, W., What Is the Smallest Model of a?, in Proc. of the INCOSE 2011 International Symposium, International Council on s Engineering, Schindel, W., Interactions: Making The Heart of s More Visible, in Proc. of INCOSE Great Lakes Regional Conference, Schindel, W., Got Phenomena? Science-Based Disciplines for Emerging Challenges, in Proc. of INCOSE 2016 International Symposium, International Council on s Engineering, Edinburgh, UK, Friedenthal, S., et al, A World In Motion: SE Vision 2025, International Council on s Engineering, Schindel, W., and Dove, R., Introduction to the Agile s Engineering Life Cycle MBSE, in Proc. of INCOSE 2016 International Symposium, Edinburgh, UK, Schindel W., and Beihoff, B., s of Innovation I: Models of Their Health and Pathologies, in Proc. of INCOSE International Symposium, Schindel, W., s of Innovation II: The Emergence of Purpose, in Proc. of INCOSE 2013 International Symposium, Schindel, W., Life Cycle Trajectories: Tracking Innovation Paths Using DNA, in Proc. of the INCOSE 2015 International Symposium, Seattle, WA, July, INCOSE s Working Group web site, at INCOSE s Working Group, -Based s Engineering (PBSE), Based On S*MBSE Models, INCOSE PBSE Working Group, 2015: ISO/IEC 15288: 2015, s Engineering Life Cycle Processes. International Standards Organization, Schindel, W., Hybrid agent enablers for evolutionary competence, in Proc. of Complex Adaptive s CAS 2011 Conference, Elsevier, Marzolf, T., Schindel, W., Smith, G., Report of the SSWG SP/SP Modeling Sub-Team, INCOSE IW2014, Los Angeles, CA, Jan 27, Peterson, T., and Schindel, W., Explicating Value through First Principles: Re-Uniting Decision Analysis with s Engineering, in Proc. Of INCOSE International Symposium, Edinburgh, UK, Schindel, W., Kline, W., Ahmed, J., Peffers, S., and Johnson, J., All Innovation Is Innovation of s: A 3-D Model of Innovation Competencies, in Proc. Of ASEE 2011 Conference, Vancouver,