Systems Engineering Guide for Systems of Systems, Version 1.0
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Capabilities in Systems Engineering: an Overview
Capabilities in Systems Engineering: An Overview Gon¸caloAntunes and Jos´eBorbinha INESC-ID, Rua Alves Redol, 9 1000-029 Lisboa Portugal {goncalo.antunes,jlb}@ist.utl.pt, WWW home page: http://web.ist.utl.pt/goncalo.antunes Abstract. The concept of capability has been deemed relevant over the years, which can be attested by its adoption in varied domains. It is an abstract concept, but simple to understand by business stakeholders and yet capable of making the bridge to technical aspects. Capabilities seem to bear similarities with services, namely their low coupling and high cohesion. However, the concepts are different since the concept of service seems to rest between that of capability and those directly related to the implementation. Nonetheless, the articulation of the concept of ca- pability with the concept of service can be used to promote business/IT alignment, since both concepts can be used to bridge different concep- tual layers of an enterprise architecture. This work offers an overview of the different uses of this concept, its usefulness, and its relation to the concept of service. Key words: capability, service, alignment, information systems, sys- tems engineering, strategic management, economics 1 Introduction The concept of capability can be defined as \the quality or state of being capable" [19] or \the power or ability to do something" [39]. Although simple, it is a powerful concept, as it can be used to provide an abstract, high-level view of a product, system, or even organizations, offering new ways of dealing with complexity. As such, it has been widely adopted in many areas. -
Existing Cybernetics Foundations - B
SYSTEMS SCIENCE AND CYBERNETICS – Vol. III - Existing Cybernetics Foundations - B. M. Vladimirski EXISTING CYBERNETICS FOUNDATIONS B. M. Vladimirski Rostov State University, Russia Keywords: Cybernetics, system, control, black box, entropy, information theory, mathematical modeling, feedback, homeostasis, hierarchy. Contents 1. Introduction 2. Organization 2.1 Systems and Complexity 2.2 Organizability 2.3 Black Box 3. Modeling 4. Information 4.1 Notion of Information 4.2 Generalized Communication System 4.3 Information Theory 4.4 Principle of Necessary Variety 5. Control 5.1 Essence of Control 5.2 Structure and Functions of a Control System 5.3 Feedback and Homeostasis 6. Conclusions Glossary Bibliography Biographical Sketch Summary Cybernetics is a science that studies systems of any nature that are capable of perceiving, storing, and processing information, as well as of using it for control and regulation. UNESCO – EOLSS The second title of the Norbert Wiener’s book “Cybernetics” reads “Control and Communication in the Animal and the Machine”. However, it is not recognition of the external similaritySAMPLE between the functions of animalsCHAPTERS and machines that Norbert Wiener is credited with. That had been done well before and can be traced back to La Mettrie and Descartes. Nor is it his contribution that he introduced the notion of feedback; that has been known since the times of the creation of the first irrigation systems in ancient Babylon. His distinctive contribution lies in demonstrating that both animals and machines can be combined into a new, wider class of objects which is characterized by the presence of control systems; furthermore, living organisms, including humans and machines, can be talked about in the same language that is suitable for a description of any teleological (goal-directed) systems. -
Introduction to Cybernetics and the Design of Systems
Introduction to Cybernetics and the Design of Systems © Hugh Dubberly & Paul Pangaro 2004 Cybernetics named From Greek ‘kubernetes’ — same root as ‘steering’ — becomes ‘governor’ in Latin Steering wind or tide course set Steering wind or tide course set Steering wind or tide course set Steering wind or tide course set correction of error Steering wind or tide course set correction of error Steering wind or tide course set correction of error correction of error Steering wind or tide course set correction of error correction of error Steering wind or tide course set correction of error correction of error Cybernetics named From Greek ‘kubernetes’ — same root as ‘steering’ — becomes ‘governor’ in Latin Cybernetic point-of-view - system has goal - system acts, aims toward the goal - environment affects aim - information returns to system — ‘feedback’ - system measures difference between state and goal — detects ‘error’ - system corrects action to aim toward goal - repeat Steering as a feedback loop compares heading with goal of reaching port adjusts rudder to correct heading ship’s heading Steering as a feedback loop detection of error compares heading with goal of reaching port adjusts rudder feedback to correct heading correction of error ship’s heading Automation of feedback thermostat heater temperature of room air Automation of feedback thermostat compares to setpoint and, if below, activates measured by heater raises temperature of room air The feedback loop ‘Cybernetics introduces for the first time — and not only by saying it, but -
Need Means Analysis
The Systems Engineering Tool Box Dr Stuart Burge “Give us the tools and we will finish the job” Winston Churchill Needs Means Analysis (NMA) What is it and what does it do? Needs Means Analysis (NMA) is a systems thinking tool aimed at exploring alternative system solutions at different levels in order to help define the boundary of the system of interest. It is based around identifying the “need” that a system satisfies and using this to investigate alternative solutions at levels higher, the same and lower than the system of interest. Why do it? At any point in time there is usually a “current” or “preferred” solution to a particular problem. In consequence organizations will develop their operations and infrastructure to support and optimise that solution. This preferred solution is known as the Meta-Solution. For example Toyota, Ford, General Motors, Volkswagen et al all have the same meta-solution when it comes to automobile – in simple terms two-boxes with wheel at each corner. All of the automotive companies have slowly evolved in to an industry aimed at optimising this meta-solution. Systems Thinking encourages us to “step back” from the solution to consider the underlying problem or purpose. In the case of an automobile, the purpose is to “transport passengers and their baggage from one point to another” This is also the purpose of a civil aircraft, passenger train and bicycle! In other words for a given purpose there are alternative meta-solutions. The idea of a pre-eminent meta-solution has also been discussed by Pugh (1991) who introduced the idea of dynamic and static design concepts. -
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. -
Collection System Manager
CITY OF DALY CITY JOB SPECIFICATION EXEMPT POSITION COLLECTION SYSTEM MANAGER DEFINITION Under the general direction of the Director of Water and Wastewater Resources or authorized representative, supervises all activities of the Collection System Maintenance Division, including wastewater collection and recycled water systems, and performs other duties as assigned. EXAMPLES OF DUTIES Manage, supervise, schedule, and review the work of maintenance personnel in the maintenance, inspection and repair of wastewater collection and recycled water distribution systems in the Collection System Maintenance Division of the Department of Water and Wastewater Resources; ensure safe, efficient and effective compliance with local, state and federal laws, rules and regulations, and industrial practices. Implement City, Department and Division Rules and Regulations, policies, procedures and practices. Ensure that required records are accurately maintained. Oversee a comprehensive preventive maintenance program of facilities. Ensure that supervisors conduct regular safety training and maintain a safe work environment. Develop and maintain training programs for employees; ensure that employees maintain required certification. Formally evaluate or ensure the evaluation and satisfactory job performance of assigned employees. Manage crews in support of City departments in maintenance operations, such as the storm drain collection system maintenance and construction program. Work to complete Department and Division goals and objectives. Prepare and manage the Division budget; propose, develop and manage capital projects and manage contracts for the Division. Prepare reports, and make presentations to the City Manager, City Council or others as required. When required, maintain 24-hour availability to address Division emergencies. Develop and maintain good working relationships with supervisors, coworkers, elected officials, professional peer groups and the public. -
Rocket D3 Database Management System
datasheet Rocket® D3 Database Management System Delivering Proven Multidimensional Technology to the Evolving Enterprise Ecient Performance: C#, and C++. In addition, Java developers can access Delivers high performance via Proven Technology the D3 data files using its Java API. The MVS Toolkit ecient le management For over 30 years, the Pick Universal Data Model (Pick provides access to data and business processes via that requires minimal system UDM) has been synonymous with performance and and memory resources both SOAP and RESTful Web Services. reliability; providing the flexible multidimensional Scalability and Flexibility: database infrastructure to develop critical transac- Scales with your enterprise, tional and analytical business applications. Based on from one to thousands of Why Developers the Pick UDM, the Rocket® D3 Database Manage- users ment System offers enterprise-level scalability and Choose D3 D3 is the choice of more than a thousand applica- Seamless Interoperability: efficiency to support the dynamic growth of any tion developers world-wide—serving top industries Interoperates with varied organization. databases and host including manufacturing, distribution, healthcare, environments through government, retail, and other vertical markets. connectivity tools Rapid application development and application Rocket D3 database-centric development environ- customization requires an underlying data structure Data Security: ment provides software developers with all the that can respond effectively to ever-changing Provides secure, simultaneous necessary tools to quickly adapt to changes and access to the database from business requirements. Rocket D3 is simplistic in its build critical business applications in a fraction of the remote or disparate locations structure, yet allows for complex definitions of data time as compared to other databases; without worldwide structures and program logic. -
Putting Systems to Work
i PUTTING SYSTEMS TO WORK Derek K. Hitchins Professor ii iii To my beloved wife, without whom ... very little. iv v Contents About the Book ........................................................................xi Part A—Foundation and Theory Chapter 1—Understanding Systems.......................................... 3 An Introduction to Systems.................................................... 3 Gestalt and Gestalten............................................................. 6 Hard and Soft, Open and Closed ............................................. 6 Emergence and Hierarchy ..................................................... 10 Cybernetics ........................................................................... 11 Machine Age versus Systems Age .......................................... 13 Present Limitations in Systems Engineering Methods............ 14 Enquiring Systems................................................................ 18 Chaos.................................................................................... 23 Chaos and Self-organized Criticality...................................... 24 Conclusion............................................................................ 26 Chapter 2—The Human Element in Systems ......................... 27 Human ‘Design’..................................................................... 27 Human Predictability ........................................................... 29 Personality ............................................................................ 31 Social -
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. -
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,. -
Fundamentals of Systems Engineering
Fundamentals of Systems Engineering Prof. Olivier L. de Weck Session 12 Future of Systems Engineering 1 2 Status quo approach for managing complexity in SE MIL-STD-499A (1969) systems engineering SWaP used as a proxy metric for cost, and dis- System decomposed process: as employed today Conventional V&V techniques incentivizes abstraction based on arbitrary do not scale to highly complex in design cleavage lines . or adaptable systems–with large or infinite numbers of possible states/configurations Re-Design Cost System Functional System Verification Optimization Specification Layout & Validation SWaP Subsystem Subsystem . Resulting Optimization Design Testing architectures are fragile point designs SWaP Component Component Optimization Power Data & Control Thermal Mgmt . Design Testing . and detailed design Unmodeled and undesired occurs within these interactions lead to emergent functional stovepipes behaviors during integration SWaP = Size, Weight, and Power Desirable interactions (data, power, forces & torques) V&V = Verification & Validation Undesirable interactions (thermal, vibrations, EMI) 3 Change Request Generation Patterns Change Requests Written per Month Discovered new change “ ” 1500 pattern: late ripple system integration and test 1200 bug [Eckert, Clarkson 2004] fixes 900 subsystem Number Written Number Written design 600 major milestones or management changes component design 300 0 1 5 9 77 81 85 89 93 73 17 21 25 29 33 37 41 45 49 53 57 61 65 69 13 Month © Olivier de Weck, December 2015, 4 Historical schedule trends -
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.