Codesign Tools for Embedded Control Systems

Download Report

Transcript Codesign Tools for Embedded Control Systems

Codesign Tools for Embedded Control Systems

Karl Erik Årzén, Anton Cervin, Dan Henriksson, Martin Ohlin, Bo Lincoln, Johan Eker

RUNES

Outline

• • •

Introduction JitterBug

– statistical analysis of how timing affects control performance

TrueTime

– simulation-based analysis of how timing affects control performance

What is Good Control Performance?

• Application dependent • Time-domain criteria – Rise time – Overshoot – Settling time • Frequency-domain criteria – Cross-over frequency – Closed-loop bandwidth – Amplitude and phase margins • Quadratic cost function – System excited by white noise – Statistical (average) measure • ……

Control Performance

Scheduling & Network Parameters (T,D,Prio, Protocol,…) Complex relationship Task Timing Parameters (latencies, jitter, …) Control Performance (variance, rise time, overshoot, ….) Complex relationship

Control Performance in Reality

• Real applications consists of multiple cooperating control loops: – cascade controller – industrial robots – combustion engines – flight control systems • Implemented as one or several tasks • The performance is related to the goal or mission rather than to individual loops • How should we define control performance in this case?

Resource Constraints

• Product-level constraints ($$, size, connectability, …) generate platform-level resource constraints: – Computing speed – Memory and chip size – Communication bandwidth – Power consumption – … • True in spite of the rapid development of computing hardware

Co-Design

• • Increasingly important due to the resource constraints • Several levels: – Mechatronics – Hardware-software – Functionality-dependability –

Control and computing

….

Why control?

– Important class of embedded systems – Unique possibilities to manage uncertainty

Not a New Topic

• In the 1960-70s constrained computer resources and temporal non-determinism were a general problem that was well-known among control engineers – E.g. effects of fixed point calculations on control performance • During the last 20 years a lot of old knowledge has been forgotten • Example: ”Rediscovered” PhD thesis – ”Random sampling and random delays in optimal control systems”, Charles Davidson, KTH Stockholm, 1973

Co-Design Tools

• Especially in embedded systems separation-of concern based approaches are not enough • New types of tools needed that take implementation-level timing effects and constraints into account • Analysis, simulation, synthesis

The Control and Scheduling Co-Design Problem

“Given a set of plants to be controlled and an implementation platform with limited computing and communication resources, design a set of controllers and schedule them such that the overall control performance is optimized”

Dependencies

The nature and degree of difficulty of the codesign problem depend on: –

The RTOS

• scheduling algorithms supported • I/O handling • execution time measurements, overrun handlers –

The scheduling algorithm

• time or event-driven • priority or deadline-driven • schedulability and response time results available • which parameters can be changed on-line

Dependencies

The controller synthesis method

• design criteria • continuous-time or discrete-time design • robustness towards timing variations • active or passive compensation for timing variations –

Execution-time characteristics of controller code

• predictable WCET • sample-to-sample variations • multiple operating modes with different timing profiles

Dependencies

– –

Off-line or on-line optimization

• what information is available for off-line design?

• how accurate is it?

• what can be measured on –line?

• dynamic task allocation • re-optimization at workload changes • feedback from control performance to scheduling algorithm

Network communication

• network protocol • guarantees on network latency • probability of lost packets • global notion of time • time stamping

Co-Design Tool Origins

Hybrid Systems Control Multi-Model Design Environments

Co-Design Tools

Real-Time Scheduling & Computing Networking

Multi-Model Tools

Focus: • modeling, simulation, and design of concurrent, real-time, embedded systems. • assembly of concurrent components • well-defined

models of computation

between components that govern the interaction • use of heterogeneous mixtures of models of computation Examples: • Ptolemy II • Metropolis • MetaH

• • • • •

Ptolemy II

Berkeley / CHESS / Edgar Lee Focus on complex embedded systems that mix widely different operations, such as networking, signal processing, feedback control, mode changes, sequential decision making, and user interfaces Models of computations – Continuous Time – Discrete Events – Distributed Discrete Events – Communication Sequential Processes (CSP) – Discrete Time – Finite State Machine – Process Networks – Synchronous Data Flow & Dynamic Data Flow – Giotto – Synchronous/Reactive – Timed Multitasking – ….

http://ptolemy.eecs.berkeley.edu/ptolemyII/ Status: Public domain, Version 5.0 Beta released in May 2005

Metropolis

• Gigascale Systems Research Center (GSRC) – Berkeley + Politechnico di Torino + Cadence – Alberto Sangiovanni-Vincentelli • Design environment for heterogeneous systems • An infrastructure, a tool set, and design methodologies for various application domains • Tools – simulation – synthesis – analysis/verification • Appears to be less homogeneous than Ptolemy II • http://www.gigascale.org/metropolis/ • Status: Released in the open domain in September 2005

MetaH

• Honeywell • Language and toolset for developing reliable, real-time multiprocessor avionics system architectures • Describe the interfaces and properties of software and hardware components and combine them into an overall integrated system. • Tools for analyzing real-time schedulability, reliability, and partition integrity • Targeting to avionics real-time execution environments • http://www.htc.honeywell.com/metah/ • Status unclear

Hybrid System Tools

• Continuous + discrete dynamics – differential equations – automata • Continuous systems with – events – switches – modes • Not well suited for modeling real-time computations

Hybrid System Tools

• Simulation tools – sometimes with automatic code generation • Examples – Simulink + Stateflow – SCICOS • public domain “Simulink” • connection to SynDEx CAD software for rapid prototyping of distributed r-t embedded applications – Modelica/Dymola – Sildex / RT-Builder • based on the SIGNAL language • mathematical foundation – HyVisual • based on Ptolemy II

Hybrid System Tools

• Formal verification tools – Charon (UPenn) • agents with modes with continuous and discrete behaviour – CheckMate (CMU) • verification toolbox on top of Matlab •

threshold event-driven hybrid systems

– Masaccio (Berkeley) • formal model for hybrid dynamical systems built from atomic discrete components (difference equations) and atomic continuous components (differential equations) by parallel and serial composition • hybrid automata – Shift (Berkeley) • programming language for describing dynamic networks of hybrid automata • continuous-time phases separated by discrete-event transitions – Hysdel (ETHZ) • describe discrete hybrid automata and generate piecewise affine systems (PWA) – UPPAAL (Uppsala/Aalborg) • integrated tool environment for modeling, validation and verification of real-time systems modeled as networks of timed automata, extended with data types (bounded integers, arrays, etc.). – Others: LSTools, HDV, PHAVer, HyTech, d/dt, Requiem, Ellipsoidal toolbox, HSOLVER, ……

Hybrid System Tools

• Restrictions necessary in order to apply formal methods, e.g.

– timed and hybrid automata – integrators (clocks) with different speed – piecewise affine systems • In addition to the tools mentioned here there are additional tools developed within the Petri Net community

Networking tools

• Based on tools from the networking community – analyze/simulate communication protocols – analyze/simulate ad hoc networks, e.g., sensor networks • Extended with support for computations and continuous dynamics • Still focused on the networking aspects

Networking tools

• • • • • • • Examples: ns-2 – most widely used wired/wireless network simulator – movement models for mobile applications OMNeT TOSSIM – TinyOS sensor network simulator – TinyOS code + ZigBee networks NAB (Network in A Box) – large scale sensor networks Network/control cosimulation tool (Branicky) – based on ns-2 – extended with continuous dynamics to model plants Ptolemy 2 – extended to suppotr wireless sensor networks …..

Real-Time Scheduling

• Scheduling simulators and/or microprocessor simulators/emulators extended with networking and/or continuous dynamics • Examples: – RTSIM (Pisa) • extended with continuous dynamics (OCTAVE) – SIMICS (Virtutech) • software emulation on various target models • extended with networking support

Control-Based Tools

• Basis in continuous control & dynamics • Extended with support for computing and communication • Often based on Matlab-Simulink • Examples – TrueTime (Lund) • Co-simulation of rt-kernels, networks and continuous plant dynamics in Simulink – Jitterbug (Lund) • Analysis of control performance subject to timing variations • Matlab – AIDA Toolset (KTH) • Matlab/Simulink-based environment for model-based codesign and analysis of real-time control systems • support for timing analysis – XILO (KTH) • related to AIDA • also supports fault injection

Outline

• • •

Introduction JitterBug

– statistical analysis of how timing affects control performance

TrueTime

– simulation-based analysis of how timing affects control performance

Jitterbug

• Matlab-based toolbox for analysis of real-time control performance • Evaluate effects of latencies, jitter, lost samples, aborted computations, etc on control performance • Analyze jitter-compensating controllers, aperiodic controllers, multi rate controllers • Calculation of a quadratic performance criterion function • Packaging of existing theory for linear quadratic Gaussian systems and jump-linear systems Developed by Bo Lincoln and Anton Cervin

Cost Function Computation

Cost Function Computation

Cost Function Computation

Cost Function Computation

Cost Function Computation

Cost Function Computation

Jitter

• What if the delay L is random?

– Impossible to obtain closed-form expression for J • Alternatives: – Analysis with Jitterbug – Simulation with TrueTime

Jitterbug Analysis

• System described using a number of connected continuous-time and discrete-time transfer function blocks driven by white noise Distributed Control Loop: Actuator Plant Sensor Controller

Jitterbug Analysis

• The execution of the blocks is described by a stochastic timing model expressed as an automaton • Each state can trigger one or more discrete systems • Time intervals are represented by discrete probability distributions

Jitterbug Model - Example

Jitterbug Example Script

% Corresponds to zero delay

Jitterbug example script

Simple Example

Timing model:

L io

1 2 S(z) K(z) • P(s) – Process (Inverted pendulum) • S(z) – Sampler (perfect sampling) • K(z) – Controller + actuator • L io – input output latency

Demo

Results

More complicated cases

Aperiodic Systems

• Jitterbug supports both periodic and aperiodic systems • Periodic: – >calccost – Analytical solution, reasonably fast • Aperiodic: – >calccostiter – Iterative computation with possibly very slow convergence

Internal Workings (periodic case)

Computational complexity (periodic case)

Markov Models

Timing Nodes: Markov Nodes: 1   [0 0.1 0.2 0.3 0.4] 2 1 1 1 1 0.4

0.3

0.2

0.1

2

Markov Models

Continuous Dynamics 1 2 Discrete Dynamics

Jitterbug Limitations

• Only linear systems • Simplistic timing model – Delays assumed to be independent from period to period – Delay characteristics may not change over time • Only quadratic performance measures • Statistical analysis • Assumes that timing distributions are known • No GUI yet

Pros and cons

Pros: – Analytical performance computation – Fast to evaluate cost for a wide range of parameters – Guarantees stability (in mean-square sense) if cost is finite Cons: – Simplistic timing models – Only linear systems and quadratic costs – Requires knowledge about latency distributions

Jitterbug Limitations

Only linear systems: – Linear analysis and linear control is often good enough – However, certain non-linear elements are crucial for good control performance, e.g., anti-windup schemes in the case of actuator saturation – Cannot be analyzed in Jitterbug

Jitterbug Limitations

Simplistic timing model: – Delays assumed to be independent from period to period – Delay distributions may not change over time – Certain common controller implementation methods

Common Implementation Method

nextTime = getCurrentTime(); while (true) { executeController(); nextTime = nextTime + samplingPeriod; delayUntil(nextTime); }

Cannot be analyzed

Jitterbug Limitations

Statistical analysis: – The calculated cost is an expected value – All results only hold in a mean-value sense • Not suitable as a basis for formal verification – Timing scenarios with probability zero are disregarded by the analysis • E.g. switching-induced instability

Jitterbug Limitations

Latency distributions: – Assumed known – Where do we get them?

– Existing scheduling theory can at best give worst-and best-case values – Need for scheduling theory that provides more statistical information – TrueTime can be used to generate the distributions through simulation • But, then why not also use TrueTime to evaluate the cost functions?

Jitterbug Textual Interface

Timing model: 1 S(z) Node Id 

Block Id 

N = addtimingnode(N,1,Ptau,2);

N = adddiscsys(3,K,2,2);

2 K(z)

Jitterbug GUI • Under development

• • Java GUI System model Timing model Matlab Text Console Matlab Compute Engine

JNI / C interface

Jitterbug Availability

Jitterbug 1.2 can be downloaded from

http://www.control.lth.se/user/lincoln/jitterbug/

Outline

• • •

Introduction JitterBug

– statistical analysis of how timing affects control performance

TrueTime

– simulation-based analysis of how timing affects control performance

Separate PDF presentation

Future Development

• Port the network simulation parts to Modelica • Port TrueTime to Scicos/Scilab • Increase the possibility to use production C code directly in the simulator Simulink Control Design Code generation Manuel conversion Integration in ECU TrueTime ECU simulation Simulink Control Design Code generation TrueTime ECU simulation Integration in ECU