Monotone Co-Design Problems; or, Everything is the Same
Andrea Censi
Abstract— This paper describes a theory of co-design. The better computation (which increases the power consumption). objects of investigation are “design problems”, defined as tuples In practice, practitioners decouple problems based on their of “function space”, “implementation space”, and “resources intuition, and then locally refine the designs. space”, along with the relations that relates implementation to function and implementation to resource usage. “Co-design Contribution: This paper describes a theory to deal with problems” are defined as the composition of design problems by co-design problems in a principled way. three operations, roughly equivalent to the concepts of series, A “design problem” is defined as a tuple of “function parallel, and feedback. “Monotone” design problems are those space”, “implementation space”, and a “resources space”, plus for which functions are partially ordered and there is an order- the two maps that relate implementations to functions and preserving map between functions and resources. The main results is that any composition of monotone co-design problem implementation to resources. A design problem defines a is monotone, and that there exists a systematic procedure to set of optimization problems, equivalent to “find the minimal obtain the solution to the composed problem explicitly from the resources needed to implement a given function”. A “co-design solution of the primitive problems. problem” is the composition of design problems using three I.INTRODUCTION operations, equivalent to “series”, “parallel”, and “feedback”, which allows expressing recursive co-design constraints. The title of this paper is inspired by that of a course called “Monotone design problems” are those where both function Everything is the Same: Modeling Engineered Systems taught space and resources space are partially ordered, and that the by Todd Murphey from Northwestern University [1]. The relation between function implemented and resources needed premise of the class is the “systems view” that allows the is monotone (order-preserving). The first main result in this unified modeling of all components of a complex system under paper (Theorem 1) is that the interconnection of any number the same interface, namely differential equations. Formalisms of monotone design problems is still monotone. The second such as bond graphs [2] make it clear that there is a strong main result (Theorem 2) is that if we have a procedure to solve formal equivalence of many heterogenous systems. the primitive design problems, then there exists a systematic So “everything in the same” in the analysis of a system. procedure to solve any co-design problem defined from them. Yet “everything is different” in the design of a system. This paper is a generalization of previous work [3], where Take robotics as the prototypical example of an hetero- the composition was limited to one cycle. The previous paper geneous multi-domain co-design problem. The design of a is a good introduction to this one. The main example in robotic system involves the choice of physical components, this paper focuses on a mechatronic system, while [3] gives such as the actuators, the sensors, the power supply, the examples about computation, control, and illusionism. computing units, and network links if the system is distributed. Not less important is the choice of the software components, II.BACKGROUND including perception, planning, and control modules. All these components define constraints on each other. Each This section includes background material on partial orders physical component has SWAP characteristics such as its and clarifies the notation used. Davey and Priestley [4] and shape (which must contained somewhere), the weight (which Roman [5] are possible reference texts. adds to the payload), and power (which needs to be provided In the following, let , P be a poset. “ P ” will be written as “ ” if the contexthP is clear.i Let P( ) be the power by something else) and excess heat (which must be dissipated P somehow). Analogously, the software components have similar set of . We shall be working with the set of antichains of , denotedP here as A , and the set of upper sets, denoted U P. requirements. For example, a planner needs a state estimate. P P An estimator provides a state estimate, and requires a sensor. Definition 1 (Antichains). S is an antichain if no Everything costs money to buy or develop or license. elements are comparable: for x,⊆ y PS, x y implies x = y. ∈ What makes the design problem non trivial is that these Call A the set of all antichains in . constraints are recursive. For example, a battery provides P P power, which is used by actuators to carry the payload. A Definition 2 (Upper sets). S is an upper set if x S ⊆ P ∈ larger battery provides more power, but it also increases the and x y implies y S. Call U the set of upper sets of . ∈ P P payload, so more power is needed. For control, typically a . . . U is a lattice with UP = , UP = , UP = , better state estimate saves energy in the execution, but requires P . . ⊇ ⊥ ∅ > . P UP = , UP = . Note that we are setting UP = better sensors (which increase the cost and the payload) or ∧ ∪ ∨ . ∩ ⊇ rather than UP = , which is the usual way of making U ⊆ P Andrea Censi
R R
Fig. 12. R R R R
Definition 13 (par). Given two design problems (a) (b) 10 dp = F , R , I , exec , eval , Fig. 15. 1 h 1 1 1 1 1i dp2 = F2, R2, I2, exec2, eval2 , h i V. MONOTONECO-DESIGNPROBLEMS define additional constraintadditional constraint r . par(dp1, dp2) = F, R, I, exec, eval , This section defines a property of design problems called R h i r where: eval monotonicity. The first main result of this paper is that an eval R arbitrary composition of a set of monotone design problems is F = F1 F2, monotone (Theorem 1). The way we prove this is by proving × R = R R , R that monotonicity is preserved for the set of graph building 2 × 2 operationsR = F2par, series, loop. I = I1 I2, × Monotonicity of a design problem is defined as a property exec : i1, i2 exec1(i1), exec2(i2) , h i 7→ h additional iconstraint of the map hdp that associates to each function f the minimal eval : i , i eval (i ), eval (i ) . h 1 2i 7→ h 1 1 2 2 i elements for the objective (1).
Definition 15. The map hdp associates to each function f the set of minimal resources necessary to implement the function:
Fig. 13. hdp : F AR, → f Min eval(i) (i I) (exec(i) = f) . 7→ R { | ∈ ∧ } 21
functions implementations resources
Proposition 2. If dp1 and dp2 are monotone, then series(dp1, dp2) is monotone. Fig. 16.
Proof. If dp1, dp2 are monotone, then the two maps hdp1 functions implementations resources and hdp2 are monotone. We have to prove that hseries(dp1,dp2) Using the map hdp we can abstract over the space of is monotone as well. Call these functions just h1, h2, and h implementations and reason only with the space of functions for brevity. For a fixed f1, the map h traces an antichain 1 and resources (Fig. 16). Throughout the paper, the illustrations in R2 (Fig. 18). What we need to prove is that if f1 increases
of the trade-offA = Min U curves are for intuitionU = only.A In particular, it in F1, then h(f1) increases according to the partial order on A U ↑ 1 might be that the curve hdp(f1) is not continuous, or that there antichains. are only a finite number of solutions. A particular class of design problems are those that are “monotone”, which means that there is a partial order structure Fig. 18. on F and that increasing the required function increases the resources needed. Definition 16 (Monotone Design Problem). A design prob- This property is plausible, considering that h is the compo- lem dp = F, R, I, exec, eval is monotone if F and R are sition of operations that are monotone (Fig. 19), but it will be h i CPOs respecting the DCC and the map hdp is monotone and proved carefully while laying the groundwork for the proof Scott-continuous (Def. 9). of Prop. 3, which is less obvious. Example 4 (Example 1, continued). In the case of the motor 1 design problem, the map hdp assigns to each pair of (speed, functions implementationstorque) the achievableresources trade-off of cost, weight, and required cost ($) Fig. 19. speed (rad/s) voltage/current (Fig. 17). The design problem is monotone weight (g) torque (Nm) if increasing thevoltage required range speed(V) and torque increases the resources needed.current (A) From the definition of series (Def. 12), the semantics of the velocity cost interconnection is captured by this problem: cost ($) speed (rad/s) motor ! design weightFig. (g) 17. using r , f R , r R , weight 1 2 1 2 2 torque (Nm) problem voltage (V) ∈ ∈ Min r2, current (A) torque R2 h : f1 s.t. r h (f ), (3) 7→ 1 ∈ 1 1 ? r f , Let atoms : CDP DP be the map that returns the set of 1 R1 2 → primitive atoms of a co-design problem. The first main result r2 h2(f2). of this paper is that if all subproblems of a co-design problem ∈ Note that (3) describes a map from f to the solution(s) of are monotone, then the co-design problem is monotone. 1 function design resource an optimization problem. The optimization problem specifies problem Theorem 1. For a co-design problem cdp CDP, if all (with the “using” clause) the type of the variables involved: function resource ∈ dp atoms(cdp) are monotone, then cdp is monotone. r1, f2, and r2. In this proof we will manipulate (3) as to obtain ∈ an explicit expression for h. Proof. A co-design problem cdp is defined recursively as the In general, if S S then S S . From r application of the operators par, series, and loop (Def. 11) 1 2 2 UP 1 1 h (f ) in (3), it follows⊆ ⊆ P ↑ ↑ ∈ starting from a set of atoms atoms(cdp). By assumption, 1 1 the atoms are monotone. If all three operators preserve h (f ) UR r . (4) ↑ 1 1 1 ↑ 1 monotonicity, then the co-design problem cdp is monotone. From r h (f ) in (3), it follows The proofs for the three operators par, series, and loop are 2 ∈ 2 2 given as Prop. 1–3. h (f ) UR r . (5) ↑ 2 2 2 ↑ 2 Proposition 1. If dp and dp are monotone, then From r R f in (3), it follows 1 2 1 1 2 par(dp1, dp2) is monotone. r1 UR1 f2. (6) Proof. For two sets A, B, write their product as A ↑ ↑ From (4) and (6), it follows B = a, b a A, b B . With this notation the× {h i | ∈ ∈ } map hpar(dp ,dp ) can be written as h (f ) UR f . 1 2 ↑ 1 1 1 ↑ 2 hpar(dp ,dp ) : F1 F2 A(R1 R2), Using f as defined in (17) and property (19), it follows 1 2 × → × f1, f2 hdp (f1) hdp (f2). (2) h i 7→ 1 × 2 h2(f2) = h2( f2). (7) It is a routine check that all products on the right are antichains ↑ ↑ From the fact that h is continuous and (6), it follows in A(R R ), and that the map so defined is continuous 2 1 × 2 iff hdp and hdp are. h ( r ) UR h ( f ). (8) 1 2 2 ↑ 1 2 2 ↑ 2 From (7) and (5), it follows equivalent to say that there exists a z such that z f(B) but z / f(A). From z f(B) it follows∈ Q that there∈ exists h2( f2) UR2 r2. (9) ∈ ∈ ↑ ↑ a b B such that f(b) Q z. Because B A, it follows ∈ ⊆ From (9) and (6), it follows this b is also in A and f(b) f(A). Because f(A) is an ∈ upper set, any point x such that f(b) Q x is also in f(A). h ( r ) r . (10) 2 1 UR2 2 In particular, z f(A) (contradiction.) ↑ ↑ ∈ From continuity of h2 and (4), it follows Proposition 3. If dp is monotone, so is loop(dp). (11) h2( h1(f1)) UR2 h2( r1). Proof. The map h : F AR can be written as the ↑ ↑ loop(dp) 1 → From (10) and (11), it follows solution of the following problem: using r, f R, h2( h1(f1)) UR r2. (12) 2 ↑ 2 ↑ ∈ MinR r, From (18) and (12), it follows hloop(dp) : f1 (20) 7→ s.t. r h (f , f ), dp 1 2 (13) ∈ h2( h1(f1)) = h2(h1(f1)) r R f . ↑ ↑ 2 From (13) and (12), it follows Denote by hf1 the map hdp with the first element fixed:
h2(h1(f1)) UR2 r2. (14) hf : R AR ↑ ↑ 1 → The left-hand side is a constant that depends only on , which f2 hdp(f1, f2). f1 7→ is fixed during the optimization; call it Bf UR2: 1 ∈ Rewrite r hdp(f1, f2) as . ∈ Bf1 = h2(h1(f1)). r hf (f ). ↑ ∈ 1 2 The optimization problem (3) can then be rewritten as This implies that hf1 (f2) r, or equivalently ↑ ⊇ ↑ using r R , 2 2 hf1 (f2) UR r. (21) ∈ ↑ ↑ h : f1 MinR r2, (15) 7→ 2 From r R f2. it follows that s.t. Bf1 UR2 r2. ↑ r UR f2. (22) The optimization problem is now trivial. In general, the ↑ ↑ From (19), it follows that solution to using x , hf1 (f2) = hf1 ( f2). (23) ∈ P ↑ ↑ MinP x, From (22) and the fact that hf1 is monotone, s.t. B UP x ↑ hf1 ( r) UR hf1 ( f2). (24) is x Min B. So (15) can be rewritten as ↑ ↑ ∈ Therefore h : f1 Min h2(h1(f1)). (16) (24) (21) 7→ R2 ↑ (23) hf1 ( r) UR hf1 ( f2) = hf1 (f2) UR r. From this, it is clear that h is monotone because it is the ↑ ↑ ↑ ↑ composition of monotone functions. And so
hf1 ( r) UR r. (25) Lemma 3. Let f : . Define ↑ ↑ P → Q Using (25), (20) can be rewritten as f : P( ) P( ), (17) P → [Q using r R, S f(x). ∈ 7→ hloop(dp) : f1 MinR r, x∈S 7→ s.t. hf ( r) UR r. Then, if f is continuous: 1 ↑ ↑ 1) If S U then f(S) U . This is equivalent to solving first for the upper set r, and ↑ 2) f is monotone∈ P and continuous∈ Q as a map from U to U . then selecting its minimal elements: P Q 3) f commutes with : using r UR, ↑ ↑ ∈ f( S) = f(S) (18) hloop(dp) : f1 Min MinUR r, ↑ ↑ 7→ R ↑ s.t. 4) For any point x : hf1 ( r) UR r. ∈ P ↑ ↑ We can rewrite everything using R = r: f(x) = f( x) (19) ↑ ↑ ↑ using R UR, Proof. (Monotonicity) By contradiction. Suppose that f is ∈ not monotone. Then there exist two upper sets A, B U hloop(dp) : f1 Min MinUR R, ∈ P 7→ R such that A UP B for which f(A) UQ f(B). This is s.t. hf (R) UR R. 6 1 3
weight motor ! payload design voltage chassis problem current design torque cost velocity problem Sums and products are degeneratespeed monotone design problems. The inner problem is equivalent to finding the least fixed point cost Let be a poset with a monotone operation : . of h : total weight f1 ThenP define dp = F, R, I, eval, exec with◦ FP= ×P → P, Min R UR hf1 (R) UR R . h i P × P UR { ∈ | } I = F, R = , eval = and exec = Id. The resulting power required (W)P ◦ design problem for = + is calledenergy “Σ (J)” and it is drawn as 23 Because hf1 (R) UR R is monotone there exists a least fixed mission time (s) ◦ point (Lemma 5) in Fig. 23. The ( ) on the sides are omitted for clarity. $ . V g lfp(h ) = min R UR h (R) R . cost MCB V f1 f1 UR Fig. 23. total cost UR { ∈ | } cost A $ We have obtained the following explicit expression A PSU Similarly,voltage one (V) defines multiplication, to model relations such for hloop(dp): power (W) g as current voltage = powercapacityand and (J) power time = energy. current× (A) × hloop(dp) : f1 Min lfp(hf1 ). (26) Connect the dangling arrows in Fig. 22 as in Fig. 24, to 7→ R distance obtain a composite design problemenergy with expended functions (voltage, velocity (m/s) Lemma 4 shows that lfp(hf1 ) is continuous as a function of f1. current, mission duration) and output (weight, cost). voltage range V-V voltage range (V-V) Lemma 4. Let , P , , Q be CPOs and f : voltage range V-VMCB V hP i hQ i P ×Q → V $ be continuous. For each x , define A PSU Q ∈ P A g fx : , J Q → Q Fig. 24. y f(x, y). 7→ 24 Then there exists a continuous map f † : that associates power (W) voltage P → Q cost ($) to each x the least fixed point of fx: mission ! current MCB+PSU ∈ P duration (s) f † : , mission time weight (g) Draw a box around the diagram, and call it “MCB+PSU”; P → Q extra power (VA) x lfp(fx). 7→ then interconnect it with the “chassis+motor” diagram Proof. Davey and Priestly [4] leave this as Exercise 8.26. A obtained before (Fig. 25). The dangling arrows on the right proof is found in Gierz et al. [8, Exercise II-2.29]. are weight and cost. This means that we are looking for all possible trade-offs of weight and cost. All other constraints about voltage, current, torque, etc. have been abstracted away. Lemma 5. [4, CPO Fixpoint Theorem II, 8.22] If is a CPO P and f : is monotone, f has a least fixed point. weight (g) P → P velocity (m/s) chassis ! Example 5. Let us finish assembling our robot. We have + motor $ $ 22 already defined the design problem for the chassis (Exam- 22 V extra ! MCB ple 2) and the motor (Example 1). A motor needs a motor payload ! control board (Fig. 20). The functional requirements are the Fig. 25. A +PSU (peak) output current and the output range. mission time output motor cost ($) output motor ! cost ($) extra power currentcurrent (A) (A) controller! controller weight weight(g) (g) board board weight Fig. 20. output output input voltage (V) voltages (V) input voltage (V) This paper did not go into the mathematical details for voltages (V) input current (A) input current (A) each of the design problems to state this formally, but: We also need a battery, or generally a power supply unit. The pending a more accurate formalization, all of the design requirements for the power supply are the output current, problems considered are monotone. Consequently, in the the output voltages, and the capacity. The resources are at diagram in Fig. 25, there is a monotonic (order-preserving) least the cost and the weight (Fig. 21). map between the set of functions (incoming dangling arrows) output current (A) and the set of resources (outgoing dangling arrows). output current (A) power cost ($) power ! cost! ($) Also note that when all functions are fixed, there is still a output voltages (V)supplysupply Fig. 21.output voltages (V) unit trade-off of resources. For the diagram in Fig. 25, this means unit weight weight(g) (g) capacitycapacity (J) (J) that there might be several designs that do not dominate each other according to the (weight, cost) trade-off. 23 Fig. 22 shows the interconnection of MCB and PSU. All optimization problems so far were carefully formulated $ as to always consider trade-offs explicitly. The only case V g MCB V when there is a “unique solution”, in the sense of a unique A design that is optimal, is when the resource space of the Fig. 22. $ A PSU composed problem is a chain, which means that everything g has been flattened down to a scalar objective function. capacity (J)
MCB V V $ A PSU A g J
power (W)
mission ! duration (s) 25
m/s velocity (m/s) mobility+ power $ s In practice,mission time this scalar objective function is usually expressed g 2) Series composition: From (16) we have inextra$. For payload example, (g) a conversion from weight to cost exists and g it is called “shipping” (Fig. 26). Depending on the destination, hseries(dp1,dp2) : f Min hdp2 (hdp1 (f)). extra power (VA) V,A 7→ R ↑ the conversion factor is between $0.5/lbs , using USPS, 2 ∼ to $10k/lbs for sending your robot to low Earth orbit. Thus also hseries dp ,dp can be evaluated explicitly know- ∼ ( 1 2) ing hdp and hdp . m/s $ 1 2 velocity (m/s) mobility+ power cost ($) 3) Feedback composition: the proof of Prop. 3 derived as (26): s mission time $ h : f Min lfp(h ). weight loop(dp) f g shipping 7→ R extra payload (g) where extra power (VA) V,A hf : UR UR, Fig. 26. → R hdp(f,R), Future work: What is missing to obtain a complete robot 7→ design problem is: the sensors, the computing platform, plus thus establishing the need to solve a least-fixed-point problem all of the software (including perception, planning, control). in the space of upper sets UR. From Kleene’s theorem [4, CPO Can all of these be described as monotone co-design problems, fixpoint theorem I, 8.15] it follows that lfp(hf ) can be found as the limit R∞ of an ascending chain R ,R ,R ,... starting interconnected through functions and resources that are posets? { 0 1 2 } from R = UR = R and iterating Rk = hdp(f,R). For robotic sensors, Lavalle and O’Kane [9, 10] described 0 ⊥ +1 quite in detail the lattice of sensors, and their monotonicity Future work: The procedure outline above is not yet a properties. All that work should be reusable in this framework. practical algorithm, because: For computation, some steps in this direction are described 1) The upper sets are, in general, not finitely representable. in [11]. Having a computer on board (the “computation” box Each upper set is equivalent to an antichain (Lemma 1), but in Fig. 27) adds to the payload and power requirements, all the antichain might have infinite elements. concrete quantities measurable in grams and watts. But what is 2) Each loop requires steps before converging. This is not the “function” of a computer? One answer is that the function a problem by itself, because∞ with a few further assumptions of a computer is to run a program. Do programs live on we can make approximation bounds on the convergence. posets? It depends on the representation. Some representations The problem arises if loops are nested; for example, to of programs developed in the field of embedded systems [12, evaluate h takes ∞ steps. 13] such as as “computation graphs” have a poset structure loop(loop(dp)) ∞ and thus can be used naturally in this framework [11]. Future work involves addressing these issues to obtain a practical26 optimization algorithm. velocity “sensing, mobility + power perception mission time REFERENCES planning, SWAP m/s [1] T. Murphey. Everything is the Same: Modeling Engineered Systems. control” Class notes. 2014. URL: https : / / www . coursera . org / course / s cost ($) modelsystems. “computation graph” [2] H. M. Paynter. “Bond graphs for engineers”. In: 1992. Chapter An g + shipping epistemic prehistory of bond graphs. “computation” [3] A. Censi. Monotone Co-Design Problems and Their W Systematic Solution. (Submitted to ICRA 2016). 2015 http://purl.org/censi/2015/mocdp1. [4] B. Davey and H. Priestley. Introduction to Lattices and Order. Fig. 27. Cambridge University Press, 2002 DOI:10.1017/cbo9780511809088. [5] S. Roman. Lattices and Ordered Sets. Springer, 2008 DOI:10.1007/978- 0-387-78901-9. VI.SOLVING MONOTONE CO-DESIGNPROBLEMS [6] J. D. Hamkins. Personal communication. In this case, “personal The second main result of this paper is that the solution of communication” means “He answered my question on MathOverlow”. a co-design problem defined as the composition of monotone 2015 http://mathoverflow.net/questions/219425/. [7] D. I. Spivak. Category Theory for the Sciences. MIT, 2014. problems can be obtained from the solution of the primitive [8] G. Gierz, K. H. Hofmann, K. Keimel, J. D. Lawson, M. Mislove, and problems. D. S. Scott. Continuous Lattices and Domains. Cambridge University Press, 2003 DOI:10.1017/cbo9780511542725. Theorem 2. Let cdp CDP and suppose that all atoms [9] J. M. O’Kane and S. M. LaValle. “On comparing the power of robots”. are monotone. Then ∈ has an explicit expression in In: International Journal of Robotics Research 27.1 (2008). hcdp [10] S. M. LaValle. Sensing and Filtering: A Fresh Perspective Based terms of the functions hdp dp atoms(cdp) . on Preimages and Information Spaces. Foundations and Trends in { | ∈ } Robotics Series. Now Publishers, 2012 DOI:10.1561/2300000004. Proof. By recursion. The statement holds for the base case [11] A. Censi. Synthesis of Resource-Aware Robotic Applications. (Sub- of cdp = dp. Explicit expressions for the composite h were mitted to ICRA 2016). 2015 http://purl.org/censi/2015/rara1. [12] E. A. Lee and S. A. Seshia. Introduction to Embedded Systems - A derived in the proofs of Prop. 1–3: Cyber-Physical Systems Approach. 1st edition. Lee and Seshia, 2010. [13] S. Sriram and S. S. Bhattacharyya. Embedded Multiprocessors: 1) Parallel composition: In this case, hpar(dp1,dp2) is simply Scheduling and Synchronization. 1st. Marcel Dekker, Inc., 2000 the product of hdp and hdp , as was derived in (2): 1 2 DOI:10.1201/9781420048025. h : f hdp (f) hdp (f). par(dp1,dp2) 7→ 1 × 2