Software Synthesis from
Download
1 / 30

Software Synthesis from Hybrid Automata - PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on

Software Synthesis from Hybrid 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
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


State machines

+ 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)


Interacting Autonomous Robots

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
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
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.


Talk Outline

  • 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
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


Walking model behavior and modes

Shared variable

Time triggered

2x==str

Event triggered

Walking Model: Behavior and Modes

v

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
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
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
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
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
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)


Wagging the tail

25

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
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)


Semantics from model to code

sense/compute/update

sense/compute/update

Sense

Compute

Actuate

Sense

Compute

Actuate

Semantics: From Model to Code

1. 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
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
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
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!


Semantics from model to code1

Sense

Compute

Actuate

Sense

Compute

Actuate

Semantics: From Model to Code

1

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
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


Code from structured designs

u

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
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 experiment1
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
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


Wrap-Up

  • 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 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


ad