Distributed Computation for Co op erativ Con trol Eric Kla vins Ric hard M PDF document - DocSlides

Distributed Computation for Co op erativ Con trol Eric Kla vins Ric hard M PDF document - DocSlides

2014-12-13 120K 120 0 0

Description

Murra Ele ctric al Engine ering Contr ol and Dynamic al Systems University of Washington California Institute of chnolo gy Se attle Pasadena CA klavinswashingtonedu murraycdscaltechedu Abstract co op erativ con trol system consists of ultiple autono ID: 23306

Direct Link: Link:https://www.docslides.com/trish-goza/distributed-computation-for-co Embed code:

Download this pdf

DownloadNote - The PPT/PDF document "Distributed Computation for Co op erativ..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.

Presentations text content in Distributed Computation for Co op erativ Con trol Eric Kla vins Ric hard M


Page 1
Distributed Computation for Co op erativ Con trol Eric Kla vins Ric hard M. Murra Ele ctric al Engine ering Contr ol and Dynamic al Systems University of Washington California Institute of chnolo gy Se attle, Pasadena, CA klavins@washington.edu murray@cds.caltech.edu Abstract co op erativ con trol system consists of ultiple, autonomous comp onen ts in teracting to con trol their en vironmen t. Examples include air trac con trol systems, automated factories, rob ot so ccer teams and sensor/actuator net orks. Designing suc systems requires com bination of to ols from con trol theory and distributed systems. In this article, review some of these to ols and then fo cus on the Computation and Con trol Language, CCL, whic ha dev elop ed as mo deling to ol and programming language for co op erativ con trol systems. In tro duction co op erativ con trol system consists of ultiple, autonomous comp onen ts in teracting to con trol their en vironmen t. Examples include air trac con trol systems, automated factories, rob ot so ccer teams and sensor/actuator net orks. In eac of these systems, comp onen reacts to its en viron- men and to messages receiv ed from neigh oring comp onen ts. Th us, co op erativ con trol system is at once con trolled ph ysical system and distributed computer. Designing co op erativ con trol systems, therefore, requires com bination of to ols from con trol theory and distributed systems. motiv ating example for our ork is the ob oFlag game [3], successor to the ob oCup rob otic so ccer tournamen dedicated to the goal of building rob otic so ccer team 2050. Rob oFlag is ersion of \capture the flag", using the setup illustrated in Figure 1. Eac team (red and blue) has home zone, defensiv zone con taining flag and et een eigh and ten rob ots. The game can pla ed either with autonomous con trollers or with one or umans in the lo op giving high-lev el directiv es to their teams. The goal of the red team, sa is to capture the blue team's flag and return it to the red home zone, mean while defending its wn flag. If red rob ot is \tagged" or touc hed blue rob ot while on the blue side of the eld, it ust return to its home zone for \time out". The blue rob ots ha symmetric goal. In addition to ha ving to con trol their wn motions, the rob ots ha limited sensing capabilities and are organized as distributed computational system, requiring that information comm u- nicated et een rob ots and across limited bandwidth links. Eac rob ot ust, therefore, con tain program that allo ws it to con trol its motion, react to ev en ts near it and participate in group strategies. Designing suc programs so that they are correct, robust and fault toleran is the goal of co op erativ con trol. Con trol vs. Distributed Computation Tw ery dieren orlds collide in co op erativ con trol problems suc as the Rob oFlag game. On one hand, things lik rob ots are electro-mec hanical ob jects
Page 2
Figure 1: The ob oFlag game. Tw teams of rob ots, red and blue, ust defend their flags while attempting to capture the other team's flag. whose in teractions with the ph ysical orld ould lik to manage. usually sp eak of con trol with resp ect to dynamical mo del of the orld, suc as set of dieren tial equations with inputs and outputs. The con trol problem is that of \closing the lo op", that is, dening input rules as functions of the output alues to pro duce desired eha vior. As con trol engineers, orry ab out the stabilit robustness and erformance of the systems design. On the other hand, gr oup of rob ots is all righ ts distributed computational system, eac rob ot ha ving its wn pro cessor and (presumably) some metho of comm unicating with the pro cessors on other rob ots. Presen tly there are no univ ersally agreed up on mo dels for distributed systems: migh use I/O automata pr ess algebr as or guar de ommand languages to describ ho messages are passed et een rob ots or ho instructions on dieren pro cessors ma in terlea ed. As distributed systems engineers, orry ab out proto col design, deadlo oidance and comm unication complexit The dicult is that cannot temp orarily ignore one of these orlds while concen trating on design problems in the other. As co op erativ con trol engineers, ust concerned with com- unication proto cols ecause they in tro duce dela ys, whic are notorious for degrading erformance and causing instabilities. ust mind the comm unication complexit of the system: truly decen tralized con trol algorithm will require only few messages to passed from rob ot to rob ot and in particular will not demand that eac rob ot kno the state of ev ery other rob ot in order to act. Unfortunately most tried and true con trol tec hniques are blind to these problems. As dis- tributed systems engineers, ust design proto cols that resp ect the dynamics of the en vironmen t: or example, proto col in tended to reac consensus among formation of aircraft ab out ho to resp ond to threat ust nish efore the momen tum of the aircraft carries them inescapably close to the threat. In con trast, momen tum and acceleration are often not concern in traditional distributed systems wherein, for example, bank customer can simply ait for distributed online transaction to complete (his momen tum eing of no concern to the bank).
Page 3
the heart of the dierence et een con trol engineering and distributed system engineering lies the role of the en vironmen in the design pro cess. In con trol, the unpredictable, messy and incompletely understo en vironmen is tigh tly coupled with con trol pro cess designed to reject disturbances from the en vironmen to ac heiv certain desired op erating condition. or example, the autopilot on an aircraft will attempt to main tain altitude, heading and sp eed despite wind gusts and turbulance. The eaut of feedbac con trol is that, to large exten t, it is robust to the dierences in the mathematical mo del of ho the en vironmen aects the system and the actual eect of the en vironmen on the system. In con trast, in computational systems and distributed systems in particular, there often is no explicit en vironmen whatso ev er, and the notion of robustness to mo deling errors is not ev en an issue. Suc systems consist of nothing but the in ternal states (memories, le systems) of the pro cesses in olv ed. The task for the distributed systems engineer is to manipulate this information and eep it consisten among the arious pro cesses. When the issue of robustness do es arise, it is with resp ect to whether the system can con tin ue to function in the ev en that one of the pro cessors fails. When design ulti-v ehicle systems, sensor-actuator net orks or automated factories ust merge these ys of lo oking at the problem. dynamical mo del of the resp onse of the system to its en vironmen is mandatory and so is an understanding of ho information flo ws from pro cess to pro cess. ust ask questions ab out the stabilit of motions in the en vironmen and the stabilit of information in the net ork. ust ensure that the system is robust to disturbances oth ph ysical, suc as resulting from wind gust, and logical, suc as resulting from hard reb ot of pro cessor. Synopsis In this article describ at high lev el some of the metho ds that are used to bridge these ys of mo deling and designing systems. or the sak of brevit our review is incomplete and biased to ard our wn ork on the Computation and Contr ol anguage or CCL whic ha egun to use for mo deling con trol systems, esp ecially distributed ones. illustrate some of the concepts in olv ed, presen fairly complete example of ulti-rob ot task, inspired the Rob oFlag scenario, and sho what kinds of questions can answ er ab out the mo del. Finally discuss one of the features of CCL, whic is that it can used as programming language as ell as mo deling to ol so that the mo dels write do wn in CCL can directly sim ulated or executed on hardw are. Mo dels The rst step to ard determining that co op erativ con trol system has giv en prop ert is to write down description, or mo del, of what the system actually is to some appropriate lev el of detail. con trol engineer migh supply ou with set of dieren tial equations that describ the closed lo op (system con trol) dynamics of the system. Unfortunately once the con trol rules ha een implemen ted in distributed fashion, simple dieren tial equations description of the system fails to capture man imp ortan qualities, as noted in the in tro duction. Th us, this description ust com bined in some with description of the distributed system that implemen ts the con trol la and that accoun ts for the eects of \spreading" the con trol la out among ultiple pro cessors. In this section review sev eral formalisms for writing do wn (or mo deling) what computation and con trol systems system are and what distributed systems are, starting with Hybrid Automata, then I/O Automata, temp oral logic nally and UNITY. Eac of these formalisms ha qualities
Page 4
need for mo deling Multi-V ehicle Systems, but none is en tirely adequate for our purp oses. Our main goal in this section, esides review, is to shed ligh on sev eral imp ortan issues that led us to our presen use of the Computation and Contr ol anguage (CCL), whic describ in the next sections. Hybrid Automata opular to write do wn mo del of system that has oth con tin uous dynamics and discrete \mo des" of con trol is as Hybrid utomaton or HA [1]. HAs come in man fla ors and summarize their commonalities here. simple nite automaton consists of nite set of states and set of transitions et een states. or example, the lev el of ater in leaky ater tank ma increasing (state one) or decreasing (state two) ransitions et een these states migh corresp ond to op ening (tr ansition on) or closing (tr ansition o an input alv on the tank. An HA extends the idea of simple nite automaton with ontinuous ariables that usually denote ph ysical quan tities (suc as the exact lev el of ater in the tank). An HA ust sa ho its con tin uous ariables hange while an giv en state is activ using dier ential inclusions of the form dt whic migh mean that the lev el of ater in tank is increasing at rate et een m/s and 0.1 m/s. An HA assigns guar ds and rules to eac transition. guar is predicate on the con tin uous state, suc as (read \the alue of is 5"). If the guard on transition from state one to state ecomes true, then the discrete state hanges from one to o. rule is an assignmen t, suc as := whic migh denote the reseting of timer ariable. When transition is tak en, an rules asso ciated with it are executed. An imp ortan asp ect of HAs is that they can omp ose to mak larger mo dels. Roughly the comp osition of HAs and is another HA denoted jj whose state set is (more or less) the cross pro duct of the state sets of its constituen ts. An transitions from and that ha the same lab el ust sync hronize. or example, ater tank con troller migh issue on and o commands that ould sync hronized with (i.e. tec hnically they are the same transition as) the on and o transitions in the ater tank mo del. This form of comp osition is acceptable for small systems. Ho ev er, it is wkw ard for the sorts of systems found in co op erativ con trol. or example, supp ose eac rob ot in ulti-rob ot system is mo deled an automaton with states. set of rob ots is mo deled jj ::: jj whic has states. urthermore, an transitions with the same lab el ust sync hronized in the comp osition, whic ould seem to suggest that the rob ots are not en tirely indep enden in this mo del. I/O Automata ery successful to ol for mo deling distributed systems is the I/O automaton (IO A) mo del [9]. In it, an individual comp onen is mo deled as an automaton as ab e, except with ossibly an innite set of states. ransitions, called actions in IO theory are lab eled as either input output or internal The comp osition of ultiple comp onen ts is uc dieren than the cross pro duct comp osition discussed ab e, ho ev er. If an IO with output action is comp osed with other IO As, then the other IO As ust lab el as an input action. An execution of an IO consists of sequence of actions tak en the comp onen ts one at time. comp onen ma execute an in ternal action, in whic case only its lo cal state hanges. comp onen ma also execute an output action, sa that causes all other comp onen ts with (input) actions lab eled to sync hronously execute their lo cal copies of action thereb hanging their states. The one restriction, called fairness onstr aint is that eac comp onen ust allo ed to tak non-input action innitely often in
Page 5
an execution. The result is an interle aving of actions tak en eac comp onen t, with ccasional partial sync hronization of some of the comp onen ts. In the example ab e, the comp osition of rob ots in this mo del ould ha an -dimensional ector describing its state (still living in an sized space, of course, but someho more parsimonious). urthermore, the in terlea ving execution mo del more naturally reflects the ossible ys that individual comp onen ts ma execute in parallel. In particular, prop ert of an IO is said to hold if and only if it holds for al ossible fairly in terlea ed executions and is, therefore, robust in some sense to ho the actions of the comp onen ts are sc heduled. IO As ha een used extensiv ely to mo del distributed algorithms [9] and ha pro ed quite amenable to analysis. The IO mo del has een extended to handle systems with con tin uous state ariables that hange according to dieren tial equations. The result is the ery comprehensiv e, if somewhat sophisticated, Hybrid I/O Automata (HIO A) Mo del [10]. In the HIO mo del, con tin uous time ariables follo tra jectories according to the equations corresp onding to the state of the HIO A. The tra jectories are punctuated actions tak en the arious comp onen ts. Because the con tin uous time ariables of eac comp onen ev olv in parallel, ho ev er, this can lead to ery complex erall tra jectories that are dicult to reason ab out. emp oral Logic An imp ortan to ol used to describ distributed systems is temp or al lo gic In temp oral logic, reason ab out the ossible eha viors of system (suc as arising from an au- tomaton mo del or program written in Ja a, for example). Beha viors are dened to sequences of states of system. state essen tially \snapshot" of system, migh assign the alue of ariable to and the alue of to true eha vior describ es ho the alues of and hange. It is imp ortan to note that there is no notion of con tin uous time er se in temp oral logic, only the notion that giv en state comes efore or after some other state in eha vior. orm ulas in temp oral logic are of the form \alw ys (written or \ev en tually (or ), where and are predicates on states. or example, if is the eha vior := := := :::; assigning to in then the statemen is true of while the statemen is false of emp oral logic also denes the notion of an action as relation et een states. usually write, for example, to denote relations et een states and sa that is related to the action if the alue of in state is equal to the alue of in state plus one. or example, is true of as dened ab e. emp oral logic can also used to reason ab out real-time and ybrid systems with the careful use of time ariables and et without an further formal mac hinery [7]. temp oral logic form ula sp cies set of allo able eha viors: those eha viors for whic is true. Th us, usually call sp ecication instead of form ula. If and are sp ecications then is true if all the eha viors of are also eha viors of sa that meets the sp ecication An implemen tation, or program, is then essen tially temp oral logic form ula that admits only one eha vior for an initial state. urthermore, sp ecications ma comp osed simple conjunction. In our ulti-rob ot example, if :::; are sp ecications of individual rob ot eha viors, then ::: is their comp osition. complex temp oral logic form ula usually consists of parts: safety sp ecication and fairness constrain t. The safeft sp ecication is used to state what actions the comp onen ts of the system are allo ed to tak to yield new states. The fairness constrain states when comp onen ma tak an action innitely often, for example. In sup er simple ulti-rob ot system, rob ot
Page 6
migh describ ed the form ula 23 whic states that the rob ot ma mo forw ard or sta still (safet y) and that ev en tually it ust mo (fairness). airness constrain ts tend to get fairly complex, esp ecially when real time is considered, and are the main source of complexit in temp oral logic sp ecications. In CCL, whic describ elo w, temp oral logic is the to ol use to state the prop erties of the programs write. particularly imp ortan prop ert is the stabilit of predicate. or example, the form ula 32 states that (a rob ot's osition, sa y) is ev en tually alw ys less than in magnitude. UNITY The non-duality of programs and sp ecications (men tioned ab e) is heralded as the eaut of temp oral logic and has een used with great success to reason ab out concurren systems. An esp ecially useful result of non-dualit is the ease with whic sp ecications ma automati- cally eried using com bination of mo del hec king and automated theorem pro ving. Ho ev er, complication of the safet y-fairness of writing sp ecifcation is that it results in form ulas that do not lo ok ery uc lik programs. In fact, dualit ma mak life simpler. This is the approac tak en the UNITY formalism for parallel program design [2]. In UNITY, sp ecications are written as set of (p ossibly guarded) ariable assignmen ts. arriv at eha vior, simply start with some initial state, and then non-deterministically pic assignmen ts one at time from the set and apply them to the state to get sequence of states. The only requiremen is that eac assignmen is applied innitely often in an eha vior. UNITY is th us kind of theoretical programming language that runs on an dd sort of non-deterministic mac hine in whic particular fairness constrain is built-in. As with CCL (describ ed elo w), temp oral logic turns out to the most con enien to reason ab out sp ecications. The general goal is to determine when form ula is true of ev ery eha vior allo ed sp ecication In con trols, often imagine that the comp onen ts of system are all executing their instructions at more or less the same frequency So the fairness constrain adopted UNITY (and IO As) that merely states \eac pro cess gets to execute eventual ly is somewhat to relaxed. urthermore, writing more complicated fairness constrain ts in temp oral logic, suc as will discussed elo w, can rather cum ersome. This as main motiv ation for our dev eloping CCL, whic describ next. CCL The Computation and Contr ol anguage or CCL, is mo deling language similar in app earance to UNITY, but in terpreted dieren tly The basic unit of CCL program is the guar de ommand (or simply command) whic describ example. ormal denitions can found elsewhere [6]. An example of guarded command is: 10 The part efore the colon is called the guard and the part after it is called the rule. in terpret it as follo ws: If this command is executed in state where the ariable is greater than 10, then new state will result in whic the new alue of is greater than or equal to its old alue plus 1,
Page 7
and the new alue of is 0. All other ariables (those not ccuring prime remain the same. If the command is executed in state in whic is not greater than 10, then the new state is dened to exactly the same as the old state. The execution of command is called step Note that guarded commands can non-deterministic, as is the one ab since it do es not sp ecify the exact new alue for only that it should increase at least 1. complete CCL program consists of parts: An initial predicate that sa ys what the initial alues of the ariables in olv ed are allo ed to e; and set of guarded commands. Here is an example program: Program Initial Clauses true true whic h, sa describ es ho the ositions of rob ots hange. It sa ys that initially the rob ots are oth at osition zero and that they ma mo forw ard meters up on taking step. CCL program comp osition is ery straigh tforw ard. If and ), then their comp osition is simply ). That is, to obtain the comp osition of programs, conjoin their initial clauses and union their command sets. CCL program can in terpreted in arious ys, dep ending on ho its commands are sc hed- uled for execution (or, equiv alen tly ho dene fairness for the system). The most simple sc hedule is: starting with state consisten with the initial predicate, the commands are executed in the order they ere written do wn, er and er again. In this case, could get something lik the follo wing execution for program ... ... more reasonable sc heme, one that accoun ts for the rob ots not executing at the same sp eeds is called the EPOCH seman tics: EPOCH: All clauses in ust executed efore an of them can executed again subsequence where eac clause has een executed exactly once (in an order) is called an ep ch The EPOCH seman tics allo for clauses to executed in an order, as long as they are all \used up" efore an get used again. lo oser sc heme is called partial sync hronization, or SYNCH( seman tics, where is ositiv in teger: SYNCH( ): or an in terv al of eha vior and for an commands, the dierence et een the um er of times eac command is executed during the in terv al ust less than or equal to Of course, in the limit as approac hes innit obtain the familiar UNITY fairness constrain t: that eac clause ust simply executed innitely often. Figure illustrates these dieren in- tepretations with resp ect to the o-rob ot example. As in UNITY, express prop erties of CCL programs as temp oral logic form ulas and dene read mo dels with seman tics if is true of all eha viors allo ed program under the in terpretation An instructiv result is the follo wing. In all in terpretations of CCL, step ma also execute no command at all, thereb lea ving the state the same. This is called stutter step and is useful for tec hnical reasons ey ond the scop of this article. See [8 for discussion of stutter steps.
Page 8
(a) UNITY (b) EOPCH (c) SYNCH(3) Figure 2: Three dieren eha viors for the o-rob ot example. (a) eha vior allo ed the UNITY seman tics. The dierence et een and ma gro arbitrarily large. The lo ops in the eha vior indicate the ccurrence of one or more stutter steps. (b) eha vior allo ed the EPOCH seman tics. After ev ery non-stutter steps, (c) eha vior allo ed the SYNCH(3) seman tics. The dierence et een and is alw ys less than or equal 3. Theorem 3.1 If is CCL pr gr am and is pr op erty, then (i) SYNCH SYNCH 1) (ii) SYNCH (2) EPOCH (iii) EPOCH SYNCH (1) So if prop ert is true of CCL program under giv en in terpretation, it is true for the more restrictiv in terpretation as ell. This theorem along with the standard inference rules for UNITY [2], and other rules for reasoning ab out the more restrictiv in terpretations ab e, are the basis for reasoning ab out CCL programs in general [6]. Mo deling Dynamical Systems: Unlik with HAs (discussed ab e), CCL programs do not mak explicit use of con tin uous time. Also, eha vior should not considered as dening discrete time scale either. mak this clear, supp ose had rob ot whose elo cit is con trolled an external input. If let denote the osition of the rob ot and denote the commanded elo cit then the dynamics of the rob ot can describ ed the dieren tial equations dt u: This equation mo dels the fact that the osition is giv en the in tegral of the commanded elo cit The solution to this equation for constan is (0) ut mo del this in CCL, migh write the program Program Initial Clauses tr ue tr ue u where is small ositiv constan t. The rst command is supp osed to represen the action of the rob ot. It senses its lo cation and sets the new alue of to (just as an example). The second
Page 9
10 10 15 Defensive Zone 10 10 15 0.25 Defensive Zone 10 10 15 0.5 Defensive Zone 10 10 15 0.75 Defensive Zone Figure 3: The rst four ep hs of an execution of athitr (6). Dots along the -axis represen blue defending rob ots. Other dots represen red attac king rob ots. Dashed lines represen the curren assignmen t. command is the action of the en vironmen t, whic accoun ts for the actual motion of the rob ot. In the EPOCH seman tics, for example, the rst command ma executed and then the second, or vic verse in eac ep h. Th us it is ossible that the rob ot executes its command wice in ro w, whic do esn't really do an ything. It is as though the rob ot's sensor sen it the same alue wice in ro w, ev en though the en vironmen (the rob ot's osition) as hanging. Only the execution of the second command the en vironmen accoun ts for an real passage of \time", measured here the actual ph ysical motion of the rob ot. If the second command happ ens to executed wice in ro w, it is as though seconds en efore the rob ot could again sense its osition and act. The reader should try to con vince his/herself that under the SYNCH( seman tics, the amoun of \time" et een eac rob ot action aries et een and seconds. This treatmen of time is mo deling hoice on our part, and it is certianly sub ject to criti- cism. Our elief is that this is go enough for the problems consider in whic decen tralized computation is as uc an issue as ph ysical dynamics, as the extended example in the next section illustrates. The conflict is et een mo deling con tin uous motion and mo deling distributed systems, and CCL has pro ed, at least in our initial attempts, to strik reasonable balance. An Extended Example no reconsider the ob oFlag game discussed earlier. do not prop ose to devise strategy that addresses the full complexit of the game. Instead examine the follo wing ery simple dril or exercise. Some um er of blue rob ots with ositions 0) ust defend their zone x; from an equal um er of incoming red rob ots. The ositions of the red rob ots are The situation is illustrated in Figure 3. rst sp ecify the ery simplied dynamics of red rob ot It simply mo es to ard the defensiv zone in small do wn ard steps. When it reac hes the defensiv zone, it sta ys there (as there is no rule describing what to do if 0). The constan ts min max describ the oundaries of the
Page 10
pla ying eld and is the magnitude of the distance rob ot can mo in one step. Program Initial min max max Clauses The motion la for the blue team is equally simple. Eac blue rob ot is assigned to red rob ot ). In eac step, blue rob ot simply mo es to ard the rob ot to whic it is assigned, as long as taking suc an action do es not lead to collision. Program blue Initial min max +1 Clauses +1 The dynamics of the en tire drill system are dened the comp osition dril (1) ::: blue (1) ::: blue no add simple proto col for up dating the assignmen Eac rob ot negotiates with its left and righ neigh ors to determine whether it should trade assignmen ts with one of them. Switc hing is useful in situations. First, if and ), then and are in conflict: in tercepting their assigned red rob ots requires them to pass through eac other. Second, if red rob ot is to close to the defensiv zone for blue rob ot to in tercept, but not so for blue rob ot then the rob ots should switc assignmen ts. dene the predicate sw itch i; to true if either switc hing the assignmen ts of rob ots and decreases the um er of red rob ots that can tagged or lea es it the same and decreases the um er of conflicts. The proto col is then Program pr oto Initial if Clauses sw itch i; 1) 1) 1) )) and the full rob oflag drill system is giv en rf dril pr oto (1) ::: pr oto 1) Prop erties of rf The program ha dened has sev eral desirable prop erties, whic giv an erview of here. Details can found elsewhere [6 ]. First, the proto col rf is self-stabilizing [4] in that, after an initial transien erio d, it settles in to mo de where no assignmen trades are made. That rf is self-stabilizing is expressed as rf 32 sw itch i; 1) whic states that it is ev en tually alw ys true that no switc hes can made. This is actually true under an fair in terpretation of CCL programs. It can pro ed using Lyapunov st yle argumen sho wing that at eac step certain non-negativ quan tit (essen tially the um er of conflicting assignmen ts) ust decrease if it is greater than zero. Self-stabilization is crucial in distributed computing. It states that no matter ho the net ork is erturb (e.g. pro cess failure), it will ev en tually return to normal op eration. 10
Page 11
Ho ev er, the duration of the transien is imp ortan t. In particular, desire that stabilize efor the red rob ots get to close to the defensiv zone. Note that under simple UNITY-lik in terpretation of the program, the red rob ots ma mo arbitrarily man times efore the blue rob ots do, whic is not our in ten tion. Th us can also sho w, roughly that if the red rob ots are \far enough" then the blue rob ot's assignmen ts will stabilize efore they arriv at the defensiv zone if, for example, the EPOCH in terpretation is used [6]. Another prop ert that can sho wn include that the blue rob ots nev er collide (fairly eviden from the guards in blue ). ha th us succeeded in formally writing down complete description of ulti-v ehicle task, alb eit simple one, that captures ho the rob ots mo e, and ho they comm unicate with eac other to ac heiv their ob jectiv e. urthermore, are able to express the prop erties require of the program and reason ab out them. Programming Because CCL has simple, precise and formal denition, can easily enco de it in simple programming language, whic ha done. The main enet of programming in language lik CCL is that CCL program ears strong resem blance to CCL mo del. In fact, they migh iden tical. Also, the CCL st yle of programming is ery natural to write programs for con trol systems, where often um er of threads (here represen ted CCL programs) are executed in parallel (a comp osition of programs). In terested readers can obtain ersion of the CCL in terpreter, called CCLi, at ttp://www.cs.caltec h.edu/ kla vins/ccl/. The distribution consists of the in tepreter; sev eral libraries for I/O, graphics and in ter/in tra pro cess comm unications; go um er of examples; and user's man ual. CCL compiler is under construction. describ some of the main features of CCLi here. Expressions and yp Chec king Basic CCLi expressions can olean, arithmetic, strings, lists and records. CCLi also pro vides lam da abstractions for dening functions (as in Lisp or ML and also pro vides simple mec hanism for linking co de written in other languages in to CCLi. All expressions in CCLi are strongly yp ed and lists and lam da abstractions are olymorphic. CCLi erforms typ infer enc and typ che cking on programs efore attempting to execute them, and giv es useful error messages efore exiting if our program is incorrectly yp ed. Programs and Comp osition Programs in CCLi are ery similar to ho ha dened them ab e. Eac program consists of name list of parameters, list of ariable declarations and initializations, and list of guarded commands. ariables are considered lo cal to program, unless they are \shared". Th us, CCLi denes new kind of program comp osition, written as follo ws: :::; := :::; :::; sharing :::; whic denes new program in terms of and in essen tially the same as standard CCL comp osition, except for the \sharing" part. An ariable ccuring in but not app earing in the list :::; is lo al to in and similarly for An ariable in the list :::; app earing in or is considered to the same ariable. An example CCLi program illustrating comp osition (although not man other features) is sho wn in Figure 4. 11
Page 12
program plant(a,b,x0,delta) := := x0; := x; := 0.0; true := delta ), := program controller := := 0.0; := 0.0; true := program system x0, a, b, delta := plant a, b, x0, delta controller sharing u, y; Figure 4: An example CCL program dening plant (the system to con trolled), ontr ol ler and their closed lo op com bination. The ontr ol ler program can used to sim ulate the system (when comp osed with plant or executed on actual hardw are if comp ed with hardw are in terface program (not listed). Conclusion Co op erativ con trol presen ts us with the hallenge of building stable con trol systems in distributed con trol en vironmen t. do this, ust determine at what lev el an to mo del the systems build so that can ensure they ha the prop erties desire for them. argued that neither standard con trol theoretic approac nor distributed systems one is completely adequate. also review ed sev eral ossible formalisms that seem to appropriate for the job, nally settling on the Computation and Con trol Language (CCL) whic seems to capture man of the essen tial qualities of co op erativ con trol systems and allo ws us to write succinct and natural sp ecications and reason ab out their eha viors. Finally CCL can used to dene programming language, CCLi, that closely mirrors the CCL formalism so that our programs and mo dels are almost one and the same. ha found CCL useful in other situations esides reasoning ab out sp ecications. ha e, for example, used CCL to express rob ot comm unication sc hemes so that reasoning ab out their ommunic ation omplexity is straigh tforw ard [5]. In addition ha egun to explore other con trol related problems suc as determining the state of comm unications proto col (written in CCL) based on the external mo emen ts of its participan ts [11]. Using formalisms lik CCL to do con trol systems design is oung endea or and man op en problems remain. or example, main shortcoming of discrete mo dels lik CCL is that the notion of robustness to small erturbations, seeming to require metric on the state space, is not ell understo d, uc less dened. This notion is crucial to traditional con trol theory Understanding this and similar problems will enable to ols from con trol theory and distributed computation to used in greater harmon to build the complex con trol net orks that promise to ubiquitous in our future. 12
Page 13
References [1] R. Alur, C. Courcoub etis, T. A. Henzinger, and Ho. Hybrid automata: An algorithmic approac to the sp ecication and erication of ybrid systems. In Hybrid Systems LNCS 736, pages 209{229. Springer-V erlag, 1993. [2] K. M. Chandy and J. Misra. Par al lel Pr gr am Design: oundation Addision-W esley 1988. [3] R. D'Andrea, R. M. Murra J. A. Adams, A. T. Ha es, M. Campb ell, and A. Chaudry The Rob oFlag Game. In meric an Contr ols Confer enc 2003. [4] E. W. Dijkstra. Self-stabilizing systems in spite of distributed con trol. Communic ations of the CM 17(11):643{644, No em er 1974. [5] E. Kla vins. Comm unication complexit of ulti-rob ot systems. In Workshop on the lgorithmic oundations of ob otics Decem er 2002. [6] E. Kla vins. formal mo del of ulti-rob ot con trol and comm unication task. In 42nd IEEE Confer enc on De cision and Contr ol Maui, HI, Decem er 2003. [7] L. Lamp ort. An old-fashioned recip for real time. CM ansactions on Pr gr amming an- guages and Systems 16(5):1543{1571, 1994. [8] L. Lamp ort. The temp oral logic of actions. CM ansactions on Pr gr amming anguages and Systems 16(3):872{923, Ma 1994. [9] N. Lync h. Distribute lgorithms Morgan Kaufmann, 1996. [10] N. A. Lync h, R. Segala, F. aandrager, and H. B. ein erg. Hybrid I/O automata. In Hybrid Systems III LNCS 1066, pages 496{510. Springer-V erlag, 1996. [11] D. Del ecc hio and E. Kla vins. Observ ation of ybrid guarded command programs. In 42nd IEEE Confer enc on De cision and Contr ol Maui, HI, Decem er 2003. 13

About DocSlides
DocSlides allows users to easily upload and share presentations, PDF documents, and images.Share your documents with the world , watch,share and upload any time you want. How can you benefit from using DocSlides? DocSlides consists documents from individuals and organizations on topics ranging from technology and business to travel, health, and education. Find and search for what interests you, and learn from people and more. You can also download DocSlides to read or reference later.