Difference between pages "Applying a Model-Based Approach to Support Requirements Analysis on the Thirty-Meter Telescope" and "Foundations of Systems Engineering"

From SEBoK
(Difference between pages)
Jump to: navigation, search
m (Text replacement - "<center>'''SEBoK v. 2.0, released 1 June 2019'''</center>" to "<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>")
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
This article describes how a model-based systems engineering (MBSE) approach was used to support requirements analysis, system design, and early verification for critical subsystems of the Thirty Meter Telescope (TMT) [8]. The MBSE approach applied the Executable Systems Engineering Method (ESEM) [4] [5] and the Open-source Engineering Environment (OpenMBEE) [7] to specify, analyze, and verify requirements of TMT’s Alignment and Phasing System (APS) and the Narrow Field Infrared Adaptive Optics System (NFIRAOS). The value proposition for applying this MBSE approach was to establish precise requirements and fine-grained traceability to system designs, and to verify key requirements using executable SysML [6] models beginning early in development.  
+
----
 +
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Scott Jackson, Janet Singer, Duane Hybertson''
 +
----
 +
Part 2 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to foundational knowledge which is relevant or useful to {{Term|Systems Engineering (glossary)|systems engineering}} (SE).
 +
[[File:SEBoK Navigation Foundation.PNG|centre|thumb|746x746px|'''Figure 1. SEBoK Part 2 in context (SEBoK Original).''' For more detail see[[Structure of the SEBoK]]]]
 +
This knowledge is included in the SEBoK firstly to help {{Term|Systems Engineer (glossary)|systems engineers}} benefit from an understanding of the foundations of their discipline, and to provide them with access to some of the theories and practices of {{Term|Systems Science (glossary)|systems science}} and other fields of systems practice.  Including this wider integrative systems science context in the SEBoK should also help to make SE knowledge more accessible to a wider audience outside of its traditional {{Term|Domain (glossary)|domains}}.
 +
 
 +
==Knowledge Areas in Part 2==
 +
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 2 contains the following KAs:
 +
 
 +
*[[Systems Fundamentals]]
 +
*[[Systems Approach Applied to Engineered Systems]]
 +
*[[Systems Science]]
 +
*[[Systems Thinking]]
 +
*[[Representing Systems with Models]]
 +
 
 +
==Introduction==
 +
 
 +
Most systems engineers are practitioners, applying {{Term|Process (glossary)|processes}} and methods that have been developed and evolved over decades. SE is a pragmatic approach, inherently interdisciplinary, yet specialized. Systems engineers usually work within a specific domain using processes and methods that are tailored to their domain’s unique {{Term|Problem (glossary)|problems}}, {{Term|Constraint (glossary)|constraints}}, {{Term|Risk (glossary)|risks}} and {{Term|Opportunity (glossary)|opportunities}}. These processes and methods have evolved to capture domain experts’ knowledge regarding the best approach to applying SE to the particular domain.
 +
 
 +
Specific domains in which {{Term|Systems Approach (glossary)|systems approaches}} are used and adapted include:
 +
* Technology products, integrating multiple {{Term|Engineering (glossary)|engineering}} disciplines
 +
* Information-rich systems, e.g. command & control, air traffic management, etc.
 +
* Platforms, e.g. aircraft, civil airliners, cars, trains, etc. 
 +
* Organizational and enterprise systems, which may be focused on delivering service or capability
 +
* Civil engineering/infrastructure systems, e.g. roads networks, bridges, builds, communications networks, etc.
  
==Background==
+
The specific skill-sets for each domain, and the kinds and scales of system it considers, may be quite different. However, there are certain underlying unifying systems principles that can improve the effectiveness of the systems approach in any domain. In particular, shared knowledge of systems principles and terminology will enable communication and improve system engineers’ ability to integrate {{Term|Complex (glossary)|complex}} systems that span traditional domain {{Term|Boundary (glossary)|boundaries}} (Sillitto 2012). This integrated approach is increasingly needed to solve today’s complex system challenges, but as these different communities come together, they may find that assumptions underpinning their worldviews are not shared.  
The TMT (Figure 1) is a next-generation ground-based extremely large telescope designed to answer key science questions regarding the nature and composition of the Universe. At its core is a wide-field, altitude-azimuth Ritchey-Chrétien design with a 492 segment, 30-meter diameter primary mirror (M1), a fully active secondary mirror, and an articulated tertiary mirror. Each segment’s optical performance is sensitive to three rigid body degrees of freedom: piston, tip, and tilt. To obtain optimal image quality, the segmented M1 must perform like a single monolithic mirror, achieved through a multitude of controls working to co-align, co-focus, and co-phase its segments. The APS (Figure 2) is responsible for the overall pre-adaptive optics wavefront quality, using starlight to measure wavefront errors and align the TMT optics. Adaptive optics systems like the NFIRAOS (Figure 2) are designed to sense real-time atmospheric turbulence and correct the telescope’s optical beam to remove its effect, enabling diffraction-limited imaging on the ground. In LGS MCAO and NGSAO modes, this is achieved through the use of wavefront sensors to detect laser and natural guide stars and deformable mirrors to direct the corrected wavefront to science instruments. These opto-mechanical designs and complex controls are constrained by several requirements that must be satisfied.
 
  
[[File:ThirtyMeterTelescope_Figure1_TelescopeImage.png|center|thumb|<center>'''Figure 1. Thirty Meter Telescope.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
==General Systems Engineering Foundations==
[[File:ThirtyMeterTelescope_Figure2_EarlyLightLocations.png|center|thumb|<center>'''Figure 2. APS and NFIRAOS early light locations.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
To bridge the gap between different domains and communities of practice, it is important to first establish a well-grounded definition of the “intellectual foundations of systems engineering,” as well as a common language to describe the relevant {{Term|Concept (glossary)|concepts}} and {{Term|Paradigm (glossary)|paradigms}}. An integrated systems approach for solving complex problems needs to combine elements of systems theories and systems approaches to practice. This may range from the technical-systems focus that has been dominant in systems engineering to the learning-systems focus of social systems intervention. An integrated systems approach needs to provide a framework and language that allow different communities with highly divergent worldviews and skill sets to work together for a common {{Term|Purpose (glossary)|purpose}}.
  
TMT International Observatory (TIO), LLC is a non-profit organization of international members, responsible for managing the design, development, and operations of the TMT. The Jet Propulsion Laboratory (JPL) [9] participates in the design and development of several TMT subsystems and delivers an operational APS, where TIO is responsible for providing requirements to JPL. The APS team applies an MBSE approach to analyze requirements, derive an architecture design, and implement a system. TIO also works with JPL to analyze the operational behavior of NFIRAOS through modeling system-level operational scenarios (such as slew, acquisition, and dithering) with Monte-Carlo simulations. Modeling patterns are used to capture functional and physical system characteristics, behavior, requirements, parametric relationships, and use case scenarios. MBSE applications are motivated by optimization to better understand TMT’s complex system behaviors.
+
The SEBoK as a whole aims to provide principles and concepts which can be used to support all potential applications of systems engineering, and which can be easily translated to any particular application by the reader. Often the published knowledge related to systems engineering has been developed from particular application areas, typically combinations of applications like defense, transport, or medical, business models such as government, commercial or voluntary or technology domains such as mechanical, electrical or cyber. In publishing it, authors will make some effort to '''specialize''' it into knowledge which can be applied across related applications.
  
==Purpose==
+
In the SEBoK, we seek to find or create '''general''' descriptions of SE knowledge.  A general description should cover all applications of systems engineering and should include an explanation of the special cases it covers and how it applied to them.  The generalization of knowledge can be informal, providing coverage of the most common specializations or being the domains current best understanding of the general case. A truly general description must be based upon stronger theoretical considerations and be in some sense proven to predict and cover all special cases. Knowledge described in the SEBoK will usually be informally generalized knowledge, with any specific knowledge being identified as such and related to the general as appropriate.
This article describes how MBSE is applied to the development of critical subsystems of a complex interdisciplinary system and the benefits of this approach. While document-based artifacts are necessary throughout the development lifecycle, complex systems engineering relies significantly on the use of models to address concerns from various domains (e.g. mechanics, optics, controls) (Figure 3). MBSE helps to manage implicit dependencies on information contained in these cross-domain documents, understand change impacts, analyze designs, and communicate evolving technical baselines. Models act as the single source of authority for systems engineering information that enables optimization through consistent and automated data exchange, enhanced analyses, and consolidating subsystem design information into separate artifacts needed by various stakeholders.  
 
  
[[File:ThirtyMeterTelescope_Figure3.png|center|thumb|550x550px|<center>'''Figure 3. Landscape of Engineering Models.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
The INCOSE Vision 2025 includes an aim for systems engineering to be become a discipline with a formally defined theoretical basis.  Such a general theory of SE would be largely included in SEBoK Part 2. The current SEBoK part 2 does not include such a theory. It provides generalized descriptions of foundational knowledge which has a pragmatic value to help describe and improve the current and future practice of systems engineering. We would expect any emerging general theory of systems engineering to draw from and expand these foundations.   As such a theory is defined, it will be included in Part 2 of the SEBoK.
  
==MBSE Challenges==
+
==The Systems Praxis Framework==
Systems engineering (SE) is inherently challenging with concepts spanning several engineering disciplines. Expressing these concepts in a model demands the use of flexible methodology, language, and tools. The modeler must understand how to leverage this flexibility to rigorously specify systems with a broad range of complex design considerations. This poses the initial MBSE challenge—'''the learning curve'''. However, this challenge is native to any new undertaking and is overcome by hands-on experience, training, and ever-growing resources.
+
 
+
The term '''“systems praxis”''' refers to the entire intellectual and practical endeavor for creating {{Term|Holistic (glossary)|holistic}} solutions to today’s complex system challenges. {{Term|Praxis (glossary)|Praxis}} is defined as “translating an idea into action”  (Wordnet 2012) and suggests that the best holistic approach to a given complex challenge may require integrating appropriate theory and appropriate practice from a wide variety of sources. Systems praxis requires many communities to work together. To work together we must first communicate; and to communicate, we must first connect.
Another challenge is determining how to '''apply''' MBSE to meet the needs of a project. MBSE is not separate from SE—it is an approach to achieve the fundamental goals of SE more efficiently. MBSE should not be used to duplicate work, but instead replace efforts that can be better accomplished formally through modeling.
+
 
+
A framework for unifying systems praxis was developed by members of International Council on Systems Engineering (INCOSE) and International Society for the System Sciences (ISSS) (International Federation for Systems Research (IFSR) 2012)) as the first step towards a “common language for systems praxis”. This '''Systems Praxis Framework''' is included here because it represents current thinking on the foundations and common language of systems engineering, making the concepts and principles of systems thinking and practice accessible to anyone applying a systems approach to {{Term|Engineered System (glossary)|engineered system}} problems.  This framework and thinking have been used to help organize the guide to systems knowledge in the SEBoK.
Engineers live in a landscape of variability among tools and information models in different domains (e.g. ALM, PLM, CAD), which are often implicitly connected [4]. To benefit from a model-based paradigm, the models require explicit connections. A key challenge is how to leverage data and associated models to enable '''cross-domain integration'''.
+
 
+
The diagram below shows the flows and interconnections among elements of a “knowledge ecosystem” of systems theory and practice.
Finally, '''standardization''' is a challenge for MBSE. A model is only effective if stakeholders can understand it. SysML is an evolving modeling language that is becoming the dominant standard to communicate system architectures, independent of the modeling tools that use it. However, SysML is only one of many standards that must be applied to ensure the models can be consistently interpreted by tools and users.
 
  
==MBSE Approach==
+
[[File:IFSR_SPF_August_2013.jpg|thumb|850px|center|'''Figure 2.  The Systems Praxis Framework, Developed as a Joint Project of INCOSE and ISSS.''' (© 2012 International Federation for Systems Research) Released under Creative Commons Attribution 3.0 License. Source is available at http://systemspraxis.org/framework.pdf.]]
The MBSE approach follows the conventional SE V-process enriched by a model-based paradigm (Figure 4). The scope of this MBSE application addresses models at L2 and L3, and requirements flow-down to L4, although the approach can be applied to support specification and architecture design at other levels as well. Associated modeling artifacts are created early and maintained throughout the development lifecycle.
 
  
[[File:ThirtyMeterTelescope_Figure4.png|center|thumb|550x550px|<center>'''Figure 4. JPL Model-based V Process.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
In this framework, the following elements are connected:
  
MBSE articulates the system architecture in a formal, executable model that captures structure, behavior, requirements, and parametric relationships of system elements. Operational scenarios are defined in the model and analyzed through system-level simulation to verify requirements and validate overall system design over an expected range of conditions and parameters. The system model is also the authoritative source for several engineering documents. The MBSE approach is subsequently described by its methodology, tooling infrastructure, and analysis processes.
+
'''Systems Thinking''' is the core integrative element of the framework. It binds the foundations, theories and representations of systems science together with the hard, soft and pragmatic approaches of systems practice. In systems praxis, as in any practical discipline underpinned by science, there is constant interplay between theories and practice, with theory informing practice and outcomes from practice informing theory.  Systems thinking is the ongoing activity of assessing and appreciating the {{Term|System Context (glossary)|system context}}, and guiding appropriate adaptation, throughout the praxis cycle.  
  
==Methodology==
+
'''Integrative Systems Science''' has a very wide scope and is grouped into three broad areas:
The Executable Systems Engineering Method (ESEM) [1] is used to formalize requirements, specify system designs, characterize components, and specify/run analyses. ESEM augments the Object Oriented Systems Engineering Method (OOSEM) [2] by enabling executable models that enhance understanding, precision, and verification of requirements through applying analysis patterns specified with various SysML diagrams. ESEM also enables integration of supplier/customer models.
+
* '''Foundations''', which help to organize knowledge and promote learning and discovery. This area includes: meta-theories of methodology, ontology, epistemology, axiology, praxiology (theory of effective action), teleology, semiotics & semiosis, category theory, etc.
+
* '''Theories''' pertaining to systems are abstracted from domains and specialties, so as to be universally applicable: {{Term|General System Theory (glossary)|general system theory}}, systems pathology, {{Term|Complexity (glossary)|complexity}}, anticipatory systems, cybernetics, autopoiesis, living systems, science of generic design, organization theory, etc.
Figure 5 shows the major activities common to SE processes using OOSEM. The red circles indicate where ESEM injects formal modeling methods.  
+
* '''Representations''' and corresponding theories describe, explore, analyze, and make predictions about systems and their wider contexts, whether in terms of {{Term|Model (glossary)|models}}, dynamics, networks, cellular automata, {{Term|Life Cycle (glossary)|life cycles}}, queues, graphs, rich pictures, narratives, games and dramas, agent-based {{Term|Simulation (glossary)|simulations}}, etc.
  
[[File:ThirtyMeterTelescope_Figure5.png|center|thumb|550x550px|<center>'''Figure 5. OOSEM activities.''' (Used with permission. Permission granted by Jamie Nakawatase.) [8]</center>]]
+
'''Systems Approaches to Practice''' aim to act on real world experiences to produce desired outcomes without adverse, unintended consequences; ergo, practice needs to draw on the wide range of knowledge appropriate to the {{Term|System-of-Interest (glossary)|system-of-interest}} and its wider context. No one branch of systems science or practice provides a satisfactory explanation for all aspects of a typical system “problematique”; therefore, a more pragmatic approach is needed. Traditional systems approaches are often described to be either hard or soft: 
  
ESEM is utilized to model different levels of abstraction that are analyzed using several modeling patterns as detailed in [4]. The system-of-interest is modeled as a black box that interacts with external subsystems, such as controls. Interactions are modeled using ports to identify operations and flows at the system-of-interest interface.  
+
* '''Hard''' approaches are suited to solving well-defined problems with reliable data and clear goals, using analytical methods and quantitative techniques. Strongly influenced by “machine” metaphors, they focus on technical systems, objective complexity, and optimization to achieve desired combinations of emergent properties. They are based on “realist” and “functionalist” foundations and worldview.
+
* '''Soft''' approaches are suited to structuring problems involving incomplete data, unclear goals, and open inquiries, using a “learning system” metaphor, focus on communication, intersubjective complexity, interpretations and roles, and draw on subjective and “humanist” philosophies with constructivist and interpretivist foundations.
The conceptual model specifies technology-independent system components and captures their behavior. This part of the model is used to analyze characteristics such as duration of operational scenarios. Component behavior is captured using state machines and activity diagrams, and constraint parameters are captured in a table. Communication across internal and external system components is accomplished through the sending and receiving of signals through ports. This model supports production of interface control documents by querying information sent from one component to another over ports.
 
 
The conceptual model serves as a basis to specify the realization model of the physical components. The realization model imposes technology-dependent constraints on the design solutions. Both the conceptual (i.e. logical) and realization (i.e. physical) models represent the “as-specified” system.
 
  
==Tooling==
+
'''Pragmatic''' (pluralist or critical) approaches judiciously select an appropriate set of tools and patterns that will give sufficient and appropriate insights to manage the issue at hand by applying multiple methodologies drawn from different foundations as appropriate to the situation. {{Term|Heuristic (glossary)|Heuristics}}, boundary critiques, model unfolding, etc, enable the understanding of assumptions, contexts, and {{Term|Constraint (glossary)|constraints}}, including complexity due to different {{Term|Stakeholder (glossary)|stakeholders’}} {{Term|Value (glossary)|values}} and valuations. An appropriate mix of “hard”, “soft”, and custom methods draws on both systems and domain-specific traditions. Systems may be viewed as {{Term|Network (glossary)|networks}}, societies of agents, organisms, ecosystems, rhizomes, discourses, machines, etc.
The MBSE approach uses standard SysML language and modeling tools to minimize custom software. The OpenMBEE community promotes an open tooling environment that provides a platform for modeling. It utilizes the Model Management System (MMS) that can be accessed from rich SysML desktop clients like MagicDraw, lightweight web-based clients like View Editor, computational programs like Mathematica, and other tools that utilize RESTful web services. The MMS also provides the basic infrastructure for search, relation management, versioning, workflow, access control, content flexibility, web applications support, web-based API access, and multi-tool/repository integration across engineering and management disciplines.
 
 
Figure 6 shows the integration of model artifacts produced by MMS, View Editor, and MagicDraw. System models are constructed, queried, and rendered following the view and viewpoint paradigm [3] from MMS.  
 
  
[[File:ThirtyMeterTelescope Figure6.png|center|thumb|550x550px|<center>'''Figure 6. OpenMBEE interactions.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
The set of “clouds” that collectively represents systems praxis is part of a wider ecosystem of knowledge, learning, and action. Successful {{Term|Integration (glossary)|integration}} with this wider ecosystem is the key to success with real world systems. Systems science is augmented by “hard” scientific disciplines, such as physics and neuroscience, and by formal disciplines, such as mathematics, logic and computation. It is both enhanced by, and used in, humanistic disciplines, such as psychology, culture, and rhetoric, and pragmatic disciplines, such as accounting, design, and law. Systems practice depends on measured data and specified {{Term|Metric (glossary)|metrics}} relevant to the problem situation and domain, the solicitation of local values and knowledge, and the pragmatic integration of experience, legacy practices, and discipline knowledge.
  
==Analysis==
+
In summary, '''Integrative Systems Science''' allows us to identify, explore, and understand patterns of complexity through contributions from the foundations, theories, and representations of systems science and other disciplines relevant to the “problematique”. '''Systems Approaches to Practice''' address complex problems and opportunities using methods, tools, frameworks, patterns, etc., drawn from the knowledge of integrative systems science, while the observation of the results of systems practice enhances the body of theory. '''Systems Thinking''' binds the two together through appreciative and reflective practice using systems concepts, principles, patterns, etc.
One key SE process is to analyze the impact of changing requirements on the system design. Figure 7 illustrates how the MBSE approach is used to support requirements impact analysis through the following steps:
 
*Step 1: A changed requirement triggers impact analysis.
 
*Step 2: MMS integrates DOORS (which manages text requirements) and the SysML model, enabling a DOORS requirement change to propagate to the SysML model.
 
*Step 3: A property-based requirement is formalized in SysML, enabling requirements specification that can be evaluated by engineering analysis.
 
*Steps 4-6: The conceptual and/or realization design is automatically verified against the changed requirement, resulting in pass or fail.
 
  
[[File:ThirtyMeterTelescope_Figure7.png|center|thumb|550x550px|<center>'''Figure 7. Propagation of a changed requirement.''' (Used with permission. Permission granted by Jamie Nakawatase.)</center>]]
+
==Scope of Part 2==
  
In this article, a simplified APS model is shown to illustrate the model-based approach for analyzing changed requirements. The full analysis is available in [4] and [5].
+
Part 2 of the SEBoK contains a guide to knowledge about systems, which is relevant to a better understanding of SE. It does not try to capture all of this systems knowledge here; rather, it provides an overview of a number of key aspects of systems theory and practice especially relevant to SE.  
  
A model-based approach was also applied to APS for error analysis, which was performed to describe the accuracy of expected system performance against requirements. It involved multiple artifacts to analyze a requirement such as “APS shall measure the position of the telescope pupil to an accuracy of 0.03% of the diameter of the pupil.” Defining requirements and parameters in the model indicated the required accuracy and current best estimates of the system design. Defining various roll-up patterns allowed for error decomposition calculations. The benefit is realized in automated requirements verification when applying a parametric solver to formulate results for specified equations in the model. This model-based approach formally integrates accuracy requirements with the system design.
+
The organization of knowledge in Part 2 is based around the Praxis Framework discussed above (IFSR 2012). The need to develop a clear guide to the underpinning knowledge of SE is one of the motivations behind the praxis framework. It is expected that the coverage of systems knowledge will be significantly increased in future versions of the SEBoK as this work progresses.
  
The system model for NFIRAOS LGS MCAO and NGSAO modes was developed to capture sequence behaviors and operational scenarios to run Monte-Carlo simulations for verifying acquisition time, observing efficiency, and operational behavior requirements. The model is particularly useful for investigating the effect of parallelization, identifying interface issues, and re-ordering sequence acquisition tasks.
+
The following diagram summarizes the way in which the knowledge in SEBoK Part 2 is organized.
  
ESEM enables system analysis by conducting quantitative assessments to select and/or update the most efficient system architecture and generate derived engineering data. System analysis provides rigor for technical decision-making. It includes modeling and simulation, cost, technical risks, and effectiveness analyses, and is used to perform trade studies. In particular, it supports requirements verification, which assesses whether a system design meets its objectives and satisfies the constraints levied by system requirements.
+
[[File:IFSR_ISA_July_2012_REV.png|thumb|center|700px|'''Figure 3. The Relationships between Key Systems Ideas and SE.''' (SEBoK Original)]]
 +
 +
The diagram is divided into five sections, each describing how systems knowledge is treated in the SEBoK.
 +
#  The [[Systems Fundamentals]] Knowledge Area considers the question “What is a System?”  It explores the wide range of system definitions and considers {{Term|Open System (glossary)|open systems}}, system types, groupings of systems, complexity, and {{Term|Emergence (glossary)|emergence}}.  All of these ideas are particularly relevant to engineered systems and to the groupings of such systems associated with the systems approach applied to engineered systems (i.e. {{Term|Product System (glossary)|product system}}, {{Term|Service System (glossary)|service system}}, {{Term|Enterprise System (glossary)|enterprise system}} and {{Term|System of Systems (SoS) (glossary)|system of systems}}).
 +
#  The [[Systems Approach Applied to Engineered Systems]] Knowledge Area defines a structured approach to problem/opportunity discovery, exploration, and resolution, that can be applied to all engineered systems. The approach is based on systems thinking and utilizes appropriate elements of system approaches and representations. This KA provides principles that map directly to SE practice.
 +
#  The [[Systems Science]] Knowledge Area presents some influential movements in systems science, including the chronological development of systems knowledge and underlying theories behind some of the approaches taken in applying systems science to real problems.
 +
#  The [[Systems Thinking]] Knowledge Area describes key concepts, principles and patterns shared across systems research and practice.
 +
#  The [[Representing Systems with Models]] Knowledge Area considers the key role that abstract models play in both the development of system theories and the application of systems approaches.
  
==Observed Benefits==
+
Systems thinking is a fundamental paradigm describing a way of looking at the world. People who think and act in a systems way are essential to the success of both the research and practice of system disciplines. In particular, individuals who have an awareness of and/or active involvements in both research and practice of system disciplines are needed to help integrate these closely related activities.
The MBSE approach applied to APS and NFIRAOS was motivated by optimization to coordinate the efforts of complex system development. In these applications, implicit dependencies are made explicit in a formal model through the use of ESEM, OpenMBEE, and SysML modeling constructs. Requirements are formalized and tracked directly to the evolving system design. This tight association of requirements within a common environment promotes cross-domain integration and efficient communication among stakeholders. The model is used to automate requirements verification and to generate systems engineering products. The benefit over a traditional document-based approach is that currently disconnected artifacts become related in the model, enabling the production of consistent model-based documentation. Requirements verification is an important analysis conducted in the context of MBSE. To perform this analysis, the requirements, executable behavior, and models predicting the system’s performance must be integrated. The ability to integrate these elements using ESEM and the OpenMBEE tooling infrastructure is a significant value proposition for the MBSE approach described in this article. In the formally integrated and executable SysML model, simulations are performed to analyze the impact of changed requirements and verify that requirements are met within specified constraints for various operational scenarios. MBSE enhances information exchange through created visualizations that communicate system behavior. For example, duration analyses were performed to study acquisition time for observing. The use of Monte-Carlo simulations proved how the model-based approach optimized the analysis process. Higher quality analysis results were obtained through the execution of operational scenario runs in an articulated system model, and the model continues to serve as a communication tool across various domains.  
 
  
==Acknowledgements==
+
The knowledge presented in this part of the SEBoK has been organized into these areas to facilitate understanding; the intention is to present a rounded picture of research and practice based on system knowledge. These knowledge areas should be seen together as a “system of ideas” for connecting research, understanding, and practice, based on system knowledge which underpins a wide range of scientific, management, and engineering disciplines and applies to all types of domains.
This research was carried out at the Jet Propulsion Laboratory (JPL), California Institute of Technology, under a contract with the National Aeronautics and Space Administration (NASA), and at NoMagic. The TMT Project gratefully acknowledges the support of the TMT collaborating institutions. They are the California Institute of Technology, the University of California, the National Astronomical Observatory of Japan, the National Astronomical Observatories of China and their consortium partners, the Department of Science and Technology of India and their supported institutes, and the National Research Council of Canada. This work was supported as well by the Gordon and Betty Moore Foundation, the Canada Foundation for Innovation, the Ontario Ministry of Research and Innovation, the Natural Sciences and Engineering Research Council of Canada, the British Columbia Knowledge Development Fund, the Association of Canadian Universities for Research in Astronomy (ACURA), the Association of Universities for Research in Astronomy (AURA), the U.S. National Science Foundation, the National Institutes of Natural Sciences of Japan, and the Department of Atomic Energy of India.
 
  
==References==
+
==References==  
 
===Works Cited===
 
===Works Cited===
[1] Zwemer, D., “Connecting SysML with PLM/ALM, CAD, Simulation, Requirements, and Project Management Tools”, Intercax LLC, May 2011.
+
 
[2] Friedenthal S, Moore A., and Steiner R., “A Practical Guide to SysML 3rd Ed.”, Morgan Kaufmann OMG Press, 2014
+
IFSR. 2012. ''The Systems Praxis Framework, Developed as a Joint Project of INCOSE and ISSS''. Vienna, Austria: International Federation for Systems Research (IFSR). Available at: http://systemspraxis.org/framework.pdf.
[3] ISO/IEC, ISO/IEC 42010:2011, Systems and software engineering - Architecture description
+
 
 +
Sillitto, H.G., 2012. "Integrating systems science, systems thinking, and systems engineering: Understanding the differences and exploiting the synergies", Proceedings of the 22nd INCOSE International Symposium, Rome, Italy, 9-12 July, 2012.
 +
 
 +
Wordnet. 2012. “Praxis.” Accessed 16 April 2013. Available at: http://wordnetweb.princeton.edu/perl/webwn?s=praxis&sub=Search+WordNet&o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&h=.
  
 
===Primary References===
 
===Primary References===
[4] Karban, R., Jankevičius, N., Elaasar, M. “ESEM: Automated Systems Analysis using Executable SysML Modeling Patterns”, INCOSE International Symposium (IS), Edinburgh, Scotland, 2016
+
Bertalanffy, L., von. 1968. ''[[General System Theory: Foundations, Development, Applications]]'', rev. ed. New York, NY, USA: Braziller.
[5] Karban, R. “Using Executable SysML Models to Generate System Engineering Products”, NoMagic World Symposium, 2016
+
 
[6] OMG SysML, “Systems Modeling Language (SysML) Version 1.4”, OMG, 2014
+
Checkland, P. B. 1999. ''[[Systems Thinking, Systems Practice]].'' Chichester, UK: John Wiley & Sons.
[7] Open Source Engineering Environment: https://open-mbee.github.io/
 
[8] TMT, “Thirty Meter Telescope.” http://www.tmt.org
 
[9] JPL, “Jet Propulsion Laboratory.” https://www.jpl.nasa.gov/
 
[10] Karban R., Dekens F., Herzig S., Elaasar M, Jankevičius N., “Creating systems engineering products with executable models in a model-based engineering environment”, SPIE, Edinburgh, Scotland, 2016
 
  
 
===Additional References===
 
===Additional References===
https://github.com/Open-MBEE/TMT-SysML-Model
+
Blanchard, B., and Fabrycky, W. 2010. ''Systems Engineering and Analysis'', (5th edition). Saddle River, NJ, USA: Prentice Hall. 
https://github.com/Open-MBEE/mdk/tree/support/2.5/manual
+
 
http://www.omgwiki.org/MBSE/doku.php?id=mbse:telescope
+
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College, UK.
https://groups.google.com/forum/#!forum/openmbee
+
 
 +
Martin J., Bendz J., Chroust G., Hybertson D., Lawson H., Martin R., Sillitto H., Singer J., Singer M., Takaku T.  “Towards a common language for systems praxis”, Proceedings of the 23rd INCOSE International Symposium, Philadelphia, June 2013.
 +
 
 +
MITRE Corporation.  2011.  ''Systems Engineering Guide: Comprehensive Viewpoint.'' Accessed 20 November 2014. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/.
 +
 
 +
MITRE Corporation.  2011.  ''Systems Engineering Guide: Systems Thinking.'' Accessed 20 November 2014. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/systems_thinking.html.
 +
 
 +
Senge, P. M. 1990. ''The Fifth Discipline: The Art & Practice of the Learning Organization.'' New York, NY: Doubleday Business.
 +
 
  
 
----
 
----
<center>[[Virginia Class Submarine|< Previous Article]] | [[Implementation Examples|Parent Article]] | [[Miniature Seeker Technology Integration Spacecraft|Next Article>]]</center>
+
<center>[[Use Case 5: General Managers|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Systems Fundamentals|Next Article >]]</center>
  
 +
[[Category:Part]][[Category:Part 2]]
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
 
[[Category:Part 7]] [[Category:Case Study]]
 

Revision as of 19:49, 28 February 2020


Lead Author: Rick Adcock, Contributing Authors: Scott Jackson, Janet Singer, Duane Hybertson


Part 2 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to foundational knowledge which is relevant or useful to systems engineeringsystems engineering (SE).

Figure 1. SEBoK Part 2 in context (SEBoK Original). For more detail seeStructure of the SEBoK

This knowledge is included in the SEBoK firstly to help systems engineerssystems engineers benefit from an understanding of the foundations of their discipline, and to provide them with access to some of the theories and practices of systems sciencesystems science and other fields of systems practice. Including this wider integrative systems science context in the SEBoK should also help to make SE knowledge more accessible to a wider audience outside of its traditional domainsdomains.

Knowledge Areas in Part 2

Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 2 contains the following KAs:

Introduction

Most systems engineers are practitioners, applying processesprocesses and methods that have been developed and evolved over decades. SE is a pragmatic approach, inherently interdisciplinary, yet specialized. Systems engineers usually work within a specific domain using processes and methods that are tailored to their domain’s unique problemsproblems, constraintsconstraints, risksrisks and opportunitiesopportunities. These processes and methods have evolved to capture domain experts’ knowledge regarding the best approach to applying SE to the particular domain.

Specific domains in which systems approachessystems approaches are used and adapted include:

  • Technology products, integrating multiple engineeringengineering disciplines
  • Information-rich systems, e.g. command & control, air traffic management, etc.
  • Platforms, e.g. aircraft, civil airliners, cars, trains, etc.
  • Organizational and enterprise systems, which may be focused on delivering service or capability
  • Civil engineering/infrastructure systems, e.g. roads networks, bridges, builds, communications networks, etc.

The specific skill-sets for each domain, and the kinds and scales of system it considers, may be quite different. However, there are certain underlying unifying systems principles that can improve the effectiveness of the systems approach in any domain. In particular, shared knowledge of systems principles and terminology will enable communication and improve system engineers’ ability to integrate complexcomplex systems that span traditional domain boundariesboundaries (Sillitto 2012). This integrated approach is increasingly needed to solve today’s complex system challenges, but as these different communities come together, they may find that assumptions underpinning their worldviews are not shared.

General Systems Engineering Foundations

To bridge the gap between different domains and communities of practice, it is important to first establish a well-grounded definition of the “intellectual foundations of systems engineering,” as well as a common language to describe the relevant conceptsconcepts and paradigmsparadigms. An integrated systems approach for solving complex problems needs to combine elements of systems theories and systems approaches to practice. This may range from the technical-systems focus that has been dominant in systems engineering to the learning-systems focus of social systems intervention. An integrated systems approach needs to provide a framework and language that allow different communities with highly divergent worldviews and skill sets to work together for a common purposepurpose.

The SEBoK as a whole aims to provide principles and concepts which can be used to support all potential applications of systems engineering, and which can be easily translated to any particular application by the reader. Often the published knowledge related to systems engineering has been developed from particular application areas, typically combinations of applications like defense, transport, or medical, business models such as government, commercial or voluntary or technology domains such as mechanical, electrical or cyber. In publishing it, authors will make some effort to specialize it into knowledge which can be applied across related applications.

In the SEBoK, we seek to find or create general descriptions of SE knowledge. A general description should cover all applications of systems engineering and should include an explanation of the special cases it covers and how it applied to them. The generalization of knowledge can be informal, providing coverage of the most common specializations or being the domains current best understanding of the general case. A truly general description must be based upon stronger theoretical considerations and be in some sense proven to predict and cover all special cases. Knowledge described in the SEBoK will usually be informally generalized knowledge, with any specific knowledge being identified as such and related to the general as appropriate.

The INCOSE Vision 2025 includes an aim for systems engineering to be become a discipline with a formally defined theoretical basis. Such a general theory of SE would be largely included in SEBoK Part 2. The current SEBoK part 2 does not include such a theory. It provides generalized descriptions of foundational knowledge which has a pragmatic value to help describe and improve the current and future practice of systems engineering. We would expect any emerging general theory of systems engineering to draw from and expand these foundations. As such a theory is defined, it will be included in Part 2 of the SEBoK.

The Systems Praxis Framework

The term “systems praxis” refers to the entire intellectual and practical endeavor for creating holisticholistic solutions to today’s complex system challenges. PraxisPraxis is defined as “translating an idea into action” (Wordnet 2012) and suggests that the best holistic approach to a given complex challenge may require integrating appropriate theory and appropriate practice from a wide variety of sources. Systems praxis requires many communities to work together. To work together we must first communicate; and to communicate, we must first connect.

A framework for unifying systems praxis was developed by members of International Council on Systems Engineering (INCOSE) and International Society for the System Sciences (ISSS) (International Federation for Systems Research (IFSR) 2012)) as the first step towards a “common language for systems praxis”. This Systems Praxis Framework is included here because it represents current thinking on the foundations and common language of systems engineering, making the concepts and principles of systems thinking and practice accessible to anyone applying a systems approach to engineered systemengineered system problems. This framework and thinking have been used to help organize the guide to systems knowledge in the SEBoK.

The diagram below shows the flows and interconnections among elements of a “knowledge ecosystem” of systems theory and practice.

Figure 2. The Systems Praxis Framework, Developed as a Joint Project of INCOSE and ISSS. (© 2012 International Federation for Systems Research) Released under Creative Commons Attribution 3.0 License. Source is available at http://systemspraxis.org/framework.pdf.

In this framework, the following elements are connected:

Systems Thinking is the core integrative element of the framework. It binds the foundations, theories and representations of systems science together with the hard, soft and pragmatic approaches of systems practice. In systems praxis, as in any practical discipline underpinned by science, there is constant interplay between theories and practice, with theory informing practice and outcomes from practice informing theory. Systems thinking is the ongoing activity of assessing and appreciating the system contextsystem context, and guiding appropriate adaptation, throughout the praxis cycle.

Integrative Systems Science has a very wide scope and is grouped into three broad areas:

  • Foundations, which help to organize knowledge and promote learning and discovery. This area includes: meta-theories of methodology, ontology, epistemology, axiology, praxiology (theory of effective action), teleology, semiotics & semiosis, category theory, etc.
  • Theories pertaining to systems are abstracted from domains and specialties, so as to be universally applicable: general system theorygeneral system theory, systems pathology, complexitycomplexity, anticipatory systems, cybernetics, autopoiesis, living systems, science of generic design, organization theory, etc.
  • Representations and corresponding theories describe, explore, analyze, and make predictions about systems and their wider contexts, whether in terms of modelsmodels, dynamics, networks, cellular automata, life cycleslife cycles, queues, graphs, rich pictures, narratives, games and dramas, agent-based simulationssimulations, etc.

Systems Approaches to Practice aim to act on real world experiences to produce desired outcomes without adverse, unintended consequences; ergo, practice needs to draw on the wide range of knowledge appropriate to the system-of-interestsystem-of-interest and its wider context. No one branch of systems science or practice provides a satisfactory explanation for all aspects of a typical system “problematique”; therefore, a more pragmatic approach is needed. Traditional systems approaches are often described to be either hard or soft:

  • Hard approaches are suited to solving well-defined problems with reliable data and clear goals, using analytical methods and quantitative techniques. Strongly influenced by “machine” metaphors, they focus on technical systems, objective complexity, and optimization to achieve desired combinations of emergent properties. They are based on “realist” and “functionalist” foundations and worldview.
  • Soft approaches are suited to structuring problems involving incomplete data, unclear goals, and open inquiries, using a “learning system” metaphor, focus on communication, intersubjective complexity, interpretations and roles, and draw on subjective and “humanist” philosophies with constructivist and interpretivist foundations.

Pragmatic (pluralist or critical) approaches judiciously select an appropriate set of tools and patterns that will give sufficient and appropriate insights to manage the issue at hand by applying multiple methodologies drawn from different foundations as appropriate to the situation. HeuristicsHeuristics, boundary critiques, model unfolding, etc, enable the understanding of assumptions, contexts, and constraintsconstraints, including complexity due to different stakeholders’stakeholders’ valuesvalues and valuations. An appropriate mix of “hard”, “soft”, and custom methods draws on both systems and domain-specific traditions. Systems may be viewed as networksnetworks, societies of agents, organisms, ecosystems, rhizomes, discourses, machines, etc.

The set of “clouds” that collectively represents systems praxis is part of a wider ecosystem of knowledge, learning, and action. Successful integrationintegration with this wider ecosystem is the key to success with real world systems. Systems science is augmented by “hard” scientific disciplines, such as physics and neuroscience, and by formal disciplines, such as mathematics, logic and computation. It is both enhanced by, and used in, humanistic disciplines, such as psychology, culture, and rhetoric, and pragmatic disciplines, such as accounting, design, and law. Systems practice depends on measured data and specified metricsmetrics relevant to the problem situation and domain, the solicitation of local values and knowledge, and the pragmatic integration of experience, legacy practices, and discipline knowledge.

In summary, Integrative Systems Science allows us to identify, explore, and understand patterns of complexity through contributions from the foundations, theories, and representations of systems science and other disciplines relevant to the “problematique”. Systems Approaches to Practice address complex problems and opportunities using methods, tools, frameworks, patterns, etc., drawn from the knowledge of integrative systems science, while the observation of the results of systems practice enhances the body of theory. Systems Thinking binds the two together through appreciative and reflective practice using systems concepts, principles, patterns, etc.

Scope of Part 2

Part 2 of the SEBoK contains a guide to knowledge about systems, which is relevant to a better understanding of SE. It does not try to capture all of this systems knowledge here; rather, it provides an overview of a number of key aspects of systems theory and practice especially relevant to SE.

The organization of knowledge in Part 2 is based around the Praxis Framework discussed above (IFSR 2012). The need to develop a clear guide to the underpinning knowledge of SE is one of the motivations behind the praxis framework. It is expected that the coverage of systems knowledge will be significantly increased in future versions of the SEBoK as this work progresses.

The following diagram summarizes the way in which the knowledge in SEBoK Part 2 is organized.

Figure 3. The Relationships between Key Systems Ideas and SE. (SEBoK Original)

The diagram is divided into five sections, each describing how systems knowledge is treated in the SEBoK.

  1. The Systems Fundamentals Knowledge Area considers the question “What is a System?” It explores the wide range of system definitions and considers open systemsopen systems, system types, groupings of systems, complexity, and emergenceemergence. All of these ideas are particularly relevant to engineered systems and to the groupings of such systems associated with the systems approach applied to engineered systems (i.e. product systemproduct system, service systemservice system, enterprise systementerprise system and system of systemssystem of systems).
  2. The Systems Approach Applied to Engineered Systems Knowledge Area defines a structured approach to problem/opportunity discovery, exploration, and resolution, that can be applied to all engineered systems. The approach is based on systems thinking and utilizes appropriate elements of system approaches and representations. This KA provides principles that map directly to SE practice.
  3. The Systems Science Knowledge Area presents some influential movements in systems science, including the chronological development of systems knowledge and underlying theories behind some of the approaches taken in applying systems science to real problems.
  4. The Systems Thinking Knowledge Area describes key concepts, principles and patterns shared across systems research and practice.
  5. The Representing Systems with Models Knowledge Area considers the key role that abstract models play in both the development of system theories and the application of systems approaches.

Systems thinking is a fundamental paradigm describing a way of looking at the world. People who think and act in a systems way are essential to the success of both the research and practice of system disciplines. In particular, individuals who have an awareness of and/or active involvements in both research and practice of system disciplines are needed to help integrate these closely related activities.

The knowledge presented in this part of the SEBoK has been organized into these areas to facilitate understanding; the intention is to present a rounded picture of research and practice based on system knowledge. These knowledge areas should be seen together as a “system of ideas” for connecting research, understanding, and practice, based on system knowledge which underpins a wide range of scientific, management, and engineering disciplines and applies to all types of domains.

References

Works Cited

IFSR. 2012. The Systems Praxis Framework, Developed as a Joint Project of INCOSE and ISSS. Vienna, Austria: International Federation for Systems Research (IFSR). Available at: http://systemspraxis.org/framework.pdf.

Sillitto, H.G., 2012. "Integrating systems science, systems thinking, and systems engineering: Understanding the differences and exploiting the synergies", Proceedings of the 22nd INCOSE International Symposium, Rome, Italy, 9-12 July, 2012.

Wordnet. 2012. “Praxis.” Accessed 16 April 2013. Available at: http://wordnetweb.princeton.edu/perl/webwn?s=praxis&sub=Search+WordNet&o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&h=.

Primary References

Bertalanffy, L., von. 1968. General System Theory: Foundations, Development, Applications, rev. ed. New York, NY, USA: Braziller.

Checkland, P. B. 1999. Systems Thinking, Systems Practice. Chichester, UK: John Wiley & Sons.

Additional References

Blanchard, B., and Fabrycky, W. 2010. Systems Engineering and Analysis, (5th edition). Saddle River, NJ, USA: Prentice Hall.

Lawson, H. 2010. A Journey Through the Systems Landscape. London, UK: College Publications, Kings College, UK.

Martin J., Bendz J., Chroust G., Hybertson D., Lawson H., Martin R., Sillitto H., Singer J., Singer M., Takaku T. “Towards a common language for systems praxis”, Proceedings of the 23rd INCOSE International Symposium, Philadelphia, June 2013.

MITRE Corporation. 2011. Systems Engineering Guide: Comprehensive Viewpoint. Accessed 20 November 2014. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/.

MITRE Corporation. 2011. Systems Engineering Guide: Systems Thinking. Accessed 20 November 2014. Available at: http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/systems_thinking.html.

Senge, P. M. 1990. The Fifth Discipline: The Art & Practice of the Learning Organization. New York, NY: Doubleday Business.



< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019