DOCSLIB.ORG

Informatics As a Science 1 Viewpoint

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Informatics As a Science 1 Viewpoint Enterprise Modelling and Information Systems Architectures Vol. 15, No. 6 (2020). DOI:10.18417/emisa.15.6 Informatics as a Science 1 Viewpoint Informatics as a Science Wolfgang Reisig Humboldt-Universität zu Berlin, Berlin, Germany Abstract. This contribution addresses the quest for a framework for a comprehensive science of “informatics” as a formal theory of discrete dynamic systems, in analogy to the model of natural sciences. A variety of examples show that this endeavor is promising indeed, and that (detached) parts of it exist already. In the long run, informatics may evolve as a self-contained science, more comprehensive than nowadays “Computer Science”, by complementing its strong technological aspects with a consistent theoretical, mathematical basis, on an equal footing with natural sciences. Keywords. comprehensive science of informatics • formal foundations • modeling Communicated by Peter Fettke. Received 2019-08-30. Accepted on 2020-01-20. Introduction of promotion and reward, that don’t support fun- damental questions on the nature of informatics.1 Background In this situation it appears nevertheless inter- Computer Science is frequently told as a success esting to pose some fundamental questions and story, driven by Moore’s law: during the last six to discuss aspects that could unify the diverging decades; computation-, information- and commu- subdomains of Computer Science. As a basis for nication technology became exponentially cheaper, a science of informatics, this may render future quicker and smaller (Brock 2006). Accordingly, developments quicker and better comprehensible. new application areas evolved. Systemic mal- function of devices, failed projects, unmanageable Informatics as a science: historical development behavior of computer embedded systems, viola- tion of privacy etc., are accepted as unavoidable The emerging computing technology of the side effects and justified as the price to be paid for 1950ies covered essentially two problem domains: the rapid evolution of the area. numerical problems as they occur in classical engineering sciences, and searching-and-sorting Whether matters might – or should – have problems in large data sets, as they occur in a evolved differently, is rarely discussed and hardly population census. The two programming lan- suspected. The quest for alternatives to the factual guages FORTRAN and COBOL had been tailored evolution of Computer Science is annoying in par- to those problems; the steps from a problem to an ticular for young scientists, who eagerly learned algorithmic idea and to a program were usually facts, and want to build on this presumed solid manageable. This changed in the 1960ies: in- and steadfast basis. They are squeezed in systems creasing computer power made problems solvable that required more complex algorithmic ideas and E-mail. [email protected] more elaborate programs. This rendered programs I owe many valuable comments to readers of a previous German version of this text: Dines Bjørner, Peter Fettke, 1 By “Computer Science” we refer to the traditional approach, Christoph Freytag, and Otthein Herzog. whereas “informatics” denotes the to-be-developed science. International Journal of Conceptual Modeling Vol. 15, No. 6 (2020). DOI:10.18417/emisa.15.6 2 Wolfgang Reisig Viewpoint increasingly error prone and incomprehensible, • Prediction: Good science can predict the evo- and finally a “software crisis” had been identified lution of processes. In Computer Science, this at a famous conference in Garmisch-Partenkirchen means to predict the behavior of programs, i. e. (Naur and Randell 1969), to be tackled by the new to verify them. discipline of “software engineering”. This in turn caused new programming languages (PL/1, Pas- Summing up, a program is conceived as a math- cal, Ada), new program paradigms (structured ematical item; its decisive properties should be programming, object orientation) and later on formulated in a logical language, its semantics new software architectures (components, service- should be formally captured, and its correctness orientation, micro-services). Furthermore, soft- should be proved. These are scientific concepts, ware design methodologies emerged, such as sys- indeed. In this spirit, also Gries (1981) conceives tematic refinement, software architectures, and the activity of programming as a scientific activity. the specification of interfaces. Looking back, it is obvious that the Garmisch- Partenkirchen conference raised important ques- This contribution tions and initiated constructive answers. However, on the long way from a problem via an algorith- In 14 sections we formulate some thoughts for a mic idea up to a software, only the last step, i. e. comprehensive science of informatics as a formal writing down programs, has been framed more scientific theory of discrete dynamic systems. The convenient by the concepts suggested there. subject of this science is intended much broader This way of thinking about “Computer Science” than the above outlined traditional “Computer as a science is visible at the memorial lecture Science”, as suggested by Dijkstra, Hoare, Gries, for famous Edsger W. Dijkstra in 2010, where Knuth and others. Nevertheless, the new, broader likewise famous computer scientist Tony Hoare theory should be conceptualized as a formal the- emphasizes four criteria for sciences in general, ory; not as classical Computer Science extended and the issue of Computer Science in particular by informal aspects of social sciences. Examples (Hoare 2010): include formal concepts of information processing and algorithmic behavior that are not intended to • Description: Science describes properties and behavior of systems; in Computer Science, such be implemented, as they occur in business infor- a “description of properties and behavior can matics, in embedded systems, and generally in serve as a specification, describing an appro- the nowadays much discussed “internet of every- priately precise interface between its purchaser thing”. and its supplier.” Hoare suggests logic based de- We will pose questions and explain some mu- scription methods, with weakest preconditions tually related concepts. Some of them are not as an example. fundamentally new, but have frequently been stud- • Analysis: The central items and their conceptual ied in isolation. Properly combined, they support relation of a science are detailed here. Central the claim to contribute to a new science of infor- items of Computer Science are programs. They matics. are analyzed with pre-/postconditions such as However, we don’t present a fully-fledged sci- Microsoft Contracts. ence of informatics. Obviously, a number of • Explanation: The behavior of systems is sub- additional ideas, concepts and insight is still miss- stantiated. For Computer Science, the seman- ing. We just want to show that it is worth searching tics of programming languages provides this for a fundamental science of informatics, and to substantiation. stimulate discussion. Enterprise Modelling and Information Systems Architectures Vol. 15, No. 6 (2020). DOI:10.18417/emisa.15.6 Informatics as a Science 3 Viewpoint 1 Successful construction of scientific equations, integrals, etc. In contrast, informatics models describes behavior in discrete steps. This allows to describe entirely different properties, and requires Good scientific theory is formulated in terms of different analysis techniques. models. A model is a system of notions and Models in informatics are used for various dif- relations among them, intended to better under- ferent purposes: stand reality. “Reality” is either given as natural phenomena, or – as in the case of informatics – • to describe domain-specific facts, for example constructed by man. Particularly impressive is a companies’ structure of the book keeping and the example of physics: For centuries, physicists the accounting department (the “correctness” searched a unifying model for all branches of of this kind of descriptions remains inevitably physics, setting up an impressive body of scien- informal); tific theory. Particularly impressive is the deep • to describe algorithmic behavior, for example harmony between physics and mathematics (Livio how to apply for a claim settlement with an 2009) with very abstract, yet exceedingly useful insurance company; scientific concepts and models. A typical example • to describe a software’s effect, either in terms is the notion of energy. This notion allows to mutually relate and quantitatively fix quite dif- of properties or of its operational behavior. ferent phenomena that, for example, occur when A model is a symbolic description. It may be a car is accelerated and crashed into a wall: In executable on the symbolic level, in which case this process, an amount of energy is involved. It its behavior can be simulated on a computer. But is initially contained in petrol, then in accelera- it also may conceptually describe the behavior tion, and finally in reshaping metal. The notion of a system in a concrete domain, that is not of “energy” is useful because it provides a quan- intended to be implemented. With a really useful tifying invariance for dynamic processes. This science of informatics it will be worthwhile to kind of invariants, usually denoted as “laws of discuss correctness on the model level and then to nature”, are the scaffold of science. In recent systematically derive correct software. years, systems biology likewise is searching for Seamless integration of computing technology
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.
    [Show full text]
  • 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.
    [Show full text]
  • Design of Instructional Modeling Language for Learning Objects and Learning Objectsâ•Ž Repositories
    University of Northern Colorado Scholarship & Creative Works @ Digital UNC Dissertations Student Research 8-2019 Design of Instructional Modeling Language for Learning Objects and Learning Objects’ Repositories Altaf Siddiqui Follow this and additional works at: https://digscholarship.unco.edu/dissertations Recommended Citation Siddiqui, Altaf, "Design of Instructional Modeling Language for Learning Objects and Learning Objects’ Repositories" (2019). Dissertations. 588. https://digscholarship.unco.edu/dissertations/588 This Text is brought to you for free and open access by the Student Research at Scholarship & Creative Works @ Digital UNC. It has been accepted for inclusion in Dissertations by an authorized administrator of Scholarship & Creative Works @ Digital UNC. For more information, please contact [email protected]. ©2019 ALTAF SIDDIQUI ALL RIGHTS RESERVED UNIVERSITY OF NORTHERN COLORADO Greeley, Colorado The Graduate School DESIGN OF INSTRUCTIONAL MODELING LANGUAGE FOR LEARNING OBJECTS AND LEARNING OBJECTS’ REPOSITORIES A Capstone Submitted in Partial Fulfillment of the Requirements of the Degree of Doctor of Philosophy Altaf Siddiqui College of Education and Behavioral Sciences Department of Educational Technology August 2019 This Capstone by: Altaf Siddiqui Entitled: Design of Instructional Modeling Language for Learning Objects and Learning Objects Repositories has been approved as meeting the requirement for the Degree of Doctor of Audiology in College of Education and Behavioral Sciences in Department of Educational Technology
    [Show full text]
  • 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
    [Show full text]
  • Integration Definition for Function Modeling (IDEF0)
    NIST U.S. DEPARTMENT OF COMMERCE PUBLICATIONS £ Technology Administration National Institute of Standards and Technology FIPS PUB 183 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEFO) » Category: Software Standard SUBCATEGORY: MODELING TECHNIQUES 1993 December 21 183 PUB FIPS JK- 45C .AS A3 //I S3 IS 93 FIPS PUB 183 FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION INTEGRATION DEFINITION FOR FUNCTION MODELING (IDEFO) Category: Software Standard Subcategory: Modeling Techniques Computer Systems Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 Issued December 21, 1993 U.S. Department of Commerce Ronald H. Brown, Secretary Technology Administration Mary L. Good, Under Secretary for Technology National Institute of Standards and Technology Arati Prabhakar, Director Foreword The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official publication relating to standards and guidelines adopted and promulgated under the provisions of Section 111 (d) of the Federal Property and Administrative Services Act of 1949 as amended by the Computer Security Act of 1987, Public Law 100-235. These mandates have given the Secretary of Commerce and NIST important responsibilities for improving the utilization and management of computer and related telecommunications systems in the Federal Government. The NIST, through its Computer Systems Laboratory, provides leadership, technical guidance,
    [Show full text]
  • Design and Implementation of the L+C Modeling Language
    Design and implementation of the L+C modeling language Radoslaw Karwowski and Przemyslaw Prusinkiewicz Department of Computer Science University of Calgary Abstract L-systems are parallel grammars that provide a theoretical foundation for a class of programs used in procedural image synthesis and simulation of plant development. In particular, the formalism of L-systems guides the construction of declarative languages for specifying input to these programs. We outline key factors that have motivated the development of L-system- based languages in the past, and introduce a new language, L+C, that addresses the shortcom- ings of its predecessors. We also describe the implementation of L+C, in which an existing language, C++, was extended with constructs specific to L-systems. This implementation methodology made it possible to develop a powerful modeling system in a relatively short pe- riod of time. 1. Background L-systems were conceived as a rule-based formalism for reasoning on developing multicellular organisms that form linear or branching filaments [Lindenmayer, 1968]. Soon after their introduction, L-systems also began to be used as a foundation of visual modeling and simulation programs, and computer languages for specifying the models [Baker and Herman, 1972]. Subsequently they also found applications in the generation of fractals [Szilard and Quinton, 1979; Prusinkiewicz, 1986] and geometric modeling [Prusinkiewicz et al., 2003]. A common factor uniting these diverse applications is the treatment of structure and form as a result of development. A historical perspective of the L-system-based software and its practical applications is presented in [Prusinkiewicz, 1997]. According to the L-system approach, a developing structure is represented by a string of symbols over a predefined alphabet V.
    [Show full text]
  • 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
    [Show full text]
  • ESD.00 Introduction to Systems Engineering, Lecture 3 Notes
    Introduction to Engineering Systems, ESD.00 System Dynamics Lecture 3 Dr. Afreen Siddiqi From Last Time: Systems Thinking • “we can’t do just one thing” – things are interconnected and our actions have Decisions numerous effects that we often do not anticipate or realize. Goals • Many times our policies and efforts aimed towards some objective fail to produce the desired outcomes, rather we often make Environment matters worse Image by MIT OpenCourseWare. Ref: Figure 1-4, J. Sterman, Business Dynamics: Systems • Systems Thinking involves holistic Thinking and Modeling for a complex world, McGraw Hill, 2000 consideration of our actions Dynamic Complexity • Dynamic (changing over time) • Governed by feedback (actions feedback on themselves) • Nonlinear (effect is rarely proportional to cause, and what happens locally often doesn’t apply in distant regions) • History‐dependent (taking one road often precludes taking others and determines your destination, you can’t unscramble an egg) • Adaptive (the capabilities and decision rules of agents in complex systems change over time) • Counterintuitive (cause and effect are distant in time and space) • Policy resistant (many seemingly obvious solutions to problems fail or actually worsen the situation) • Char acterized by trade‐offs (h(the l ong run is often differ ent f rom the short‐run response, due to time delays. High leverage policies often cause worse‐before‐better behavior while low leverage policies often generate transitory improvement before the problem grows worse. Modes of Behavior Exponential Growth Goal Seeking S-shaped Growth Time Time Time Oscillation Growth with Overshoot Overshoot and Collapse Time Time Time Image by MIT OpenCourseWare. Ref: Figure 4-1, J.
    [Show full text]
  • On the Analysis of Cmmn Expressiveness: Revisiting Workflow Patterns
    ' $ ON THE ANALYSIS OF CMMN EXPRESSIVENESS: REVISITING WORKFLOW PATTERNS Renata Carvalho 1, Anis Boubaker 1, Javier Gonzalez-Huerta 1, Hafedh Mili 1, Simon Ringuette 2, and Yasmine Charif 3 Mars 2016 D´epartement d'informatique Universit´edu Qu´ebec `aMontr´eal Rapport de recherche Latece 2016-1 & % ON THE ANALYSIS OF CMMN EXPRESSIVENESS: REVISITING WORKFLOW PATTERNS Renata Carvalho 1, Anis Boubaker 1, Javier Gonzalez- Huerta 1, Hafedh Mili 1, Simon Ringuette 2, and Yasmine Charif 3 1 D´epartement d'informatique UQAM Montr´eal,Qc, Canada 2 Trisotech Inc. Montr´eal,Qc, Canada 3 Xerox Innovation Group Xerox Research Center Webster Mailstop 128-29E Laboratoire de recherche sur les technologies du commerce ´electronique D´epartement d'informatique Universit´edu Qu´ebec `aMontr´eal C.P. 8888, Succ. Centre-Ville Montr´eal,QC, Canada H3C 3P8 http://www.latece.uqam.ca Mars 2016 Rapport de recherche Latece 2016-1 Summary Traditional business process modeling languages use an imperative style to specify all possible execution flows, leaving little flexibility to process operators. Such lan- guages are appropriate for low-complexity, high-volume, mostly automated processes. However, they are inadequate for case management, which involves low-volume, high- complexity, knowledge-intensive work processes of today's knowledge workers. OMG's Case Management Model and Notation(CMMN), which uses a declarative stytle to specify constraints placed at a process execution, aims at addressing this need. To the extent that typical case management situations do include at least some measure of imperative control, it is legitimate to ask whether an analyst working exclusively in CMMN can comfortably model the range of behaviors s/he is likely to encounter.
    [Show full text]
  • System Model-Based Definition of Modeling Language Semantics In: Proc
    System Model-Based Definition of Modeling Language Semantics Hans Gr¨onniger, Jan Oliver Ringert, and Bernhard Rumpe Lehrstuhl Informatik 3 (Softwaretechnik), RWTH Aachen, Germany Abstract. In this paper, we present an approach to define the seman- tics for object-oriented modeling languages. One important property of this semantics is to support underspecified and incomplete models. To this end, semantics is given as predicates over elements of the seman- tic domain. This domain is called the system model which is a general declarative characterization of object systems. The system model is very detailed since it captures various relevant structural, behavioral, and in- teraction aspects. This allows us to re-use the system model as a domain for various kinds of object-oriented modeling languages. As a major con- sequence, the integration of language semantics is straight-forward. The whole approach is supported by tools that do not constrain the seman- tics definition’s expressiveness and flexibility while making it machine- checkable. 1 Introduction Modeling is an integral part of complex software system development projects. The purpose of models ranges from assisting developers and customers commu- nicate to test case generation or (automatic) derivation of the developed system. A prominent example modeling language is UML [1]. Actually, it is a family of languages used to model various aspects of a software system. While UML is widely used, domain specific modeling languages emerged recently that allow developers and even customers to express solutions to well-defined problems in aconciseway. A complete definition of a modeling language consists of the description of its syntax, including well-formedness rules and its semantics (meaning) [2].
    [Show full text]
  • System Structure Modeling Language (S2ML) Michel Batteux, Tatiana Prosvirnova, Antoine Rauzy
    System Structure Modeling Language (S2ML) Michel Batteux, Tatiana Prosvirnova, Antoine Rauzy To cite this version: Michel Batteux, Tatiana Prosvirnova, Antoine Rauzy. System Structure Modeling Language (S2ML). 2015. hal-01234903 HAL Id: hal-01234903 https://hal.archives-ouvertes.fr/hal-01234903 Preprint submitted on 1 Dec 2015 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. System Structure Modeling Language (S2ML) Language Specification Version 1.0 November 2015 Abstract: This document defines the S2ML language, version 1.0. S2ML is developed in the framework of the OpenAltaRica project, leaded by IRT SystemX, Palaiseau, France. S2ML is a freely available, prototype-oriented language for both representing the structure complex systems and structuring models of these systems. It aims at providing a minimal but sufficient set of constructs for these purposes. S2ML 1.0 Specification 2 Copyright © AltaRica Association, 2015 All rights reserved. Reproduction or use of editorial or pictorial content is permitted, i.e. this document can be freely distributed especially electronically, provided the copyright notice and these conditions are retained. No patent liability is assumed with respect to the use of information contained herein. While every precaution has been taken in the preparation of this document, no responsibility for errors or omissions is assumed.
    [Show full text]
  • Lecture 9 – Modeling, Simulation, and Systems Engineering
    Lecture 9 – Modeling, Simulation, and Systems Engineering • Development steps • Model-based control engineering • Modeling and simulation • Systems platform: hardware, systems software. EE392m - Spring 2005 Control Engineering 9-1 Gorinevsky Control Engineering Technology • Science – abstraction – concepts – simplified models • Engineering – building new things – constrained resources: time, money, • Technology – repeatable processes • Control platform technology • Control engineering technology EE392m - Spring 2005 Control Engineering 9-2 Gorinevsky Controls development cycle • Analysis and modeling – Control algorithm design using a simplified model – System trade study - defines overall system design • Simulation – Detailed model: physics, or empirical, or data driven – Design validation using detailed performance model • System development – Control application software – Real-time software platform – Hardware platform • Validation and verification – Performance against initial specs – Software verification – Certification/commissioning EE392m - Spring 2005 Control Engineering 9-3 Gorinevsky Algorithms/Analysis Much more than real-time control feedback computations • modeling • identification • tuning • optimization • feedforward • feedback • estimation and navigation • user interface • diagnostics and system self-test • system level logic, mode change EE392m - Spring 2005 Control Engineering 9-4 Gorinevsky Model-based Control Development Conceptual Control design model: Conceptual control sis algorithm: y Analysis x(t+1) = x(t) +
    [Show full text]