- 79 Views
- Uploaded on

Download Presentation
## PowerPoint Slideshow about ' Software Synthesis from Hybrid Automata' - tavorian-ayden

**An Image/Link below is provided (as is) to download presentation**

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript

Software Synthesis fromHybrid Automata

Rajeev Alur

System Design Research Lab

University of Pennsylvania

www.cis.upenn.edu/~alur/

SEES Workshop, Chicago, Sept 2003

Model-Based Design

- Benefits of model-based design
- Detecting errors in early stages
- Powerful analysis and formal guarantees
- Automatic code generation
- Many commercial tools are available for design of embedded control systems (e.g. Simulink)
- Typically, semantics is not formal
- Typically, only simulation-based analysis
- Code generation available, but precise relationship between model and code not understood

+ Dynamical systems

x>68

off

on

dx=-k’x

x>60

dx=kx

x<70

x<63

Hybrid Modeling

Modeling embedded software reacting to continuous world

Past research: Verification, Control, Compositional modeling…

Standardization effort: HSIF (DARPA’s MoBIES program)

Model-based

Concurrency + hybrid

Strategies

Attack/defense modes

Collaboration

C++ programming env

message-driven execution

API for sensing and

actuating

Platform; AIBO robots

MIPS microprocessor

servo-motors

touch sensors

camera

Ideal Design Environment

Can we infer code properties from model properties?

Formal Specification

Environment Model

Performance Metrics

Can we integrate task generation and scheduling?

Programming/Modeling Language

Based on Hybrid Automata

Design and Analysis Tools

Simulation, Verification, Optimization

Compiler +

Scheduler

Libraries in Base Language

Platform Description

Executable Code on

Embedded Processor

Acknowledgements

- Thanks to the Charon group at Penn
- Generating embedded software from hierarchical hybrid models; LCTES’03, with Ivancic, Kim, Lee, and Sokolsky
- Integrated discretization and scheduling (ongoing work with C.G.Arun)
- Caution: Ongoing work (more questions than solutions!); feedback welcome.

- Charon Overview and Case Study
- Sample Research Issues
- From continuous-time model to discrete software
- Missed events and switching errors
- Control blocks and optimal code generation

CHARON Language Features

- Individual components as agents
- Composition, instantiation, and hiding
- Individual behaviors as modes
- Encapsulation, instantiation, and Scoping
- Support for concurrency
- Shared variables as well as message passing
- Discrete and continuous behavior
- Differential as well as algebraic constraints
- Discrete transitions can call Java routines

Software engineering (hierarchy, reuse)

Concurrency theory (Compositionality, refinement)

Hybrid systems theory

Walking Model: Architecture and Agents

- Input
- touch sensors
- Output
- desired angles of each joint
- Components
- Brain: control four legs
- Four legs: control servo motors
- Instantiated from the same pattern

Time triggered

2x==str

Event triggered

Walking Model: Behavior and Modesv

On Ground

Up

x

turn == i

dy = kv

dt = 1

dx = dy = 0

L1

j1

y==0

->

turn++

L2

j2

t==2

(x, y)

y

dx = kv

x < str /2

dy = -kv

Down

Forward

Programming in Charon

- Formal and modular semantics
- modes and agents have compositional semantics in terms of sets of observable behaviors
- Rich and high-level programming model
- Shared variables; synchronous communication
- Switches can be time-triggered, event-triggered
- Verification for linear systems
- Predicate abstraction + Polyhedra based approx.
- But this is just the core, many extensions desirable (e.g. types, interfaces, inheritence…)

Code Generation Case Study

- Front-end

Translate CHARON objects into modular C++ objects

- Back-end

Map C++ objects to execution environment

front-end

back-end

CHARON objects

C++ objects

Executionenvironment

Targetplatform

agent

class agent

scheduler

mode

class mode

diff()

trans()

diff/alge eqn

API

transition

analog var

class var

Code Generator: Front-end

- Variable

C++ class: read and write to variables can be mapped to system API

- Differential equation

Euler’s method: x’ == 100 x += 100 * h

h: step size (0.008 ms in AIBO)

- Algebraic equation

Assignment statement executed in a data dependency order

x == 2y; y == 2z y = 2z; x = 2y;

- Transition

If-then statement

- Mode

C++ class: collection of variables, equations, transitions, and reference to submodes

- Agent

C++ class: interleave execution of each step of subagents

Code Generator: Back-end

- Maps variables in the model to system API of the target platform
- Our approach: “Makefile-like” script

<variable>.{read|write}: <system variables list> <API call><system variable>: <type> <API call> | <#include>

x: joint(TAIL_JOINT)

joint(id).write: rgn SetJointGain(rgn, id, value, newValue);

TAIL_JOINT: #include “def.h”

rgn: Region* #include “def.h”

rgn = FindFreeRegion()

#include “def.h”

class joint: public var {

public:

joint(int id) id(id) { }

virtual void write(double value) {

SetJointGain(rgn, id, value, newValue);

}

static Region* rgn;

private:

int id;

} x(TAIL_JOINT);

What did we learn?

- Mapping structured hybrid automta to code is feasible, in principle
- Many research questions
- Discretization
- Switching errors and non-determinism
- Task generation and scheduling
- Not addressed in this talk
- Logical to physical concurrency
- Platform specification
- Evaluation (e.g. with respect to Simulink)

20

u

x

time

-20

-25

Wagging the Tail- Variables
- x: angle (env state)
- u: speed (control output)
- Non-deterministic switching
- Continuous-time semantics

dx=u

u=+1

x<=25

dx=u

u=-1

x>=-25

Code Generation

1. Generate task

M : {up, down}

sense(x);

if (M==up) {

u = +1;

if x > 25 error;

if (x >= 20) M=down;

}

else {

…

}

actuate(u);

down

up

dx=u

u=+1

x<=25

dx=u

u=-1

x>=-25

2. Determine scheduling parameters

- Period Delta

- Deadline Delta

Hopefully guided by control-theoretic

analysis (e.g. sensitivity, robustness)

sense/compute/update

Sense

Compute

Actuate

Sense

Compute

Actuate

Semantics: From Model to Code1. Continuous-time semantics: Task executes instantaneously at every time point

Continuous

2. Discrete/simulation semantics: Task executes instantaneously at fixed (periodic) discrete points

3. Periodic computation that takes time (predictable)

4. Scheduled computation (variable time)

Bridging the gap between 1 and 2

- Rich theory of sampled control (but mainly for purely continuous systems)
- Discrete-time control design
- Sampling errors
- Accurate simulation (well-studied area)
- How to choose step size
- How to choose integration methods
- Variable step size to ensure events (that trigger mode switches) are not missed
- How can code ensure that events are not missed?

Avoiding Switching Errors

Execute every Delta sec

sense(x);

if (M==up) {

u = +1;

if x > 25 error;

if (x >= 20) M=down;

}

else {

…

}

actuate(u);

down

up

dx=u

u=+1

x<=25

dx=u

u=-1

x>=-25

When can we be sure to avoid error?

In mode up,

if x<20 holds at time T then x should not exceed 25 at time T + Delta

This depends on model dynamics

Requirement on Models

- Δ look-ahead condition: Given a step size Δand a hybrid automaton, check whether for all pairs of invariants I and guards g of outgoing transitions, PostΔ(I & ~g) is a subset of I
- If the model satisfies the condition then no switches are missed
- For systems with linear dynamics this requirement can be checked automatically

Model non-determinism is necessary for implementability!

Compute

Actuate

Sense

Compute

Actuate

Semantics: From Model to Code1

Continuous

Control theory has many tools to bridge gaps between 2,3,4

- u(t) depends on x(t-tau)
- Robustness of controllers
- Integrating control and scheduling

2

3

4

Programming abstractions: Synchrony hypothesis, Giotto …

Why use continuous-time semantics?

- There is no “standardized” discrete-time simulator (or semantics)
- Many tricks, many approaches
- This is a recurring discussion topic in HSIF
- Committing to a discretization may be pessimistic
- Continuous-time semantics has many benefits
- Composable models
- Portable models (or blocks of code)
- Powerful control design tools available

v

x

C1

C2

Code from Structured Designs- How to map control blocks to tasks?

- Many choices for code
- Two tasks: C1 and C2 with their own periods
- One task: Read(x);C1;C2;Actuate
- One task: Read(x);C1;Read(x);C2;Actuate

- The choice can depend on many parameters: computation times, sensitivity ox x to u and v, performance objective

Simulation Experiment

Target

- Goal: Head to target while avoiding obstacle
- Only an estimate of obstacle (model based on sensory vision)
- Estimate improves as robot gets near the obstacle
- Control output: Direction
- Three blocks
- C1: Sense current position
- C2: Compute obstacle estimate
- C3: Decide direction
- Blocks take d1, d2, d3 time units to execute

Obstacle Estimate

Initial Position

Simulation Experiment

Target

- Performance metric defined wrt to continuous model
- Total distance travelled, or
- Error wrt reference trajectory
- Assume d1 < d2,d3
- Two reasonable choices
- C1;C2;C3 executed repeatedly
- C1;C2;C1;C3 executed repeatedly
- Second choice performs better (updated position allows to change direction earlier)

Obstacle Estimate

Initial Position

Optimal Code Generation

- Input
- Set of control tasks (including sensing and actuating)
- Graph of dependencies among them
- WCET estimates for all the tasks
- Some measure of dependence of state on outputs of individual tasks
- Output: Cyclic executive schedule that optimizes something (error wrt continuous model)
- We don’t have a good solution yet
- Note: tasks are platform indpendent, but schedule is dependent

- Generating software from hybrid models with continuous-time semantics has many appeals
- Many theoretical research directions
- Bridging the gap between model and code
- Optimal code generation to follow reference trajectories
- Many engineering issues
- Platform specification for automatic compilation
- Distributed platforms
- Experimentation: Penn UAV platform

Policy Integration for Smart Cards

Policy Automata

- Joint work with Carl Gunter, Michael McDougall
- Java cards offer programmable API
- Goal: Allow dynamic installation of new policies
- Solution: allows modular policies, detects for conflicts and redundancy
- Formal model: Policy automaton is Extended FSM that vote (votes are constraints in defeasible logic) and resolve conflicting votes

Analysis

Compiler

Policy Installer

Global Platform

Java Cards

Download Presentation

Connecting to Server..