User Tools

Site Tools


projects:twins:start

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
projects:twins:start [Friday, 17 April 2009 : 17:26:18]
vanbeek
projects:twins:start [Tuesday, 28 April 2009 : 16:21:21] (current)
vanbeek
Line 1: Line 1:
 +====== Twins ======
  
 +The [[http://​www.twins-itea.org/​|Twins]] project is part of the European [[http://​www.eureka.be/​home.do|EUREKA]] cluster program [[http://​www.itea-office.org/​|ITEA 2]], that addresses co-design problems of product development consisting of integrated hard- and software development.
 +
 +===== Research =====
 +
 +Within the TWINS project, we approach the problem of designing complex high-tech systems as a control problem.
 +More precisely, we propose
 +to view the problem of designing the software controlling the global behavior of
 +the machine as the problem of designing a controller which achieves certain
 +control objectives. In addition, we propose to generate the control algorithm
 +and the control software automatically from the formal model of the plant and
 +of the requirements. The argument in favor of this approach is that it should
 +considerably reduce the length of the developmental cycle of the product, as it
 +facilitates reduction in the number of design-test-redesign loops.
 +
 +We distinguish between the uncontrolled physical system (referred to
 +as plant) and the control software. Our goal is to generate the control software
 +such that if the generated control software is coupled with the physical system,
 +the resulting entity exhibits the desired behavior. There are many ways to
 +formulate what is meant by the desired behavior. One possibility is to state it
 +as conditions on the input-output map. More precisely, the dynamic behavior
 +of the machines is usually determined by two kinds of input signals: user input
 +and machine control input. The former is essentially the input provided by the
 +We distinguish between the uncontrolled physical system (referred to
 +as plant) and the control software. Our goal is to generate the control software
 +such that if the generated control software is coupled with the physical system,
 +the resulting entity exhibits the desired behavior. There are many ways to
 +formulate what is meant by the desired behavior. One possibility is to state it
 +as conditions on the input-output map. More precisely, the dynamic behavior
 +of the machines is usually determined by two kinds of input signals: user input
 +and machine control input. The former is essentially the input provided by the
 +user or external environment. The machine control inputs are the ones which can be used by the
 +controller to change the behavior of the system.
 +The desired behavior can be formulated as a relation describing what kind of output the machine is supposed to produce
 +for a specific user input.
 +
 +{{ :​twins:​machine_abs_small.jpeg?​600 }}
 +
 +With the point view explained above in mind, the main problem of software
 +design for machines can be reformulated as follows.
 +
 +**Design as control problem**. ​
 +Assume that a model P of the
 +plant is given and assume that a formal specifcation S of the requirements is
 +given. Furthermore,​ assume that the requirements are formulated as properties
 +which should be satisfied by user input/​machine output pairs. The task is to
 +generate a controller C such that the closed-loop system on Figure 3 satisfies
 +the requirements S.
 +
 +The problem formulated above indeed looks similar to a classical control
 +problem. However, in the case of complex machines the inputs and the outputs
 +can be both discrete and continuous. This calls for methods and techniques
 +which can deal with control systems exhibiting both continuous and discrete
 +behavior. Such methods and techniques exist and they are known under the
 +name of control theory for discrete-event systems and hybrid systems.
 +
 +**(Controlled synthesis as design procedure).** ​
 +Notice that the problem
 +formulation implies that the generated controller C should be
 +correct by design. That is, if the mathematical model of the plant and of the
 +requirements is accurate enough, then the controller will enforce the desired
 +behavior of the system. This means that in contrast to the case when the
 +controller is designed by hand, no testing and debugging of the controller is
 +required. The only purpose of testing is to find out whether the plant model is
 +realistic enough and whether the model of the requirements formalizes all the
 +relevant features. The overall design procedure is then as follows.
 +
 +1. Build a mathematical model P of the plant.
 +
 +2. Build a mathematical model S of the requirements.
 +
 +3. Generate a controller C which is correct by construction.
 +
 +4. Test the closed-loop system (see figure).
 +
 +5. If the test results indicate incorrect functionality,​ then there can be only
 +two causes for this; either the model P of the plant is inadequate, or the
 +model S of the requirements is inadequate. Improve the model of the
 +plant or the model of the requirements and repeat the steps above again.
 +
 +6. If the outcome of the tests is satisfactory,​ then the design is ready.
 +
 +{{ :​twins:​sup_picture_abs_small.jpg?​500 |:​twins:​sup_picture_abs_small.jpg}}
 +
 +The proposed approach also fits well into the more general paradigm of
 +model-based engineering. The main idea of model-based engineering can be
 +formulated as follows. Instead of making prototypes of the system, the engineers
 +are expected to make mathematical models of the system behavior and
 +to test/verify their design choices by analyzing the impact of the choices on the
 +behavior of the models.
 +
 +
 +
 +=== Staff ===
 +  * [[http://​yp.wtb.tue.nl/​se/​showemp_t3.php/​883|prof.dr.ir. Koos Rooda]]
 +  * [[http://​se.wtb.tue.nl/​sewiki/​vanbeek|dr.ir. Bert van Beek]]
 +
 +=== Postdoc ===
 +  * [[http://​yp.wtb.tue.nl/​se/​showemp_t3.php/​7359|dr.Mihaly Petreczky
 +
 +]]
 +
 +=== Students ===
 +  * Esmee Bertens (at Oce)
 +  * Jelte Leijenaar (at Neopost)
 +
 +===== Selected publications =====
 +M. Petreczky, D.A. van Beek, J.E. Rooda. ​
 + ​{{twins:​se_report_2008_11.pdf|Supervisor for toner error-handling}},​ SE Report 2008-11, Eindhoven University of Technology, Department of Mechanical Engineering,​ 2008.
 +
 +E. Bertens, R. Fabel, M.Petreczky,​ D.A.van.Beek,​ J.E.Rooda. {{twins:​paper_pact_-_oce_bertens_26fabel.pdf |Supervisory control synthesis for exception handling in printers}}. In Proc. Philips Conference on Applications of Control Technology, 2009.
 +
 +M. Petreczky, P. Collins, D.A. van Beek, J.H. van Schuppen, J.E. Rooda. ​ A control problem for hybrid systems with discrete inputs and outputs. Accepted to European Control Conference 2008.
 +
 +See also:
 +  * [[:​cif:​start|CIF]]
 +  * [[:​chi:​start|Chi]]
 +Note that we use and (partially) develop [[:​chi:​start|Chi]] and the [[:​cif:​start|Compositional Interchange Format (CIF)]] for supervisory control synthesis and simulation in the Twins project.
projects/twins/start.txt · Last modified: Tuesday, 28 April 2009 : 16:21:21 by vanbeek