Systems-within-systems: a unifying perspective Wayne J. Davis Professor Emeritus Industrial and Enterprise Systems Engineering University of

Slides:



Advertisements
Similar presentations
Time averages and ensemble averages
Advertisements

Priority INHERITANCE PROTOCOLS
Lect.3 Modeling in The Time Domain Basil Hamed
SHOP2: An HTN Planning System Nau, D.S., Au, T.C., Ilghami, O., Kuter, U., Murdock, J.W., Wu, D. and Yaman, F. (2003) "SHOP2: An HTN Planning System",
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 12Slide 1 Software Design l Objectives To explain how a software design may be represented.
By Philippe Kruchten Rational Software
Chapter 4 - Object-Oriented Analysis and Design in a Nutshell1 Chapter 4 Object-Oriented Analysis and Design in a Nutshell.
Systems Engineering in a System of Systems Context
CS 325: Software Engineering April 7, 2015 Software Configuration Management Task Scheduling & Prioritization Reporting Project Progress Configuration.
1 Software Testing and Quality Assurance Lecture 12 - The Testing Perspective (Chapter 2, A Practical Guide to Testing Object-Oriented Software)
Domain-Specific Software Engineering (DSSE). Software Engineering Concerns  There are many of them  “Classical” software architecture research has focused.
1 Learning from Behavior Performances vs Abstract Behavior Descriptions Tolga Konik University of Michigan.
CS 425/625 Software Engineering System Models
Chapter 21 Object-Oriented Analysis
© Copyright Eliyahu Brutman Programming Techniques Course.
Dynamic Optimization Dr
Motor Control Theories
UML and Object Oriented Concepts
Unified Modeling Language
Definition of an Industrial Robot
MobSched: An Optimizable Scheduler for Mobile Cloud Computing S. SindiaS. GaoB. Black A.LimV. D. AgrawalP. Agrawal Auburn University, Auburn, AL 45 th.
An Introduction to Software Architecture
Christian Heinzemann 11. Oktober 2015 Modeling Behavior of Self-Adaptive Systems Seminar Software Quality and Safety.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
1 Introduction to Software Engineering Lecture 1.
9-1 © Prentice Hall, 2004 Chapter 9: Analysis Classes Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich, Jeffrey.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
Introduction to OOAD and the UML
BPEL Business Process Engineering Language A technology used to build programs in SOA architecture.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
Chapter 2 Object-Oriented Paradigm Overview. Getting Acquainted with the Class Project Read the requirements specification carefully Make note of any.
CS3773 Software Engineering Lecture 06 UML State Machines.
Methodology First and Language Second -A Way to Teach Object-Oriented Programming Haibin Zhu, PhD Department of Computer Science and Mathematics Nipissing.
Object-Oriented Programming © 2013 Goodrich, Tamassia, Goldwasser1Object-Oriented Programming.
Week 04 Object Oriented Analysis and Designing. What is a model? A model is quicker and easier to build A model can be used in simulations, to learn more.
Technical Seminar Presentation 2004 Presented by- Geetanjali Konhar EE O81 1 Dynamic power management for embedded system “ Dynamic power management.
Chapter 5 System Modeling. What is System modeling? System modeling is the process of developing abstract models of a system, with each model presenting.
Quantum New way of looking at our world. Classical vs Quantum Typically a student develops an intuition about how the world works using classical mechanics.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
1 Chapter 1 Introduction to Differential Equations 1.1 Introduction The mathematical formulation problems in engineering and science usually leads to equations.
CS 5150 Software Engineering Lecture 16 Program Design 3.
Chapter 4 Motor Control Theories Concept: Theories about how we control coordinated movement differ in terms of the roles of central and environmental.
Fall 2007 Week 9: UML Overview MSIS 670: Object-Oriented Software Engineering.
École Doctorale des Sciences de l'Environnement d’Île-de-France Année Universitaire Modélisation Numérique de l’Écoulement Atmosphérique et Assimilation.
Basic Concepts of Software Architecture. What is Software Architecture? Definition: – A software system’s architecture is the set of principal design.
Leading in a Complex Healthcare Environment
Chapter 2 Object-Oriented Paradigm Overview
Analysis Classes Unit 5.
CHAPTER
Virtual memory.
Chapter 1: Introduction to Systems Analysis and Design
Object-Oriented Analysis and Design
Unified Modeling Language
CS 325: Software Engineering
Wireless Sensor Network Architectures
Hierarchical Finite State Controllers for Generalized Planning
ISCOM 370 Competitive Success/snaptutorial.com
ISCOM 370 Education for Service- -snaptutorial.com
ISCOM 370 Teaching Effectively-- snaptutorial.com
Chapter 20 Object-Oriented Analysis and Design
CSE403 Software Engineering Autumn 2000 Design (Overview)
An Introduction to Software Architecture
Chapter 1: Introduction to Systems Analysis and Design
David Botzer and Opher Etzion
Chapter 1: Introduction to Systems Analysis and Design
Introduction to OOAD and the UML
The Theory and Computation of
Presentation transcript:

Systems-within-systems: a unifying perspective Wayne J. Davis Professor Emeritus Industrial and Enterprise Systems Engineering University of

Past Future (a) Past Future (b) Past Future (c) (a)Physical process evolves in real time. Blue dot indicates current state, tail its observed trajectory (b)Process controller resides in the future. It cannot access the present: it observes immediate past as it attempts to influence the imminent future Its planning seeks the trajectory from last observed state toward a future goal state Often goal state corresponds to end of an assigned task

Past Future (a) Past Future (b) Past Future (c) (c) Multiple physical processes evolve concurrently in real time Each process exists independently in real world Each process has a dedicated controller that projects its future state at a common future time These projections evolve in real time as additional observations are made

(d) Process controllers’ projected states at a common future time are aggregated into an initial planning state for a composite planner Planner seeks trajectory from aggregated future state toward an assigned future goal state Both boundary states are time-variant The planned trajectory must be dynamic also Planning is a process, not a task Past Future

(d) Continued Planners’ response initiates from and thus contains the processes’ response Planner relies upon processes to implement its prior plans==>planner cannot execute its plan Processes are not subordinate to planner Planner does not exist with its processes Past Future

(e) Continued Additional processes are included and aggregated to specify initial planning states for two planners In this example, two planners share middle process This is not a hierarchy Past Future (e)

(f) The two planners behave as aggregate process encapsulating the responses of their contained processes. Another planner initializes its planning from their projected states at a common time Aggregated processes execute this planner’s prior plans Past Future (f)

(f) Continued Recursive structure is revealed All planners behave the same Past Future (f)

Critical observation One: All systems have a primal and dual configurations Primal system configuration: fix state definition and describe state evolution as function of time Dual system configuration: Fix time and describe transitions among coupled state definitions Past Future (f)

Critical observation Two: Super-symmetry Both primal and dual formulations have their dedicated primal and dual formulations Traditional planning only considers the primal formulation of the primal configuration between two time-variant future states Past Future (f)

Critical observation Three: Planning is a process, not a task Equilibration replaces optimization Equilibration underlies energy analyses within classical mechanics Past Future (f)

Major conclusion: Trajectory planning includes three components Identifying trajectory between two future states Collaborate with its executors to plan the initial state from which it will initialize its planning Collaborate with planners with which its goal state is coupled For time-variant systems there are other modes of concurrent “optimizations” to be addressed collaboratively in real time.

Additional accomplishment: Unify classical mechanics, controls and optimization Temporally unify past and future with the present instantiates imminent future into immediate past Mathematical formulations for linear, nonlinear and discrete-event systems exist