DOCSLIB.ORG

A Model-Based Approach to System-Of-Systems Engineering Via the Yss Tems Modeling Language Kevin Hughes Bonanne Purdue University

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Model-Based Approach to System-Of-Systems Engineering Via the Yss Tems Modeling Language Kevin Hughes Bonanne Purdue University Purdue University Purdue e-Pubs Open Access Theses Theses and Dissertations Summer 2014 A Model-Based Approach To System-Of-Systems Engineering Via The ysS tems Modeling Language Kevin Hughes Bonanne Purdue University Follow this and additional works at: https://docs.lib.purdue.edu/open_access_theses Part of the Databases and Information Systems Commons Recommended Citation Bonanne, Kevin Hughes, "A Model-Based Approach To System-Of-Systems Engineering Via The ysS tems Modeling Language" (2014). Open Access Theses. 407. https://docs.lib.purdue.edu/open_access_theses/407 This document has been made available through Purdue e-Pubs, a service of the Purdue University Libraries. Please contact [email protected] for additional information. PURDUE UNIVERSITY GRADUATE SCHOOL Thesis/Dissertation Acceptance Kevin H. Bonanne A MODEL-BASED APPROACH TO SYSTEM-OF-SYSTEMS ENGINEERING VIA THE SYSTEMS MODELING LANGUAGE Master of Science in Aeronautics and Astronautics William Crossley Daniel DeLaurentis Saurabh Bagchi C Disclaimer (Graduate School Form ) Daniel DeLaurentis Tom Shih 06/27/2014 A MODEL-BASED APPROACH TO SYSTEM-OF-SYSTEMS ENGINEERING VIA THE SYSTEMS MODELING LANGUAGE AThesis Submitted to the Faculty of Purdue University by Kevin H. Bonanne In Partial Fulfillment of the Requirements for the Degree of Master of Science August 2014 Purdue University West Lafayette, Indiana ii To Tom, Carmella, my friends, and my family iii ACKNOWLEDGMENTS The work in this thesis would not be possible without the guidance of Dr. Daniel DeLaurentis, who has taught me and fostered my development over many years; Dr. William Crossley and Dr. Saurabh Bagchi and Bob Kenley, who served on my committee; Dr. Oleg Sindiy, who mentored me through much of my early career; Dr. Thomas McVittie and Dr. Otfrid Liepack, with whom I worked at JPL; Marc Sarrel, who showed me the delicate intricacies of SysML; Kim Simpson, who has acted as project manager for much of my technical work related to this thesis; and finally my colleagues at Purdue University, especially those in Dr. DeLaurentis’ research group, who have furthered my understanding of numerous subjects through technical discussions and their own research. iv TABLE OF CONTENTS Page LIST OF TABLES ................................ vii LIST OF FIGURES ............................... viii SYMBOLS .................................... x ABBREVIATIONS ................................ xi ABSTRACT ................................... xii 1 INTRODUCTION .............................. 1 1.1 Motivation ................................ 1 1.2 System-of-Systems ........................... 2 1.3 Model-Based Systems Engineering via the Systems Modeling Language 4 1.4 Research Objectives ........................... 5 2 BACKGROUND ............................... 9 2.1 Systems-of-Systems Engineering Wave Model ............. 9 2.2 Systems Modeling Language ...................... 11 2.3 Previous Work ............................. 13 3 SOS INITIATION & EARLY-PHASE ANALYSIS ............. 16 3.1 SoS Initiation .............................. 17 3.2 Resource Definition ........................... 19 3.3 Develop a Concept of Operations ................... 22 3.4 Application to SoS Types ....................... 26 3.4.1 Directed SoS .......................... 26 3.4.2 Acknowledged SoS ....................... 29 3.4.3 Collaborative SoS ........................ 29 3.5 Evaluation ................................ 32 3.5.1 How does SysML define systems and their features within a SoS? ............................... 32 3.5.2 How does SysML define the operations and allocate them to the systems of a SoS? ...................... 34 4 SOS ARCHITECTURE DEVELOPMENT AND EVOLUTION ..... 36 4.1 System Interactions and Networks ................... 36 4.2 Port Definition ............................. 41 4.3 Requirements on Ports ......................... 42 4.4 Integration of System Models ..................... 43 v Page 4.5 Networking with Di↵erent SoS Types ................. 49 4.5.1 Directed SoS .......................... 49 4.5.2 Acknowledged SoS ....................... 52 4.5.3 Collaborative SoS ........................ 52 4.6 Conclusions ............................... 56 4.6.1 How are alternative configurations, system sets, networks eval- uated in SysML within the SoS scope? ............ 56 4.6.2 How does SysML allow for SoS evolution? .......... 57 5 SOS PLANNING FOR UPDATES & IMPLEMENTATION ....... 59 5.1 System Analysis ............................. 59 5.2 Interface Analysis ............................ 63 5.3 Requirements Analysis ......................... 67 5.4 System Integration & Aggregate Analysis ............... 68 5.5 SoS Analysis ............................... 68 5.5.1 Directed SoS .......................... 69 5.5.2 Acknowledged SoS ....................... 71 5.5.3 Collaborative SoS ........................ 73 5.6 Updates & Implementation ....................... 75 5.7 Conclusions ............................... 76 5.7.1 What analysis methods does SysML provide for the SoS and how well does SysML execute said analysis methods? .... 76 6 CONCLUSION ................................ 79 6.1 Systems Engineering vs. SoS Engineering ............... 79 6.2 Is SysML capable of demonstrating the 8 traits of a SoS? ...... 79 6.2.1 Managerial Independence ................... 79 6.2.2 Operational Independence ................... 81 6.2.3 Evolutionary Behavior ..................... 82 6.2.4 Emergent Properties ...................... 82 6.2.5 Geographic Distribution .................... 83 6.2.6 Heterogeneity .......................... 83 6.2.7 Trans-domain Nature ...................... 83 6.2.8 Networks ............................ 84 6.3 Is SysML capable of modeling di↵erent types of SoS? ........ 86 6.4 Future Work ............................... 87 A SYSML TUTORIAL ............................. 89 B MODELING PATTERN ........................... 94 B.1 Developing the Baseline Architecture and Specialized Configurations 94 B.1.1 The use of directed associations ................ 96 B.1.2 Applying generalizations and redefinition ........... 97 B.2 Definition of System Interactions ................... 98 vi LIST OF REFERENCES ............................ 100 vii LIST OF TABLES Table Page 1.1 Comparison of Systems and Acknowledged SoS [9] ............ 7 2.1 Key SysML Elements ............................ 14 2.2 Key SysML Diagrams ........................... 14 3.1 ROPE-Scope Table for Distributed Sensor Problem ........... 18 3.2 Overview of SoS Initiation & Analysis tasks in SysML ......... 35 4.1 Overview of SoS Architecture Evolution tasks in SysML ........ 58 5.1 Overview of SoS Plan for Updates tasks in SysML ............ 78 6.1 Systems Engineering vs. SoS Engineering ................. 80 6.2 Overview of SoS Traits in SysML ..................... 85 viii LIST OF FIGURES Figure Page 1.1 Wave model for System-of-Systems Engineering ............. 5 2.1 The Vee process model for systems engineering ............. 9 2.2 A breakdown of the various viewpoints within SysML .......... 12 3.1 Block definition diagram showing the baseline hierarchy of systems within the SoS ................................... 20 3.2 Value properties and default values defined for a Radar Sensor block . 21 3.3 Example requirement on the avg. transmitted power of a Radar Sensor block, satisfied by its value property ................... 21 3.4 Functional decomposition developed for CONOPS ............ 23 3.5 Example activity flow: the allocation and flow of key activities ..... 24 3.6 Example activity flow: actions required for a radar sensor to take a mea- surement ................................... 25 3.7 Hierarchy of resources for the directed SoS architecture ......... 27 3.8 Sensor management for the directed SoS ................. 28 3.9 Hierarchy of resources for the acknowledged SoS architecture ...... 30 3.10 Hierarchy of resources for the collaborative SoS architecture ...... 31 3.11 Allocation of activities to the communication node ........... 32 4.1 Logical network diagram for the acknowledged SoS architecture .... 38 4.2 Physical network diagram for the acknowledged SoS architecture .... 39 4.3 Relation between activity diagrams and logical ports .......... 40 4.4 Requirement specifying the output of measurement data by a radar plat- form ..................................... 42 4.5 Structural decomposition of the independent radar model. ....... 44 4.6 Use case diagram showing three key use cases: search, track, and discrim- inate. .................................... 45 4.7 Activity flows for key operational modes: search, track, and discriminate 46 ix Figure Page 4.8 New radar model (ExperimentalRadar) integrated into the Acknowledged SoS. ..................................... 47 4.9 Acknowledged SoS logical network with a radar platform replaced with an experimental radar system. ........................ 48 4.10 Directed SoS logical network ........................ 50 4.11 Directed SoS physical network ....................... 51 4.12 Collaborative SoS logical network ..................... 53 4.13 Collaborative SoS physical network .................... 54 5.1 Parametric diagram showing the calculation of SNR for two sensors on a single target ................................. 61 5.2 Signal-to-noise ratio and other derived performance values for a single radar and a single target .......................... 62 5.3 Physical network diagram displaying the state of each physical connection 66 5.4 Look directions for all sensors in the Directed SoS simulation
Load more

Recommended publications
  • Managing Requirements for a System of Systems
    Orchestrating a Systems Approach Managing Requirements for a System of Systems Ivy Hooks Compliance Automation, Inc. As we encounter more system of systems (SOS) and more complex SOS, we must consider the changes that will be required of our existing processes. For example, requirements management has been focused on a system or a product. This article looks at how the SOS has evolved, including what parts of requirements management apply to the SOS and where the process will need revision. It also discusses the need for dynamic scope for the SOS and more use of standards to interface the sys- tems. Challenges definitely exist in SOS, not just in the Department of Defense but also in every aspect of the networked world. Our existing requirements management process is necessary, but not sufficient for the SOS. here is much in literature depicting ent data processing systems – one for each new systems to accomplish their mission system of systems (SOS) [1]. I will use satellite program. The person providing without reinventing the wheel or duplicat- theT characteristics Maier [2] has defined the tour had no idea why things were like ing capabilities. Writing requirements to (in boldface below), followed by my sum- they were, but I later talked to a NASA interface to these existing systems is gen- mary of each. headquarters person who explained it very erally straightforward, involving an under- 1. Operational Independence of the clearly. “Of course fewer systems would standing of what the new system must do Individual Systems. If you decom- be better, but we can’t take the risk.
    [Show full text]
  • Emergent Behavior in Systems of Systems John S
    Emergent Behavior in Systems of Systems John S. Osmundson Thomas V. Huynh Department of Information Sciences Department of Systems Engineering Naval Postgraduate School Naval Postgraduate School 1 University Circle 1 University Circle Monterey, CA 93943, USA Monterey, CA 93943, USA [email protected] [email protected] Gary O. Langford Department of Systems Engineering Naval Postgraduate School 1 University Circle Monterey, CA 93943 [email protected] Copyright © 2008 by John Osmundson, Thomas Huynh and Gary Langford. Published and used by INCOSE with permission. Abstract. As the development of systems of systems becomes more important in global ventures, so does the issues of emergent behavior. The challenge for systems engineers is to predict and analyze emergent behavior, especially undesirable behavior, in systems of systems. In this paper we briefly discuss definitions of emergent behavior, describe a large-scale system of system that exhibits emergent behavior, review previous approaches to analyzing emergent behavior, and then present a system modeling and simulation approach that has promise of allowing systems engineers to analyze potential emergent behavior in large scale systems of systems. Introduction Recently there has been increased interest in what has been become known as systems of systems (SoS) and SoS engineering. Examples of SoS are military command, control, computer, communications and information (C4I) systems (Pei 2000), intelligence, surveillance and reconnaissance (ISR) systems (Manthrope 1996), intelligence collection management systems (Osmundson et al 2006a), electrical power distribution systems (Casazza and Delea 2000) and food chains (Neutel 2002.), among others. Much of this current interest in SoS is focused on the desire to integrate existing systems to achieve new capabilities that are unavailable by operation of any of the existing single individual systems.
    [Show full text]
  • Enabling Constructs and Methods from the Field of Engineering Systems
    Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Rhodes, D.H., A.M. Ross, and D.J. Nightingale. “Architecting the system of systems enterprise: Enabling constructs and methods from the field of engineering systems.” Systems Conference, 2009 3rd Annual IEEE. 2009. 190-195. © Copyright 2009 As Published http://dx.doi.org/10.1109/SYSTEMS.2009.4815796 Publisher Institute of Electrical and Electronics Engineers Version Final published version Citable link http://hdl.handle.net/1721.1/60049 Terms of Use Article is made available in accordance with the publisher's policy and may be subject to US copyright law. Please refer to the publisher's site for terms of use. IEEE SysCon 2009 —3rd Annual IEEE International Systems Conference, 2009 Vancouver, Canada, March 23–26, 2009 Architecting the System of Systems Enterprise: Enabling Constructs and Methods from the Field of Engineering Systems Donna H. Rhodes, Adam M. Ross, and Deborah J. Nightingale Massachusetts Institute of Technology 77 Massachusetts Avenue, Building E38-572 Cambridge, MA 02139 http://seari.mit.edu Abstract. Engineering systems is a field of scholarship focused on engineering, calling for identifying “Considerations for developing fundamental theories and methods to address the SoS/Enterprise Engineering” as one of six recommended challenges of large-scale complex systems in context of their socio- research initiatives. Experts attending this workshop agreed technical environments. The authors describe facets of their recent that system-of-systems engineering and complex enterprise and ongoing research within the field of engineering systems to engineering present new challenges in identifying and develop constructs and methods for architecting enterprises engaged in system-of-systems (SoS) engineering,.
    [Show full text]
  • System-Of-Systems Viewpoint for System Architecture Documentation
    System-of-Systems Viewpoint for System Architecture Documentation John Klein∗ and Hans van Vliet† VU University, Amsterdam, Netherlands Revised 11 Nov 2017 Abstract Context: The systems comprising a system of systems (SoS) are inde- pendently acquired, operated, and managed. Frequently, the architecture documentation of these existing systems addresses only a stand-alone perspective, and must be augmented to address concerns that arise in the integrated SoS. Objective: We evaluated an architecture documentation viewpoint to address the concerns of a SoS architect about a constituent system, to support SoS design and analysis involving that constituent system. Method: We performed an expert review of documentation produced by applying the viewpoint to a system, using the active review method. Results: The expert panel was able to used a view constructed using the baseline version of the viewpoint to answer questions related to all SoS architect concerns about a constituent system, except for questions concerning the interaction of the constituent system with the platform and network infrastructure. Conclusions: We found that the expert panel was unable to answer certain questions because the baseline version of the viewpoint had a gap in coverage related to relationship of software units of execution (e.g., processes or services) to computers and networks. The viewpoint was revised to add a Deployment Model to address these concerns, and is included in an appendix. arXiv:1801.06837v1 [cs.SE] 21 Jan 2018 Keywords: architecture documentation; system of systems; viewpoint defi- nition; active review; expert panel; design cycle 1 Introduction A system of systems (SoS) is created by composing constituent systems.
    [Show full text]
  • Systems of Systems Engineering and the Internet of Things Or “Your Iot App Is Only As Good As It’S Least Stable Interface”
    Systems of Systems Engineering and the Internet of Things Or “Your IoT App is only as good as it’s least stable interface” GJ Bleakley ([email protected]) M Hause ([email protected]) Elemental Links Agenda • Introduction – What are systems of systems – The IOT as a special class of Systems of System – Perceived approach to developing IOT Systems • Architecture and Engineering the I/IoT – Challenges of I/IoT – IIC Reference Architecture – UAF Elemental Links 2 What is a SoS • A SoS is an integration of a finite number of constituent systems which are independent and operatable, and which are networked together for a period of time to achieve a certain higher goal. (Jamshidi 2009) 3 Systems vs. Enterprise vs. SoS • System Engineering is like specifying a building, e.g. a swimming pool • Enterprise Architecture is like urban planning • – Need for the swimming pool driven by council/government health objectives • The Swimming Pool is only part of the solution • Other means to reach the objective, e.g.. running tracks, cycle lanes • Need to integrate these solutions into existing services • Provide service infrastructure to support and maintain them Elemental• EA Links is about managing and developing Systems of Systems 4 Example: Traffic Management Case Study Scenarios (from DANSE) •Trip Preparations •City traffic – Interactions with other autonomous cars – Interactions with pedestrians – Overtaking Situations •Autonomous Parking •Public Driverless Taxi •PDL back to the airport •Private Car comes home •Billing Elemental Links 5 traits of SoS – Maier (2+3) • Operational independence – The constituent systems can operate independently from the SoS and other systems.
    [Show full text]
  • Systems Engineering Guide: 7 Considerations for Systems Engineering 8 in a System of Systems Environment 9 10 11
    1 2 3 4 5 System of Systems 6 Systems Engineering Guide: 7 Considerations for Systems Engineering 8 in a System of Systems Environment 9 10 11 12 13 14 15 16 17 18 19 20 21 Version 1.0 DRAFT 22 14 December 2007 23 24 25 26 27 28 29 30 Director, Systems and Software Engineering 31 Deputy Under Secretary of Defense (Acquisition and Technology) 32 Office of the Under Secretary of Defense 33 (Acquisition, Technology and Logistics) 34 35 1 36 Preface 37 38 The Department of Defense (DoD) continually seeks to acquire material solutions to 39 address capability needs of the war fighter in military operations and to provide efficient 40 support and readiness in peacetime. A growing number of these capabilities are 41 achieved through a system of systems (SoS) approach. As defined in the DoD Defense 42 Acquisition Guidebook [2004], an SoS is “a set or arrangement of systems that results 43 when independent and useful systems are integrated into a larger system that delivers 44 unique capabilities.” 45 46 Systems engineering (SE) is a key enabler of systems acquisition. SE practices and 47 approaches historically have been described with a single system rather than an SoS in 48 mind. This guide examines the SoS environment as it exists in the DoD today and the 49 challenges it poses for systems engineering. Specifically, the guide addresses the 16 50 DoD Technical Management Processes and Technical Processes presented in the 51 Defense Acquisition Guidebook [2004] Chapter 4 “Systems Engineering” in the context 52 of SoS.
    [Show full text]
  • LNCS 4561, Pp
    Role of Humans in Complexity of a System-of-Systems Daniel DeLaurentis School of Aeronautics and Astronautics, Purdue University, West Lafayette, IN, USA [email protected] Abstract. This paper pursues three primary objectives. First, a brief introduc- tion to system-of-systems is presented in order to establish a foundation for ex- ploration of the role of human system modeling in this context. Second, the sources of complexity related to human participation in a system-of-systems are described and categorized. Finally, special attention is placed upon how this complexity might be better managed by greater involvement of modeling of human behavior and decision-making. The ultimate objective of the research thrust is to better enable success in the various system-of-systems that exist in society. Keywords: system-of-systems, complexity, human behaviors, connectivity. 1 Introduction A system-of-systems (SoS) consist of multiple, heterogeneous, distributed, occasion- ally independently operating systems embedded in networks at multiple levels that evolve over time. While the moniker may be recent, the notion of a “system-of- systems” is not new. There have been and still are numerous examples of collections of systems that rely upon the interaction of multiple, but independently operating, sys- tems. Ground and air transportation, energy, and defense are high profile examples. These existed before the phrase “system-of-systems” entered common use, have been studied extensively through several fields of inquiry, but rarely have been examined as a distinct problem class. In recent years, the formal study of systems-of-systems has increased in importance, driven largely by the defense and aerospace industries, where the government’s procurement approach has changed.
    [Show full text]
  • System of Systems Integration Technology & Experimentation
    System of Systems Integration Technology & Experimentation (SoSITE) Architecting Composable-SoS Configurations Justin Taylor Abstract # 18869 Lockheed Martin Aeronautics 27 October 2016 Skunk Works Program Manager This research was developed with funding from the Defense Advanced Research Projects Agency (DARPA). The views, opinions and/or findings expressed are those of the author and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited. Architecting Composable-SoS Configurations A System Architect & Integrator’s Perspective Requirements SoS Allocation System Composition Delivery Requirements Decomposition Source: Systems Engineering Guide for Systems of Systems v1.0, August 2008 • Background: DoD has long relied on tightly integrated weapons platforms using top-down requirements allocation • Challenge for a SoS-Architect: When the environment changes, must employ systems in unplanned ways – Must be able to plug them together – Must have confidence that they satisfy the mission • Implication on Constituent Systems: Must provide broad characterization to support SoS-Architect DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited. 2 Integrated Analytic Framework IAF Cost Analytically Multiple Valid Solutions Research Combine to Accomplish the Mission Datasets Increased Autonomy Constructive Military Utility, Cost Leverage Sim Analysis Increased Increased Multi- Quantity
    [Show full text]
  • A Framework for Enterprise Systems Engineering Processes
    A Framework for Enterprise Systems Engineering Processes Dr. Robert S. Swarz Dr. Joseph K. DeRosa Tel: +1 781-271-2847 Tel: +1 781-271-3332 Email: [email protected] Email: [email protected] Fax: +1 781-271-2841 Fax: +1 781-271-3803 The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 U.S.A. Abstract: In this paper, we describe how traditional systems engineering processes, such as those delineated in the ANSI//EIA 632 standard, are becoming inadequate for today’s complex systems, in which there is a rich set of interconnections and interrelationships between all of the systems in an enterprise. We further suggest that a new discipline (or an extension of the old discipline) is developing in response, called Enterprise Systems Engineering (ESE). We next explain some salient characteristics of complex adaptive systems and motivate how these properties, such as variation, interaction, and selection can be used to shape the evolution of the enterprise. We outline five important new processes: Technology Planning, Capability-Based Engineering Analysis, Enterprise Architecture, Strategic Technical Planning, and Enterprise Analysis and Assessment that can be used to exercise a degree of control beyond that which can be afforded by traditional means. Key words: Enterprise Systems Engineering, Evolution, Variety, Selection, Process, Enterprise Architecture, Capabilities ICSSEA 2006 Swarz & Derosa 1. INTRODUCTION In 1999, the Electronic Industries Alliance (EIA) published their Processes for Engineering a System. This has become an American National Standard (ANSI/EIA 632), and is consistent with the approach being taken by the International Standards Organization’s standard ISO 15288. In addition, the Institute of Electrical and Electronics Engineers (IEEE) standard 1220 represents an application of EIA 632 to the electronics and electrical industry.
    [Show full text]
  • Mobility Aircraft Interoperability in a Multi
    MOBILITY AIRCRAFT INTEROPERABILITY IN A MULTI-DOMAIN ENVIRONMENT (A/TA SEMINAR BRIEF) Daniel Malloy LM Aero SoSITE Program Manager LM Aero ADP [email protected] Distribution Statement “A” (Approved for Public Release, Distribution Unlimited) REALIZING MULTI-DOMAIN DISTRIBUTED ARCHITECTURE • Multi-Domain Operations (MDO) require increased warfighter speed in DATA TO DECISION - Platforms need to be interoperable in a dynamic Command & Control (C2) architecture - Operations based on heterogenous distributed platforms, sensors, weapons, and applications - Decision making is distributed across the battlespace • Datalink communications, machine-to-machine information exchange, and automated/autonomous decision aids are key enablers for realizing this MDO architecture • USAF is developing and maturing foundational technology through flight test demonstrations to realize MDO sooner than thought possible • Two key MDO enabling technologies: - FLEXIBLE AUTONOMY FRAMEWORK to enable enhanced Situational Awareness (SA) and mission management (C2) with minimum impact on Pilot/Operator workload - “STITCHES” technology developed under DARPA's SoSITE Program to enable interoperability Distribution Statement “A” (Approved for Public Release, Distribution Unlimited) MULTI-DOMAIN OPERATIONS (MDO) VISION Involves Multi-Domain Every Node Connects To Produce High-velocity, Planning…and Execution – Shares – Learns operationally agile ops that present multiple dilemmas for an adversary at an operational tempo they cannot match Multi-Domain Operations: Warfare
    [Show full text]
  • 18 Systems of Systems Engineering: Basic Concepts, Model-Based
    Systems of Systems Engineering: Basic Concepts, Model-Based Techniques, and Research Directions 18 CLAUS BALLEGAARD NIELSEN, Aarhus University PETER GORM LARSEN, Aarhus University JOHN FITZGERALD, Newcastle University JIM WOODCOCK,UniversityofYork JAN PELESKA, University of Bremen The term “System of Systems” (SoS) has been used since the 1950s to describe systems that are composed of independent constituent systems, which act jointly towards a common goal through the synergism between them. Examples of SoS arise in areas such as power grid technology, transport, production, and military enterprises. SoS engineering is challenged by the independence, heterogeneity, evolution, and emergence properties found in SoS. This article focuses on the role of model-based techniques within the SoS engineering field. A review of existing attempts to define and classify SoS is used to identify several dimensions that characterise SoS applications. The SoS field is exemplified by a series of representative systems selected from the literature on SoS applications. Within the area of model-based techniques the survey specifically reviews the state of the art for SoS modelling, architectural description, simulation, verification, and testing. Finally, the identified dimensions of SoS characteristics are used to identify research challenges and future research areas of model-based SoS engineering. Categories and Subject Descriptors: H.1.1 [Systems and Information Theory]: General Systems The- ory; I.6.0 [Simulation and Modelling]: General; F.4.0 [Mathematical Logic and Formal Languages]: General General Terms: Design, Languages Additional Key Words and Phrases: System of systems, systems engineering, model-based engineering ACM Reference Format: Claus Ballegaard Nielsen, Peter Gorm Larsen, John Fitzgerald, Jim Woodcock, and Jan Peleska.
    [Show full text]
  • Engineering Elegant Systems: Theory of Systems Engineering
    National Aeronautics and NASA/TP–20205003644 Space Administration IS02 George C. Marshall Space Flight Center Huntsville, Alabama 35812 Engineering Elegant Systems: Theory of Systems Engineering M.D. Watson Marshall Space Flight Center, Huntsville, Alabama B.L. Mesmer and P.A. Farrington The University of Alabama in Huntsville, Huntsville, Alabama June 2020 The NASA STI Program…in Profile Since its founding, NASA has been dedicated to the • CONFERENCE PUBLICATION. Collected advancement of aeronautics and space science. The papers from scientific and technical conferences, NASA Scientific and Technical Information (STI) symposia, seminars, or other meetings sponsored Program Office plays a key part in helping NASA or cosponsored by NASA. maintain this important role. • SPECIAL PUBLICATION. Scientific, technical, The NASA STI Program Office is operated by or historical information from NASA programs, Langley Research Center, the lead center for projects, and mission, often concerned with NASA’s scientific and technical information. The subjects having substantial public interest. NASA STI Program Office provides access to the NASA STI Database, the largest collection of • TECHNICAL TRANSLATION. aeronautical and space science STI in the world. English-language translations of foreign The Program Office is also NASA’s institutional scientific and technical material pertinent to mechanism for disseminating the results of its NASA’s mission. research and development activities. These results are published by NASA in the NASA STI Report Specialized services that complement the STI Series, which includes the following report types: Program Office’s diverse offerings include creating custom thesauri, building customized databases, • TECHNICAL PUBLICATION. Reports of organizing and publishing research results…even completed research or a major significant providing videos.
    [Show full text]