>> Leonardo de Moura: It is my great pleasure to introduce Sean Gao from CMU. Sean did many interesting things: he defined a [inaudible] that's very interesting. Today he is going to talk a little bit about that. But he is also now working on cyber-physical systems, and I'm eager to learn more about it.
>> Sicun Gao: Thank you. I think it's okay if I just stand here. Okay. Hi, it's really a great honor to be here. I want to talk about our recent work, this emerging field called cyberphysical systems. A cyber-physical system is a combination of digital computation and the physical environment. Basically what you have -- I mean this is actually a part of every sophisticated machinery in our daily life. You have some kind of chip, you have some computation going on and you have the computational part interacting with the environment. It gets information from the sensors, and it has actuators that can control the physical environment.
And all this is done in real time. Those systems are really everywhere. You can see that all the big sort of companies that are not considered software companies, they're really what we could call cyber-physical systems because they need to develop those big machines and also the software that's going on in those machines. And here are some examples, more concrete examples. This one is the autonomous car being developed at
CMU, so it has a lot of sensors and its own actuators. It is driving itself. And this is what you see in a cockpit in a plane. And this is a cardiac pacemaker that people have in their body. And this is the control room of a nuclear plant.
So all those systems, they have this characterization that it's computation combined with some really important physical environments and some physical control problem. The two most important features about these kinds of systems are one, it's very complicated.
So if you want to reason about the system, combined with the dynamics of the environment, it's really a complicated thing. And the second thing, the other thing is that it's very safety-critical. If you think about having a blank screen on your desk top and laptop, the most you're losing is a day's work. But if you have a blank screen on the plane -- which actually happened in the, I think, Air France in 2009 which crashed and I think 200 people died or something, hundreds of people died, and that was because the sensor for the speed of the plane was frozen and the control software on the plane was giving a blank screen saying, "You have invalid data." And it stopped doing anything.
And then, the pilot didn't know how to control the plane at that point. And it was a window of a few seconds that they can make the decision, but they made the wrong decision; they tried to pull the plane up but that's the wrong thing to do. And the plane just crashed into the ocean.
The way that we look at it, I mean, we look at cyber-physical systems first from a model point of view. So you want to sort of understand that underlying, the basic theoretical model for things first. That is, something that we call a hybrid system which is that you have different types of continuous control. Usually in control theory you would talk about a continuous system, and you talk about this one set of dynamics. But in a hybrid system because of the integration of digital computation it's actually several sets of control rules, continuous control, and between them you have discrete mode changes.
If you look at it more mathematically, basically you have different modes and in each mode you have a set of, say, differential equations defining the continuous thing. And then, between the modes you have decisions: if something happens, if the sensor value

gets bigger than something, you go to that mode and if something else happens, you go to another mode. So this is what we call a hybrid system.
People would say that all those things are what we call embedded systems right now.
And the reason that we talk about this new, sort of, field of cyber-physical systems is really you want to focus on the integration of computation physics and sometimes you have communication networks. Well, in the usual setting in embedded systems the problem you are mainly dealing with is the limited computation resource that you have.
But that's not the -- I mean that's an important part of the problem but really the key thing now is the integration of digital things and, let's say, analog things, right, discrete things and continuous things. And it's really the hybrid picture that's important here.
And the most difficult task is to cope with the complexity of those systems and ensure the reliability of those safety-critical systems. As people to start to work in the field, we want to have a guiding roadmap, a methodology that you can understand and use to know the things that you want to do on those systems. And by that it's usually several things that you want to have. First, you want to definitely have a language to talk about the things that you have; you want to have a language to model those systems and you want to have a language that you can specify the properties, the questions that you want to solve. And then, you want to have a systematic theoretical understanding of what you can do, what you can solve. You want to know about the theoretical computability and complexity of the problems that you are facing for those kinds of systems. And then, you want to have a systematic way of dealing with those questions. Those methods that you propose in a systematic way, they should respect the complexity of the problems. And also there should be evidence that you can have realistic tools that can help you to solve those problems using the methods.
And then, in the end you want to have a reasonable understanding about how you can go from theory, from theoretical models, from formal things to actual systems, to a piece of C code in your nuclear control system. So this is the least of things that we would look for in coming up with a methodology, and there are a lot of difficulties with this. Just because of the high complexity of the problem that we're looking at. So first when people try to model separate physical systems, hybrid systems, we realize that -- I will come back to this later. Actually this is going to be the first thing that I'll talk about -- it's quite difficult to have a formal language to contain all the features that you want to have
[inaudible] systems. It's hard to put in, say, differential equations and logical decisions in the same framework. Of course there are a lot of proposals but we're going to say that we have a simple -- not simple but a first-order sort of standard logic that can allow you to express all those things.
But that's not a very easy thing to do. And then, very early on in the proposal of hybrid systems people realized that almost trivial questions about hybrid systems are undecidable, for instance reachability for hybrid systems with constant dynamics or even simpler than that, having two or three variables that are having the dynamics of one. Just those very simple constant dynamics give you undecidable problems because you
[inaudible] and do a lot of fancy things. So there's really a pessimistic outlook at the problem. It looks like nothing can be solved. And the tools, because of this, that are proposed are usually focused on very simple problems. You don't target at realistic systems with nonlinear differential equations and very complicated [inaudible] changes.
The tools are not available to handle those systems at all.

And then, there is a lot of research on hybrid system theory and the transition from the theoretical results to the practical system is not very clear. So I'm going to talk about the language problem first; I'm going to talk about the logic that we're going to use. What we need if we try to come up with a language, we need to have several things. So the first thing is we want to reason about systems that are in the Euclidean space. You want to talk about the real numbers, right? It's not the digital controls any more. And then, you want to have your usual logical constructions; you want to have Boolean connectives and you want to have quantifiers. And then, you want to have all the real functions that are actually needed in the engineering of those systems because the engineers, they're building systems already and they have good theories, good control theory and different things and they can reason about them. They know partially how to build the systems.
If you want to have a general methodology, at the minimum you need to be able to talk about those functions and that includes polynomials, transcendental functions, differential equations and everything else. That is very much beyond what I would say we already have, informal methods. I mean, the logic that we have -- temporal logic, different kinds of first-order theories -- they are really not containing those kinds of actual real functions that we would like to have. This is why we first studied this first-order logic over the real numbers with what we call computable real functions. This concept comes from computable analysis.
You have a real function. The formal of understanding a real function is really to look at it as a mapping from an infinite sequence approximating your argument of the function to an infinite sequence approximating the value of your function. So basically what is a sine function? It's taking a sequence approximating X and there should be something that's giving you this approximation to the value of sine of X. And if you have such a machine, you will say that this function is computable.
So all those functions that are computable in this sense are called type 2 computable functions. It's called type 2 because it's talking about functions on sequences of integers which are like functionals of those functions. So it's type 2 and we don't need into the deep theory of computable analysis, but it's enough to know that almost every numerically computable function is computable in the type 2 sense. So you can have all those, trigonometric functions, exponential functions, differential equations, even
[inaudible] or partial differential equations. As long as you have a reasonable procedure to compute the function numerically, we say that it's very likely that you can prove that it's type 2 computable in theory and it's part of this set of functions.
So we talk about the first-order theory over the real numbers with arbitrary computable real functions. So is LRF: R is the real number -- talking about things over the real numbers -- and this F is the set of arbitrary computable real functions. So it includes all the functions that I just mentioned, and you can write down formulas like this. So you can say this is something that if you give it to an engineer, it will look like something that's saying you have two signals and you are wondering if there are some coefficients such that they are not exponentially far away from each other. So this is the language that you can describe -- I will later show you that's the case as well -- almost every problem in, say, control engineering or these kinds of topics in continuous systems.
But of course the trouble is you can write down those functions, you can define the theory, you can throw in all those functions but the formulas are naturally undecidable.
It's just too complicated because even the simplest trigonometric functions combined

with arithmetic are able to give you natural numbers and that gives you an undecidable theory.
But then we asked this question: If those formulas are so difficult to handle from our perspective then why is it the case that people are solving engineering problems every day? There has to be a reason for the routine procedures that engineers can use to build those systems and to reason about those systems. And the key of the change in perspective is actually we need to look at numerical procedures. We need to have a way of logically, formally understanding numerical procedures that are used in handling those functions.
And this is a notion that we defined. Suppose you have LRF formula, a formula that contains all those computable functions and you can put it in a normal form like this. This is going to be easy to see. You can push all the negations inside and you can -- all you need is to have these two kinds of relations. Right? This is normal form. And we define the delta-weakening of the formula to be something that you only make [inaudible] change on the atomic formulas. You change the zeros. You relax them by minus delta.
So you call this phi of minus delta which is the delta-weakening of the formula. You an also define delta-strengthening of logic formulas by just using positive delta, but we don't need to talk about that here. We're going to mention that later.
Then, we define this notion called delta-decision problem which is instead of asking whether a sentence is true or false, you allow one-sided errors. Okay? So you say that your procedure can return one of the following answers: either phi is false or phi of minus delta -- which is a relaxation, a weakening on the original formula -- is true. So again you can define that phi is true or phi plus delta is false, something like that. It's a dual of this. They're all called the delta-decision problem.
And the key theoretical result that's leading to a positive outlook of using this language is what we call delta-decidability over the real which is the delta-decision problem for any of those formulas, the assumption is that they are bounded which means all of the variables are bounded in bounded domains in the formula. All of those formulas are delta-decidable. This is in sharp contrast to the fact that very simple formulas of that kind, if you only have the trigonometric functions, are highly undecidable. And actually you can have a complexity matter on those sentences which is that sigma in the sentence is just in the polynomial hierarchy [inaudible] by the complexity of the functions that you have. And the easy way of understanding this is that I could tell you the SMT problem, the existential formulas containing trigonometric functions and exponential functions which are all polynomial time computable, continuous functions in the type 2 sense.
The complexity of solving those formulas, the existential formulas is just NP-complete.
So that is if you don't look at the delta-decision problem, if you look at the standard decision then it's an undecidable problem. It's actually highly undecidable. But if you look at the delta problem, it's actually NP-complete. It's actually not harder than the
[inaudible] problem itself. That is a very positive result for this. I mean it's still NPcomplete but it's really much easier than what we expected.
And then, we are done with the language. We can start talking about the models. So a hybrid system -- I just showed some pictures but a real definition is something like this: you can have a set of formulas called the flow. They define the continuous dynamics for each location, each control mode. And you can have set of formulas called the jump that

defines the conditions for you to switch between the modes. And you have invariants and the invariants are the conditions that say, "If you want to stay in this mode, if you want to do the continuous flow in this mode, you have to satisfy some condition." And the initial conditions that you use to start the system.
Everything can be written in these LRF formulas because like I said you can have differential equations. The solutions of differential equations are computable. They are on the side of this F and you can just write down all the continuous systems that you are interested in. So if you look at this automaton and if you look at the execution of those automatons, you're going to see something like this. The trajectory of hybrid automatons are what we call hybrid trajectories. They are basically piecewise continuous, you know, surfaces in the state space because in this connective point, it's the switch between different control modes that you're doing. And if you let it go through time, it's going to be through this.
And on the left-hand side is the notion of hybrid time that's used in producing this picture because you can now consider time to be a two-dimensional structure where you keep track of the discrete changes you have and you keep track of the time [inaudible] you have in each discrete location. And you can define a mapping from here to here and that's the trajectories we're talking about.
This is an example of probably the most popular simple model of the hybrid system which is a bouncing ball. So I didn't draw the ball here but the idea is you start with some ball above the ground and you drop it and make it do free-falling. And you can have the first state to be going down. And when you hit the ground which is when the height of the ball goes to zero, it's going to bump up. And these two modes will alternate many times.
This is actually something we have in our tools that I'm going to mention later. You can just break down those formulas in a simple text. And this is the trajectory which we can also produce from our tool but it's something we just saw; it's piecewise continuous.
So this is like the ball is going to bump back a few times and the velocity changes based on the different modes that you have. And this is a more serious model; this is actually a faithful characterization of this atrial fibrillation problem. So you can consider the heart as a hybrid system, and you can make transitions between different modes. And in each mode you have a set of quite complicated differential equations, non-linear differential equations describing the behaviors. And this is the trajectory of the system that we can produce by our tool as well. So now we're done with the language and the models and we can start talking about the questions we can solve, we want to solve about those systems.
Usually we know that given any system we have, the questions are mostly -- of course you have very complicated problems but the two big categories are safety questions and liveness questions. And in the context of hybrid systems most likely you either talk about reachability, which is a safety property, or you talk about stability which is more like a liveness property because you're going to say that it's going to reach to some point that the system stabilizes. The formula here is a bit complicated. It's not really in the language that I just defined because you quantify over the trajectories, but I'm going to explain how you actually do them using the first order logic that we just defined.
Okay, let's look at reachability first. The standard way, one of the standard ways of dealing with reachability questions is to use bounded model checking. Usually when we

talk about bounded model checking we have in mind something like you have a finite state system and you unwind the system up to some finite [inaudible] and you solve the question of whether some unsafe property is satisfied. But we can do this just using the logic that we just talked about. You can unwind these quick changes in the hybrid system, and in each change you have a continuous flow that is defined by the flow predicate of the system. So you basically start with the initial state and you have a flow that's giving you something like this. You start with, let's say, X zero and you take some time, say P zero, and go to another value. And that value satisfies the flow predicate. It's like a solution of your differential equation at some time point. And then, it's possible that you want to make a jump from the end of your continuous flow to a new set of states and you switch modes. So basically you want to encode the possible transition of the whole system using this logic formula. And then, you say after K [inaudible] you ask the question of whether it can be an unsafe state.
So this is the first-order encoding. And here I'm simplifying a lot of details. Actually you don't see anything about the mode invariant here because actually if you have the invariants, you have to say something like -- The invariant tells you that during the flow from Xi to Xit, you should stay in the invariant. So if you use the logic language to say that, it's like for all t within zero to ti, the invariant should hold. So that's actually exists for all of the sentence if you write everything down. And then, if you have nondeterministic flow, it's even more difficult because your first-order language cannot choose between different possible flows. You need to have -- You can read it in the paper that you need to have another existentially quantified set of variables saying that not only that you are always in the invariant but you can actually follow all of the possible points. And they form one particular trace in the continuous flow.
That's something you encode in using exists for all exists. So actually given this encoding, you directly know that bounded model checking problem for those systems.
The complexity is actually if you don't have invariants, it's just MP to the C where C would be the complexity that you have for the functions in your system. And when you have invariants and undeterministic flows, you will correspondingly have sigma 2, sigma
3 problems. So you can easily obtain all of those complexity results.
Then the delta-decision that we were talking about, it's a relaxation of the standard decision problem. So here you need to make sure that this relaxation is not doing any harm to you. And this is why it doesn't do any harm. Basically if you use the deltadecision procedures, you solve this formula. I omitted the existential quantifiers. All the variables would be existentially quantified. So if you solved that satisfiability problem, either you know that there is no solution or you know that there is a delta-set solution, a delta-set answer. So that corresponds to two different claims. Either you say that a system is safe up to the depth that you have unloaded or the system is delta unsafe which means that you have found a solution to the formula which, you would say, a bug falsifying the safety properties that you have.
But its delta-safe means that your actual system may not have this bug; that's possible because we may be wrong. We may be saying delta-safe and it may be actually unsafe.
But we know that given some perturbation, this weakening on the system, this bug would actually be a bug. So if you think about it, delta can be arbitrarily chosen. So if you're an engineer you can choose a small enough delta such that this answer actually tells you about the robustness problem in your system. So that is why this relaxation is actually helping you with this analysis. So with a delta perturbation, the system has a bug which

means that the system is likely going to be wrong in practice and in reality if you have some kind of error going on. If the delta is really small, you really should be worried.
And then, another way of doing reachability, another category of methods is to use inductive invariants. So you want to show that the systems satisfies some safety property because you an find a set such that the system basically never goes out of the set and that set actually implies your safety property. So you're like doing an induction proof mathematically. So using the formulas, using the LRF formulas, this kind of technique can also be easily expressed. So the basically the idea is that you have this formula encoding the invariant and you just want to make sure that at first the system starts from that invariant and the flow of the system doesn't bring you outside of the invariant. And the jump of the system doesn't bring outside of the invariant as well. And then, in the end the invariant actually implies the safety property.
So one difficulty in the standard approach to this is actually this flow part. So in discrete systems we can say that you are in the invariant now and in the next step you should not go outside of the invariant. But in a continuous system, you don't have this notion of the next step. Right? You don't have the next time point to talk about and you don't know what to write. So there is a lot of research going on saying that for instance you can consider essentially the vector space and come up with something called the differential invariant such that you can just look at the derivatives of the right-hand side part, the right-hand side of your differential equations and make sure that they do not bring you outside of the invariant. But there are many tricky problems with that approach actually.
I'm not going to go into details there.
But what I wanted to say is just using this logic that allows you to write down differential equations, actually you can now throw in a really small epsilon that is good for the deltadecision correctness guarantees that you're going to make. You can choose the epsilon such that you can directly write down this differential equation. And the next step is actually this epsilon step. So again you can delta-decide the formulas that you just listed here. Here, actually, what I omitted was the universally quantified variables. All the variables should be universally quantified and you should ask a solver about whether the negation of that formula is satisfiable. And if that is not satisfiable, you would say true; you would say that the invariant actually holds.
And if the formula is satisfiable, you have found a counter example to the proof rules for the inductive invariant. And what you can claim, using a delta-decision procedure, is that the invariant will fail under, again, delta-perturbations. So this is how you could use the delta-decisions to do unbounded reachability checking. And of course the most difficult question is how you can actually search for those inductive invariants, and there are methods like template-based search where you leave out some parameters. And those questions can also be easily encoded because you just need one more [inaudible] of quantifiers. And you can show theoretical results saying the template-based search for invariants is like sigma 2 to the C. You know? Things like that. They are results that are easy to get.
Now the other type of properties that we usually worry about for hybrid systems is stability. But bounded-time stability really can be encoded just as reachability. And you can define notions like bounded-delta stability and you can again give complexity claims.
That's why I call it a general methodology. It's really you write down things in a logic formula which gives you for free all of those complexity results for those problems. And

unbounded-time stability is a bit like termination for programs. Instead of the [inaudible] function, you would look for Lyapunov functions. And you have conditions for the
Lyapunov functions work to guarantee the stability of the system. And all those you can describe as logic, I just won't write those formulas any more. So I just want to add in this part about our tool that can actually solve the formulas that I just wrote down in all those slides.
It's available at the real web page. You can find it on my home page. And if you just
Google for dReal, I'm pretty sure you can find that. It's open source and it can handle all those formulas that I just mentioned. And for hybrid systems we have a front end where you can actually put in the hybrid system descriptions that I just mentioned and you can ask about reachability questions and different things. So the tool is actually quite scalable. I mean we proved complexity results saying that it's not much harder than SAT, it's not much harder than this NP-complete problem that you actually routinely can handle.
We actually also see this in the performance of our solver. We have handled formulas generated from the bounded model checking of some complicated systems that I'll probably show on the next slide which contain hundreds -- actually, I forgot, 800 - 900 variables -- and they involve, again, like 200 - 300 nonlinear differential equations and you can actually solve them. And there is no serious limitation on the signature that you can have in this tool because basically you can recall that our procedure is using those numerical algorithms. And as long as you can numerically compute something, you can prove that as part of your decision procedure and you can delta-decide those formulas.
So in the tool we allow those transcendental functions, differential equations, et al. So we try to handle models from many domains. We are working on car transmission and flight control and we have results on biomedical devices and cancer therapy. And we're also doing power systems which contain a large number of differential equations with trigonometric functions on the right-hand side that are really big models.
This is just to show you a few systems that we can handle. I won't go into the details of them but you can see that they are complicated differential equations, and these graphs are showing you the solutions. Basically if you want to answer a reachability question, we can give you a witness for the answer that your system can actually delta reach your goal. So those pictures, they are actually quite non-trivial. I mean, each line is actually obtained from a trace of -- How long is it and how -- [Inaudible] it's very big. So it can be like -- Can it go up to gigabyte? No, not yet. Right? But it could.
>>: [Inaudible]
>> Sicun Gao: Yeah. So it's actually non-trivial to produce those graphs. So now I'm going to go more into the design or synthesis problems of those hybrid systems. And the reason that we can talk about them is because we realize -- not that we realize but it's just that everyone knows that it's just about solving the same type of formulas but asking for more solutions for some different variables. All you need to do is parameterize the dynamics that you have in the system. And you want to ask the question, "How do I design the system such that within a certain bounded time you can reach a particular goal?" And that is simply what you can write down with this logic formula, and you can just solve the decision problem with this. And you will get the least of solutions for those parameters.

Here notice precisely speaking when we talk about delta decisions, delta-weakening, you're actually ensuring that your error is on the right side, I mean the correct side. Your error is actually helping you to debug the system. And if you want to solve the parameters actually you will need delta-strengthening instead of delta-weakening because you don't want to say that this solution may work if you have some perturbation.
You actually need to say that this solution should work if you regardless of any perturbations that you have. It's a [inaudible] of the problem.
And actually doing the delta-strengthening is not an easy thing, so this is why synthesis problems in this domain are harder, at least, practically than the verification problems.
It's just because to get the delta-strengthening of formulas to solve those, you need to have under-approximations of the solution sets instead of the over-approximation of solutions sets which are actually the assumption of all the current algorithms in this area.
So the formula -- The algorithm that we implement in our tool that gives overapproximations, all the decision procedures are usually targeting verification problems which require you to give over-approximations. And this whole direction of doing underapproximations when you solve the formulas is just starting. This is something you need for a synthesis problem.
But for now we do handle those problems and we can do a simple design and verification loop because you can sort of find a solution and then try to verify that it actually satisfies your property so that you throw away the errors on the bad side. So you can do things like that for now, but in general you would need a new set of solving strategies. And you can also do a lot of fancy things that are usually talked about in control theory. You can actually do optimal control. Here I'm just using a simple formulation of the thing. Basically you want to reach some goal and you also want to make sure that the cost of your control design is actually at the minimum.
Although here you have one more alternation of universal quantifiers, you are usually okay with replacing this by some goal that you want to have. Basically you don't have to find the absolute minimum cost, the control plan that gives you the absolute minimum cost, but you are okay with finding a plan that's giving you a cost smaller than something. So you can usually approximate this universal quantification here. And then,
I'm not going to go into the details of more things but you can do them. It's just a matter of looking at the problem statement and encoding them as a logic formulas and then understand the solvability, complexity and actually having solvers that can actually solve them.
And in general you can think about a sort of algorithmic control theory; this is probably a term that's used by others as well for maybe different meanings. But basically you can think about encoding all of those control problems into the appropriate logic formulation.
And then, you can use logic solvers like the ones that we just saw to solve those problems directly without a lot of work. You could provide some heuristics that are built in to the solver. You provide this interface that the control engineer could just write down the question that they are asking, and you're just directly calling the decision procedure to solve the problems for them. This is really like lifting what people are doing in the linear dynamic systems to this nonlinear and hybrid domain. In linear systems you usually would have a program running linear algebra, and there are very clever algorithms going on. But if you are beyond that scope, you basically have no systematic way of doing things.

But now we're basically saying you can just write down those formulas in a formal way, in a logical way and then, use the automated reasoning tools -- which are just extensions of the algorithm that you probably originally had but they are now having logic capability for doing the logic decisions which is the hybrid part of our system and the capability of handling nonlinear differential equations which is the nonlinear part. The whole framework becomes this formulation first and then solving next and then, you're done.
So the hope is really to have scalable solvers that contain all the computational power you have in your usual standard algorithms and put them in this logic framework that you can just use to solve those questions.
And then, at the end I want to talk about this mapping from theoretical models, from formal answers to the actual programs that you can actually have in those systems. The observation that started not just our work but I'm sure everyone else's work as well is that the embedded software, although they're very safety critical and they're very complicated, has all of those difficult continuous mathematics going on but the program structure itself is actually pretty simple. If you just look at what you run -- I mean the software car actually we have practical experience with some of that.
You would see just a big loop running at certain frequencies. And within that loop you would rarely see very advanced programming techniques. Most likely you don't even need pointers. You would never have recursive calls. You would never have complicated programs and constructs. And if you think about the problem in more detail, you see that it's really -- I mean the gap between the theoretical model and the actual code you have is really not that big. I mean the gap is not that big. Basically if you have a hybrid system that you can directly write down and any tool, you have the differential equations defined and you have the logical decisions then the car -- Of course this is a very simplified thing, but the basic idea is this. You have this big loop and you just have different cases and you switch between them and each time you execute your program up to a delta T derision. So you're basically just translating the differential equations into difference equations that you have in the program.
And all you actually need to do is to prove that the program that you have and the theoretical hybrid system model that you have, they bisimulate each other up to some error bound. And that error bound of course is related to the delta T [inaudible] pick the behavior of the function, say, the [inaudible] constant, the differential equations that you have and some minor things.
But the big structure is really something like this. So this is simplistic picture of what people are now calling the model-based design idea. So you have formal methods, you have verification and synthesis on the model level. And then, you would directly generate code from that model, and most likely all you need is some mapping from the variables that you have in the theoretical model to the commands that you need in the program. And then, you need to prove the faithfulness of this translation from the theoretical models to the programs. And that is the task that is much easier than the direct code verification that you can think about.
Say you take these tens of thousands of lines of code from embedded software and you want to basically reverse engineer the original code design. That is a very difficult

problem. But if you go from the model first, if you verify your properties and then verify the translation is useful, is reliable up to a certain error-bound, you can actually do this.
And actually this is something that we are trying to do. It's a real small robot that we're currently building at CMU. The property that you want to ensure -- So it's just a very small car. It's not even a car. It's two big wheels and one small one for balancing. And you want to program it so that it can run in any room. And it has sensors on it so that you want to verify that it never hits anything. It never hits a wall, a person walking by; it never hits anything. That's something that you can verify on the model level. And also to have that you actually need to synthesize the controller. For instance the small robot would see a wall, and it needs to reduce its speed. It needs to reduce its velocity. And then, what's the acceleration that you want to give for that?
And that is something you can directly synthesize by solving the logical formulas describing the questions. And the model that we have -- I'm not showing it here -- is really just a one-page hybrid automaton. It's just like three or four control modes and each mode is really not complicated differential equations. It's really a small thing. We have a student from mechanical engineering who doesn't really care about the logic theory or anything. He just learns about this hybrid automaton language that we have and he made this and is making this robot. And then, we're going to just generate the code directly for the robot and see that the formal properties that we verify on the model can actually witness that in practice.
So this is roughly all I want to talk about. The message is that there is this promising framework based on the appropriate logic containing all those functions that you have, in the Euclidean space, et al. And you have automated reasoning underlying the logic. And the usual difficulty either in theory or practice can actually be avoided by our formulations of this delta-decision problem or delta reachability; they are all reasonable things to ask.
And then, this gives you a new set of techniques to handle nonlinear and hybrid systems control and the practical tools that we're developing, the power is going to keep growing.
And we think it's very promising. And the future work is that you want to handle more complicated models, and also now that you have logic solver you can actually basically translate all the sophisticated verification synthesis techniques that you have in other domains, in hardware and software domains, to this field and improve the state of the art greatly.
So that's all I want to say. Thank you.
[Applause]
>>: [Inaudible]
>> Sicun Gao: Right. Right. Right.
>>: But wouldn't you have [inaudible]...?
>> Sicun Gao: Yes.
>>: Because usually [inaudible]...

>> Sicun Gao: Exactly. Exactly. I do. So I think it's actually open whether the sine function itself -- I mean just adding this one single function gives you undecidability. I think that is still open. There are some constructions in the paper. And you can easily show that it's undecidable if you have more complicated computable functions. I have some papers that I can show you and -- Yeah. So my guess is actually for bounded problems if you have the sine function itself, it doesn't give you undecidability. But for a bit more complicated functions, you would have undecidability problems.
>>: I was wondering about the sine [inaudible]...
>> Sicun Gao: Exactly.
>>: ...[inaudible].
>> Sicun Gao: Exactly. Exactly. So yeah, I remember seeing some very complicated constructions about how -- I think it's mainly about how you encode Turing machines using the, yeah, sine function itself, just using the sine function. The construction is very complicated, I remember. And, yeah, actually I don't know if it's still I our current version of the paper but I think we put that as a question, like open question, like, "Is it possible that it's bounded and you don't have delta, just the sine function itself gives you
[inaudible]?" Yeah -- Yeah.
>>: But don't [inaudible]? I [inaudible] equations [inaudible].
>> Sicun Gao: Right. Exactly.
>>: But why did you have X [inaudible]?
>> Sicun Gao: Exactly. That's really -- I shouldn't write it that way. I was just simply finding things just to show that you can do things. But, yeah, so what you need is to put the -- So actually you have this U. So the control is the U variable. That's the thing that you really want to encode. So here I'm not talking about the difference between the control and [inaudible]. So I was simplifying. Usually you just have U and it's some other differential equation that you put in a difference equation for.
>>: Because basically you would have like a sensor [inaudible]...
>> Sicun Gao: Exactly.
>>: ...[inaudible].
>> Sicun Gao: Exactly. Exactly. That's what we're doing for the small robot here actually. We allow the user to clarify some variables to be the sensor variables. And we lead them out in the synthesis, I mean in the code generation. And if we run a simulation of the thing, we can actually make a product of the control itself and the plant model which itself is also another hybrid automaton that gives you sort of the signal. So for instance if you have a map of the room, you can put that in terms of a hybrid system that are giving you different sensor data for different times. So you can take the product of those two automatons and have this full thing running for a simulation. And then, for code all you need is the control part.

>>: I see. Would you ever [inaudible]?
>> Sicun Gao: Exactly.
>>: How precise would you [inaudible] this model? I mean because you have people running...
>> Sicun Gao: Exactly.
>>: ...into your robot? I mean [inaudible]?
>> Sicun Gao: Right. That's definitely related to the actual parameters you have. For instance, the velocity of the vehicle is a wrench. So you property will likely be that if you don't have an object approaching your vehicle with a velocity higher than something...
>>: Okay. [Inaudible] consider the environment [inaudible]...
>> Sicun Gao: Exactly.
>>: ...[inaudible].
>> Sicun Gao: Exactly. Anything relative to -- Yeah. So the final formal claim would be, well, anything that we can actually verify on the model.
>>: I see.
>> Sicun Gao: And that will contain those parameters.
>>: I see.
>> Sicun Gao: So you just have a big thing hitting on the robot, of course it can't avoid that. So under some assumption...
>>: In one of these slides you had [inaudible]. This is [inaudible]?
>> Sicun Gao: [Inaudible].
>>: It's this...
>> Sicun Gao: So this is the front end that we have.
>>: For the real?
>> Sicun Gao: Right. For the real or the reach, whatever we call. So basically you write down this hybrid system thing and, yeah, we just want to follow this theoretical format.
[Inaudible] of something and the [inaudible] differential equations. And the jump it's just
SMT format. And we generate the SMT formulas from that. And, yeah, so this is the front end for bounded-model checking and we're right now doing the invariant-based reasoning right now. And that actually would be a simpler script that you can write to generate the formula.

>>: I see. And [inaudible], right?
>> Sicun Gao: Yes. Right. Right. It's the front end on [inaudible]. Yes.
>>: But do each of those [inaudible] for the real?
>> Sicun Gao: There's no complication [inaudible]. It just translates this hybrid system to
[inaudible]. We feed it to the real --.
>>: I see. But do you [inaudible] things like [inaudible], all of these things that
[inaudible]?
>> Sicun Gao: Mmm-hmm. Maybe we can do some abstraction or --. Yeah, I was mentioning that all the techniques that you have in [inaudible] software application, they should be built into this and you can just scale up to more and more complicated models. Yeah, so we just want to start implying that -- Yeah, if you [inaudible] into it.
Yeah, so we made it open source so --.
>>: Oh, dReach is not open source?
>> Sicun Gao: It is.
>>: Oh, it is.
>> Sicun Gao: Yeah, yeah.
[Multiple simultaneous comments]
>> Sicun Gao: So it's just anyone learning can [inaudible]. Don't you need to stop doing the recording?
>>: I think they know.
>> Sicun Gao: Okay.