Copyright © IFAC 12th Triennial World Congress, Sydney, Australia, 1993
THE ANDECS DESIGN ENVIRONMENT FOR CONTROL ENGINEERING G. GrUbel, H.-D. Joos, M. Otter and R. Finsterwalder DLR - German Aerospace Research Establishment. Control Design Engineering, Institute for Robotics and System Dynamics, D-8031 Oberpfaffenhofen, Germany
Abstract. ANDECS belongs to the new generation of open CAE systems for computational experimenting in controlled dynamic systems simulation, analysis, and multi-objective optimization. Strict databased function modularization with neutral object-oriented data- and model interfaces allows a flexible configuration of application programs . This modularity also guarantees side-effect free functional extensions by an application programmer . Module operation can be switched any time from interactive line commands to an X-Window graphical user interface. Via macro scripts stored on database, module sequences can be operated in batch mode with automatic parameter incrementation . Function modules are available for basic mathematical methods , control methods , simulation, parameter- and trajectory optimization, and interactive visualization for result- and algorithm animation . Keywords. Computer-Aided, Control Engineering, Computational Experimenting, Databased Simulation, Engineering Database.
1
INTRODUCTION
putation engine which runs parametric iterations for a best-possible compromise solution, and of an interaction machinery to handle and monitor the design machine on the three strata of: model experiments, method experiments, and parametric experiments. The 'database-centered' software architecture allows a strictly modular experimentation set-up, combining synthesis-, analysis-, simulation-, and optimization modules in a most versatile way.
At the 10th IFAC World Congress, Munich, 1987, A .G.J. MacFarlane presented an invited paper on Future Design Environments for Control Engin eering. That paper examined for the field of control engineering the relationship between user needs and interactive computing environments to satisfy them. The purpose was to stimulate the discussion of research directions in this field; practical guidelines or recipes for the user were not provided.
In the following, we concentrate on the core design environment MOPS, the simulation environment DSSIM, and the visualization environment VISTA. Readers interested in more details are referred to a 'long version' of this paper which is available from the authors.
In this contribution we substantiate, refine, and extend the view of MacFarlane et al. (1989) based on our practical experience in conceiving, realizing, and applying the control-dynamics design environment ANDECS®l . In particular, we adhere to the view that design is an interactive, iterative feedback process where the design engineer controls a design machine by drivers, and gets feedback from the machine by indicators. This design machine consists of a demand-driven com-
2
THE BASIC COMPONENTS OF ANDECS
The design environment ANDECS®is based on the control-engineering numerics library RASP and the 'engineering operating system' RSYST; Griibel and Joos (1991) . It integrates :
1 ANDECS®stands for: Analysis & D esign of Controlled Systems, and is a registered trademark of DLR.
789
Mathematical Methods: Basic EISPACK, LINPACK matrix-function calculations using the matlab syntax, interpolation of signals, or root finding of nonlinear functions, etc .. Control Methods: Analysis and synthesis methods for linear multivariable systems in time-, state-, and frequency domain; like simulation via transition matrix, observability- and controllability, poles and zeros, frequency- and singular value plots, pole placement, LQG, or Hoo. Simulation : Simulation environment for nonlinear dynamic systems described by differential algebraic equations, linearization and computation of stationary solutions. Optimization: Multi-objective parameter and trajectory optimization within a design environment where the design history is recorded on an automatically evolving hierarchical database. The database records all necessary data for completely backtracing, and for branching and restarting a design process in a new direction. Visualization and Interactive Steering: Standard diagrams like 2-D plots, Bode-, Nyquist-, and root locus diagrams. Special diagrams like representation in Inselberg coordinates to visualize conflicts in multiple optimization criteria, Finsterwalder (1991); direct interaction in result visualization and algorithm animation; Finsterwalder (1992).
3
THE ANDECS CORE DESIGN ENVIRONMENT MOPS
Engineering design is the iterative search for a suitable compromise or tradeoff among potentially competing goals in creating and modifying engineering objects. It is a feedback process where in general both the object being created and the specifications against which it is manipulated are being iteratively adjusted in a feedback cycle of dependence as the design proceeds. In order to record the design history and to show the various design experiments done by the user, ANDECS provides a databased design environment called MOPS (Multi - Objective Programming System); Joos (1993). The principal design feedback loops behind MOPS are illustrated in figure 1.
CD· OBJECTS
DESIGNER
+
MODIFICATION
\
4_---
SPECIFICATION ...
Fig. 1. The principal design-feedback loops Note, that the procedural framework of the 'dynamics design engine' has the general structure of a feedback control system, where the designer inputs desired performance levels and the engine outputs best-possible compromise solutions by adj usting the design tuners via design synthesis , i.e. multi-criteria optimization.
The module AMATLAB is a re-implementation of the classic matlab syntax, to be used for interactive specification of matrix calculations within a modular computation sequence; it has the same database access as any other ANDECS module. Via client/server communication, PROMATLAB2 and MATLAB Toolboxes can be used as slave processes within a databased computation loop like multiobjective optimization.
In particular, as a design comparator for detecting 'better' designs, we use the max-function a = max {cd di }, where di is a chosen design demand level corresponding to the performance criadi < di , terion Ci. Then, if a < 1 we have Ci for all i ; or in vector notation C aD < D :
:s
ANDECS fully supports the neutral 'model bus' DSblock for model import and export; Otter (1992). DSblock is a set of standardized program interfaces to describe executable models of dynamic input/output systems which are governed by nonlinear, parameterized, event-driven differential-algebraic equations . The ANDECS simulation environment supports time-simulation and linearization of DSblock models. The simulation module DSSIM behaves as any other ANDECS module as far as user interface and database access is concerned.
:s
d,
Ci
A design is the better, the smaller the criteria vector C is compared to the design-director vector D . Hence a = max {ci(T)/ d;} should be minimized as a function of the tuners T. This is the purpose of design synthesis: min a(T)
->
T
su bject to performance and tuning restraints: 2PRO-MATLAB, MATLAB-Toolboxes: Mathworks Inc. USA.
Products of
790
The variability of possible design decisions and the amount of computational data necessary to get the proper indicators for these decisions, make it necessary to support the designer in
Figure 1 also shows, that, in addition to parametric design iterations, the designer must be able to modify the specifications, - formalized by performance measures - , and slhe must be able to modify the structure of the design object, - i.e. the dynamics model- , via suitable system modelling procedures. This yields the 3-strata designprocess model depicted by figure 2:
design-project database
formally structuring the decision process, automatically recording the various design steps and the pertinent data, allowing to compare any design outcomes by making the necessary indicator data easily recoverable, allowing back tracing and branching of the design process.
,.
r-
::::r:>
design synthesis (optimizer)
T
:::fi~;,."
tu K
D
The 3 decision strata I, J, K form a hierarchy. Hence a hierarchical database is best suited to record and reflect the design history, figure 3:
en
:J
>: 0 .
design comparator
en C\l
ia
C?
0)
c:
·c
performance measures
J
analysis & -~ simulation . .. . . .. .. . .. ...... . ., . . . . .
.0,
:.::r: .
oo
>P: <
········:t·· ...... : :.:.: ..
Q) Q)
::t: . :::(
c: c:
UJ
()
> ~. >
Dynamics Model Bus
I
--
Fig. 3. Structure of a design-history database.
system dynamics model
dynamics synthesis
This data structure yields the required formal design support in that all design steps are completely recorded for backtracing. Branching of the design process is possible by choosing an already existing design (I, J, K)a as the first branch of a new design-history data structure.
.. p. >
:-.-r:
... :- .. ...
Fig. 2. The 3 design strata I, J, K, the designer interacts and iterates on.
Variability and flexibility during design requires adaptable software. Figure 2 shows the data flow in a MOPS design iteration. The corresponding software architecture is based on tool abstraction: For each of the function blocks, such as system dynamics model evaluation; analysis and simulation; performance criteria computation; design synthesis (e.g. parameter optimization); dynamics synthesis; a bundle of function modules (toolies) is available. These communicate via the "engineering-data bus" only. The communication data are Abstract Data Types (lD-, 2D-, 3Darrays, parameter sets of numeric and symbolic values, text, pixel-pictures), as well as Control Data Objects (CDO) which are higher-level data structures (e.g. 'signal', 'transfer matrix', 'generic linear state space model'), and which are formally defined via the class schema of the database; Joos and Otter (1991).
The 3 principal design strata I , J, K are:
(I) The designer creates or modifies the dynamics model M or its parametrization P. This task may be supported by available system modelling tools . (J) The designer defines and modifies the performance measures. The design specifications have to be expressed by performance criteria C based on the indicators I which are computed by analysis or simulation of the dynamics model. (K) The designer weights the various performance criteria using the design directors D, to achieve the trade-off solution that satisfies the chosen demand level best.
791
transistor models of electronic circuits. The eventhandling feature is used to treat discontinuous equations or equations with varying structure; e.g. impact, friction, backlash, sampled-data systems.
From the available bundle of toolies, computational sequences can be composed by the dialog and macro facility. In particular, MOPS is a monitoring module which drives user-defined application macros. Being consequent in tool abstraction, the function 'parameter optimization via mathematical programming' is also implemented as a module which is independent from other function modules. This is achieved by a program structure called reverse communication, where the control of the computational flow is returned from the optimizer to the driver module MOPS on every occasion where new values of the performance measures or gradients are required.
4 4.1
Modelling is not performed in module DSSIM. Rather, existing modelling environments are enhanced by a code generator, which generates a DSblock. Programs which generate a numerical model description are augmented by a subroutine layer in DSblock format, which allows the calling of that program at specific time instants to calculate the right hand side of the differential equations. This is realized in the multi body program SIMPACK. Presently, the following modelling environments have been enhanced by DSblock generators:
THE ANDECS SIMULATION ENVIRONMENT DSSIM
A general purpose simulation language; Mitchell and Gauthier (1991). ACSL is the de-facto industrial standard for CSSL simulation languages. Dymola A new , very powerful object oriented modelling language; Cellier and Elmqvist (1992), Cellier (1991). SIMPACf( A general-purpose multibody program; Rulka (1990).
A CSL
Modelling Environments
Modelling and Simulation in ANDECS are separated into two distinct parts as shown in figure 4. The interface between these two parts is defined by a neutral description of input/output blocks, which are realized as FORTRAN- or Csubroutines with defined formal arguments. A block of this type is called DSblock (= Dyn amic System block); Otter (1992).
Dymola3 is the prefered modelling env ironment for ANDECS. It supports the building of domain specific model libraries. Models are hierarchically decomposed into submodels which can be connected according to the physical coupling of the components. An examp le is given in Table 1, which shows the Dymola definition of the multibody part of a Manutec r3 robot dynamics model using the ANDECS multi body systems library mbs.
domain .pccific modcllibraria for
modelling environments
model L-~+-_+-_+
___-+_--.J 4.2
export a model is described by upto 11 FORTRAN or C subroutines
. w~tith.lijIUtral OSb/ock interlace
neutral model bus
Before simulations of DSblocks can be carried out by the module DSSIM, the appropriate DSblocks must be introduced to the system by a configuration module where any number of DSblocks is allowed in the executab le image simultaneously. Thereby online run-time switching between design alternatives or system models of various complexity is possible .
model import
Simulation by module DSSIM
r:;=:i::::::;--;=±:::;:-=:±=:l simulation environments
Fig. 4. Separation of modelling and simulation by the DSblock model bus
The result of a simulation experiment is a set of computed signals which are automatically stored on database, and then can be visualized by available graphics modules. All input data of an experiment, e.g . integration method or length of communication interval, are stored on database as well. Therefore every simu lation run is completely
A DSblock allows the description of timedelayed, time-, state-, and step-event dependent explicit ordinary differential equations (ODE), differential-algebraic equations (DAE), and overdetermined differential algebraic equations (ODAE) . The latter equations result in transforming a higher index differential algebraic equation to an index-1-DAE equation; e.g. in multibody systems with closed kinematic loops, or in
3Dymola is commercially available from its originator Hilding Elmqvist, DynaSim AB, Lund, Sweden.
792
5
documented and reproducible. Figure 6 shows a screen-hardcopy of a typical DSSIM session . The lower left part shows the input window, the right part shows the database browser, and in the upper left part the online graphics of DSSIM can be seen.
THE ANDECS INTERACTIVE VISU ALIZATION ENVIRONMENT
Human feedback has to close the design loop between the design indicators and the design drivers of the design machine. In order to explore properties that may be difficult to understand or even remain unnoticed otherwise, all design relevant data are simultaneously displayed in multiple graphical views while the design process is in action. Since previous results remain on the screen, the designer gets an immediate visual feedback about the effect of changes in the problem data. This closes the loop between computation/visualization and the designer .
The DSSIM simulation environment uses welltested numerical integration routines from various professionals. Presently the following solvers are provided:
DEABM
Multistep solver for non-stiff and moderately stiff ODEs by Shampine/Watts. LSODE Multistep solver for stiff and nonstiff ODEs by Hindmarsh. LSODAR Multistep solver which switches automatically between a non-stiff and a stiff integration algorithm along the solution by Petzold/Hindmarsh. LSODAR also provides a root finder . RK45/78 Runge-Kutta-Fehlberg solvers of Kraft/Fiihrer of fixed orders 5 and 8 with variable stepsize using the Prince- Dormand coefficients. GRK4T A(89.3)-stable linearly-implicit Rosenbrock type single-step solver of fixed order 4 for stiff and oscillating ODEs by Arnold . DASSL/RT Multistep solvers of Petzold for DAEs and for DAEs with root finder . ODASSL/RT Multistep solvers by Fiihrer based on DASSL/RT of Petzold for ODAEs and for ODAEs with root finder. Extrapolation solver of Lubich for a MEXX class of index-2 ODAEs.
Figure 7 shows a snapshot of a typical ANDECS session while an optimization process is running . By looking at the results from different points of view, the designer may watch online how the optimizer proceeds . In the upper left window some design-relevant properties of the particular application problem are shown . In the upper right window the conflict editor shows the performance values of all candidates so far obtained by multiobjective optimization . The smiling expression of the status face indicates that the optimization is converging. A yellow color of the face indicates that no constraints are violated, otherwise the face's colour would be red and more sorrowful. At any time the computation can be interrupted or stopped . Then the designer can examine actual and previous results by the following facilities : - Selecting a particular design candidate by picking any point/curve on any design related display invokes that all curves belonging to this design are highlighted . - Scanning the design history stepwise along anyone of the performance measures Ci yields all data of an actualized candidate being visualized . The actual candidate is highlighted, while the highlighting of the previous chosen candidate then is reset .
There are a wide variety of available options to define a simulation experiment . For example, the communication time grid can be defined as an equidistant grid, as an arbitrary user-defined grid, or as a computationally-chosen grid .
- Tradeoff-analysis via the conflict-editor gives a design-history-based information of what criteria are competing how strongly. - Information Zooming: Validation of results requires to look at data from different abstraction levels . In general, this implies that more detailed computations for the corresponding visualizations are needed. For example, in axis 3 of the criteria-conflict editor the maximum amplitude of a time simulation is displayed as criterion C3 . By clicking this performance item, a new simulation run is
The module DSSIM can be combined with other ANDECS modules via macros . This allows customized realizations of analysis and design tools which use nonlinear time simulation in combination with, e.g ., active online monitoring, automatic parameter incrementation, multi-criteria parameter and trajectory optimization by MOPS, or Monte Carlo experimentation .
793
realization of a design framework: It supports an integrated 3-strata design process of goal-driven parametric iterations, performance-modelling reiteration, and multidisciplinary system-dynamics modelling via various domain-specific modelling environments.
started and the complete trajectory together with previously shown trajectories is visualized in a new window. - Interactive Steering: By acting on the drivers, i.e. design directors or tuners, a new computation is started and new results are immediately shown by the displays. If the computations are fast enough, this allows the designer to do on-line (multi-) parameter variations via 'analog' input-devices such as the DLR steering ball or mouse-driven sliders. The module bundle VISTA (Visualization & Interactive Steering for Task Activation) allows a strictly modular realization of the visualization concepts outlined above, cf. figure 5:
.
... -- ..... -.. .
.
-.~
1:
compute:
all modules are : reusable in computational chains : for e.g. multiobjective : optimization
+
t/)
:::s
CC
-
REFERENCES Cellier, F . E . (1991) . Continuous System Mode/ing. Springer , New York . Cellier, F. E. and H. Elmqvist (1992). The need for automated formula manipulation in object-oriented continuous-system modeling. In 'Proc. IEEE CACSD'92 Symposium, Napa, CA, USA', pp.I-8. Finsterwalder, R . (1991) . A 'parallel coordinate' editor as a visual decision aid in a multiobjective concurrent control engineering environment. In 'Proc. 5th IFAC/IMACS Symposium on Computer Aided Design in Control Systems, Swansea, UK', pp . 118-122. Finsterwalder, R . (1992) . Algorithm Animation of Computational Chains. To appear in : Beitriige zur graphischen Datenverarbeitung,
«I «I
~ .. -........ -- j
CI
C)
C
.~
visualization:
~ c '0, c
independent modules to be reused in computational chains for e.g. multiple objectives diagrams
W
oC o
Fig . 5. Modular visualization by VISTA
6
CONCLUSIONS
Referring to the seminal paper Future Design Environments for Control Engineering; MacFarlane et al. (1989), we claim that most of the perspectives developed then are met now by the ANDECS® control-engineering design environment, which provides a coherent system of design problem-solving concepts, control-engineering methods, numerics, informatics, and modular software integration. This CACE software is an adaptable, extensible, and computation ally efficient
Springer 92 . Griibel, G . and H.-D . Joos (1991) . RASP and RSYST - two complementary program libraries for concurrent control engineering. In 'Proc . 5th IFAC/IMACS Symposium on Computer Aided Design in Control Systems, Swansea, UK ' , pp. 101-106. Joos, H.-D . (1993). Informationstechnische Behandlung des mehrzieligen regelungstechnischen Entwurfs.Dr.-Ing. Thesis. Universitiit Stuttgart . DLR TR R44-91. Joos , H.-D. and M. Otter (1991) . Control engineering data structures for concurrent engineering . In 'Proc. 5th IFAC/IMACS Symposium on Computer Aided Design in Control Systems, Swansea, UK', pp. 107-112. MacFarlane, A. G . J ., G. Griibel and J . Ackermann (1989). 'Future design environments for control engineering' . A utomatica 25, 165-176. Mitchell, E. E. 1. and J . S. Gauthier (1991) . ACSL : Advanced Continuous Simulation Language Reference Manual. MGS, Concord ., Mass.
Otter, M. (1992). DSblock: A neutral description of dynamic systems . In : OPEN CACSD Electronic Newsletter, No . 3. Rulka, W . (1990) . SIMPACK - A Computer Program for Simulation of Large-Motion Multibody Systems . In: W . Schiehlen (ed.) Multibody Systems Handbook. Springer, pp . 265284 .
794
Table 1
Dymola specification to generate a DSblock rigid-multibody dynamics model for the manutec r3 6 link robot. The dynamics equations are automatically generated by an O(n) multi body formalism using the ANDECS mecha.nics-object library mbs . . .b.dir.lib
{u. . . .ltibody library ab.dir.lib; O(n)
aodel direab. submodel (Inertial) submodel (Revolute) submodel (Revolute) submodel (Revolute) submodel (Revolute) submodel (Body) submodel (Body)
i rl r4 rS r6 ml m2
submodel (Body)
m3
submodel (Body)
m4
submodel (Body)
mS
submodel (Body)
m6
input
al,orit~
(ng3=-0 (n3-0, r2 (nl"l), r3(nl=l, r3=0 . S) (n3=l, nrot3"'l, Jrot=1.6e-4, irot=-99) (nl=l, nrot3"l, Jrot"1 . 8e-4, irot= 79 . 2 , r3=0 . 73) (n3=l, nrot3=l, Jrot=4.3e-S, irot=-99) (I33= 1.16) (m -S6 . S , rl - 0.172, r3 = 0.20S, 111- 2.S8 , 122= 2.73 , 133= 0.64 , 131= -0 . 46) (m -26 . 4 , rl .. 0 . 064, r3 =-0.034, 111- 0 . 279, 122= 0 . 413, 133'" 0.24S, 131'"-0 . 070) (m "'28 . 7 , r3 - 0.32 , Ill" 1.67 , 122" 1 . 67 , 133= 0 .080 (m ,. S . 2 , r3 '" 0.023, Ill" 1.2S , 122= 1 . S3 , 133= 0 . 81 ) (133-0 .0000
tl, t2, t3 , t4, tS, t6
{ Connection structure of robot} connect i to rl to r2 to r3 to r4 to rS to r6 connect ml at rl, .2 at r2, m3 at r3, m4 at r4, mS at rS, m6 at r6 { The torques in the joints are the input signals, e .g . from other submodel} rl.f = t1 r2.f t2 r3.f t3 r4. f t4 rS . f tS r6.f '" t6 end
~I
...,-
,-1
1' '-
. . . . '1.-11_t ...
I'
~
DB-aro.r.te
.....
I!!I!!!!!I DEI [!!mJ
"
S.l.cted
.. r-~ I\, ~ 1\.\ ~~ .. .. .... 1\ \ \ \ \ \ ~ ~\ .. ... .. .. .. .. ... ... ... ...
Root 1 : SCA_IALlGJ)SSI" . 8
1· 1f
!!!!'l [J!!J [
-~
U -\El..
leYel 1 :
112 3
I
--
Globtll
III
PSI"
DD DD C]CJ ID t!mEJ C!!J IC!!!U Cl _I ij 5.0000
DO. 00000[ ·00
IICOIt
U
TIl.A8S
H1. 00000l-04
HLAEl
!I l.00060E=64
PIIOOEL
..,...
METHOD
l~mwI
lMETHIID
I
JlSS10 . 9
-
J'OUT .PSI" .PSI""
--'"
TEIIl OT
SlM1l.Uon
COHPIlTE
Fig. 6
1
• 9 10
11 12
tmD~
LEVEL SCR __ LG
TO
~
Il:!!2!!J
6
""""'"
cm::J
cg:J
•5
FJlter 1 :
ICl os
s-..... :
SCRJj'UGJlSSIO.9j>tOO(l[l.
--,"0 .J([1Il
100
4
User-interaction display for the databased simulation environment DSSIM 795
'"B tno "m tUB I
.
:
· • w::.. ·· : .......... .. .. .........: .. •
I~.
·· •
'.
·· ·
. ..
..
,
! _... ___ _
., I
MI
.;
~.
,
I
I;•
I~.
....
L ....
L~
. . . . . . . .: . ...
:
..... •
'::":":~
. ..
..
...
...
..
..
..
..
...
..
...
•
I •
,
.\\ O[CS 1.\"[
I
»»> HOPS >C> ana Available Busly-d. _CraI: o - .tepresponse8 . dlcnvahe., CAP 1 - .al.tiotl (COtlpal"'e berore, .Fter opU.baUo.) 2 - .. i .. tloB (de. lp .tep I-J-lt, .11 fll,hb tosetherl 3 - frequeacy l'eSpoosc q/dc ,( 0 )11
Fig. 7
Screen hardcopy during an ANDECS flight-control design session using MOPS. The aircraft icon animation shows dynamic pitch-rate behaviour. The ANDECS FACE shows that the optimizer is converging. In the upper left window eigenvalues, pitch-rate step response and CAP /~min is shown for flight conditions FC! and FC2. The upper right window visualizes the evolution of performance criteria in Inselberg (parallel) coordinates. The lower left window allows to choose from available analysis macros. Note that this X Motif multi-windows display is not hard coded, but application programmed using the generic VISTA modules.
796