Formal methods for Embedded Systems

Cours E1Master STIC UNSA

Spécialité Systèmes Embarquésannée 2006/2007

Robert de Simone

INRIA Sophia-Antipolis

Part I: general introduction

Formal methods in the design flow of embedded systems

Chapter 1.1

Embedded Systems specifics

Embedded SystemsComputing power outside the desktop or mainframe

computers, with different interfaces:

• Mobile phones and electronic appliances (cameras, TVs, DVD or MP3 players, copiers…)

• Transportation (cars, planes, subways,…)• MP-SoCs (STI Cell, TI OMAP, NXP Nexperia,…)With multicore chips and heterogeneous platforms, many

similarities in design methodologies may appear, with varying importance of cost, reliability, power consumption…

What remains specific to embedded systems ?Platform-Based, System-Level design

Embedded Systems specifics• Heterogeneous applications

– Signal processing (multimedia codecs, control of physical devices)

– Communications and security (wireless, …)– Man-machine interfaces and multimode control

• Heterogeneous execution platforms– Often tuned to the applications (and designed after

them)– Mixed hardware/software, dedicated reconfigurable

parts, MP-SoCs (multiprocessor systems-on-chip)

• Stringent constraints– Time, price, energy/power, memory space budgets

Need for Model-Driven Approach at system-level

Shift example: from UML to SysML

AutoSar

TI OMAP

Applications can be dispatched to the ARM11 general-purpose processor (GPP), or theTMS320 DSP, or a mix of both

Tensilica Xtensa

Instruction sets (ISS) can be custom-made to better fit the application demand

STI Cell

Platform-based design

• Independent modeling of application and execution platform• Later, optimized mapping (allocation) of functions onto resources, with

communication synthesis (and optimization)• Often, architecture changes after the application is defined.

Comm & Control Data ComputationApplication sideApplication side

Architectural sideArchitectural side

Allocations (operations to resources)

«Meet-in-the-middle»«Meet-in-the-middle»

(Synchronous) state diagrams

Activity (block) diagrams

HW/SW platform model

Structure/deployement diagrams

Formal models Model-Based DesignModel-Based Design

System-Level DesignSystem-Level Design

Platform-Based DesignPlatform-Based Design

Chapter 1.2

Methodology

Design stages

Product design cycle

• Large projects (engineering aspects)• Different teams, few interactions• Different companies, sometimes competitors

(e.g., car manufacturers and OCM providers)• Standardisation pressure• Legagy code and knowledge, lines of product

Test & validation take most engineering time, become untractable because of complexity !

User requirements remain informal or at least not used through design

Cycle de developpement/ design cycle

Requirements capture Cahier des charges

(Initial) specification(Initial) specification

Architectural division

Component design Component design / programmation/ programmation Component testingComponent testing

Integration

IP component reuse

libraries

Sign-off /Recette

Global testing

Implementation

correct Product validation?

Currently products rarely meet their initial requirements,which are already inaccurate or obsolete or unreachable. Big problem if safety-critical design (human lives), or money-critical (company’s life)

• We shall focus mostly on functional correctness (vs extra-functional: physical real-time, consumption,...)

Requirements capture Cahier des charges

Sign-off /RecetteMatch ?

Simulation models

High-level abstract modelHigh-level abstract model

Refinement

Global testing

Abstraction

Simulation

Test plan generation

Simulation modelsSometimes physical prototypes, sometimes software

approximation of desired system

• Very helpful for:– Tuning the specification (runs faster than full implementation)

– Predicting the system’s behavior and suggesting tests– Performing crude early analysis of performance and

dimensioning

• But:– No relation guaranteed between simulation and

further implementation– Not meant for code production (synthetizability issue)

• Formalisms: Matlab/Simulink, SystemC/C++,…

IEEE Std 1666-2005 Standard SystemCNOTE 1—The scheduling algorithm implies the existence of three causal

loops resulting from immediate notification, delta notification, and timed notification, as follows:

— The immediate notification loop is restricted to a single evaluation phase.— The delta notification loop takes the path of evaluation phase, followed by update phase, followed

by delta notification phase and back to evaluation phase. This loop advances simulation by one delta cycle.

— The timed notification loop takes the path of evaluation phase, followed by update phase, followed by delta notification phase, followed by timed notification phase and back to evaluation phase. This loop advances simulation time.

NOTE 2—The immediate notification loop is non-deterministic in the sense that process execution can be interleaved with immediate notification, and the order in which runnable processes are executed is undefined.

NOTE 3—The delta notification and timed notification loops are deterministic in the sense that process execution alternates with primitive channel updates. If, within a particular application, inter-process communication is confined to using only deterministic primitive channels, the behavior of the application will be independent of the order in which the processes are executed within the evaluation phase (assuming no other explicit dependencies on process order such as external input or output exist).

Drawn from Simulink on-line doc…

Avoiding Invalid LoopsSimulink allows you to connect the output of a block directly or indirectly (i.e., via other blocks) to its input, thereby, creating a loop. Loops can be very useful. For example, you can use loops to solve differential equations diagramatically (see Modeling a Continuous

System) or model feedback control systems. However, it is also possible to create loops that cannot be simulated.

Common types of invalid loops include:•Loops that create invalid function-call connections or an attempt to modify the input/output arguments of a function call (see Function-Call Subsystems for a description of function-call subsystems)•Self-triggering subsystems and loops containing non-latched triggered subsystems (see Triggered Subsystems in the Using Simulink documentation for a description of triggered subsystems and Inport in the Simulink reference documentation for a description of latched input)•Loops containing action subsystems

You might find it useful to study these examples to avoid creating invalid loops in your own models.

copyright © The MathWorks

Formal model

Formal methods

Component testingComponent testing

Integration

libraries

Sign-off /Recette

Global testing

RefinementAbstraction

Synthesis

Com

pilationCorrect-by-Construction Implementation

Test pattern generation

& result analysis

Abstraction

Equivalence Checking Property Checking

Model Checking

V&V (Validation and Verification)?

• Validation: the product matches its intended specification

• Verification: the product does not malfunction (bug-free)

• 2 issues:– Requirement properties must be clear and complete enough (and

hopefully little ambiguous); they can be represented as logical properties, or operational abstraction of ideal behaviors

– The development process must preserve them (and it should be established); also the requirements and initial specs should be consistently updated in case of downward changes

Problem: clear semantics ?

Formal methods: 3 aspects• Syntax: Models should come with specification languages

that are simple formalisms, with few clear concepts (too often engineers prefer multiplicity of ad-hoc features tamed by practice)

• Semantics– should provide unambiguous mathematical meaning to

models, so that their relation to implemented product can be asserted and proved; should be machine-independent

• Analysis techniques (models at work)– Abstraction/refinement (& abstract interpretation)

Equivalence-checking

– Assertions and properties (black-box or white-box)Property-checking

– Some properties genericModel-checking, algorithmic and decidability issues

– Test generation

Semantics: flavors• Axiomatic

– Inherited from naïve approach, insert assertions and assumptions at program locations, then relate their truth values (ex. Floyd-Hoare 1967)

– Most popular for sequential data-computation, mechanical theorem proving (proof assistant)

• Operational– Provides meaning as a virtual state machine, with

program constructs structurally “building” behavior transitions (ex. Milner’s CCS, 1979)

– Most popular for distributed or concurrent systems• Denotational (less developed in this class)

– Translation of program into a mathematical structure, where meaning is already defined often through fix-point constructions) (ex. Esterel to circuits, 1992)

– Often coupled with abstraction techniques

Part II: modeling

What kind of models do we need ?

ES modeling featuresSeparation of concerns:• Data-computation (data-flow)

– Recursive functions and data-types– Pre-, post-conditions, invariants– Block-diagrams and pipe-lined treatments– In ES world, often rather static framework

• Communication and control (control-flow)– Concurrency : Synchronous or asynchronous

tasks/processes (same clock or different speeds)

– Communication: synchronous or asynchronous (handshake or buffered), blocking or not.

– Protocols, Hierarchical Finite State Machines

Systems: structure and behavior

In general, a system is:

• constituted of components, interacting in a collaborative or hierarchical fashion (structure)

• evolving, as a result of the composed functional of its components (behavior)

a system changes state through time; time is counted in number of actions/operations

• In highly dynamic systems the division is blurred, as structure is transformed by behaviors; rarely the case in embedded systems (never in our case)

See UML and elsewhere, models divided between structural and behavioral ones

Systems : states/transitions

A global state (or configuration) is an instantaneous “snapshots” of all the values of the components ingredients:

• Data values (memory, registers) : Store

• Control values (program counters…) : ConfigurationBy performing/executing/firing an action/operation/transition,

the system goes from one state to the next

• Recall: S (and S’ ) can be a complex structure, and act a complex behavior

S S’act

Symbolic data & abstraction

• The control state correspond to well-defined program locations• Further abstraction is possible on predicates• The division between data and control can be fuzzy and changeable• Embedded systems (often):

– finite (control) state structure– Finite (static) set of data variables

Current control state

Next control state

Precondition predicate

Postcondition predicate

Ctrl_act

update

FSMs with data

Textual: guarded Command

prev/from<origin_control_state_(predicate)>

provided<conditional_guard_predicate>

(on data values and/or input events)

then<action > (assignment, computation or event production)

next/to<target_control_state_(predicate)>

Coin?(50cents)

Coin?(50cents)

Coin?(1euros)

Left_button? /deliver(coffee)

Right_button? /deliver(cappucino)

/Change!(exp)

Formalisms• Expressing properties:

• Floyd-Hoare foundations• JML (for Java)• PSL/SuGaR (from CTL/LTL temporal logics)

• Operational (2 styles): Models of Computation– Hierarchical finite-state machines

• CCS, CSP (async proc, sync comm)• Esterel/SyncCharts, SCCS (sync proc, sync comm)

– Process networks• Petri nets with variants (async), SDF• Kahn networks (async comm) • Lustre/SCADE, Signal/Polychrony (sync)

Course outline

• Properties and assertions– Annotating the spec: white box– Temporal observations: black box

• Hierarchical automata and variants– SOS semantics of CCS with examples– SOS semantics of Esterel with examples

• Data/control flow networks and variants

• Model-checking algorithms and applications

Sites• Modeling formalisms– Esterel/SCADE:

http://www.esterel-technologies.com/technology/– Ptolemy: http://ptolemy.eecs.berkeley.edu/– Metropolis: http://www.gigascale.org/metropolis/

• General-purpose Model-Checkers– SPIN: http://spinroot.com/– SMV: http://www-cad.eecs.berkeley.edu/~kenmcmil/

• Software model-checking– Bandera: http://bandera.projects.cis.ksu.edu/– Blast: http://www-cad.eecs.berkeley.edu/~blast/– Slam: http://research.microsoft.com/slam/

• Assertions and properties– JML: http://www.jmlspecs.org/ – PSL/SuGaR: http://www.pslsugar.org/

http://www.haifa.il.ibm.com/projects/verification/sugar/• Abstraction

– ASTREE: http://www.di.ens.fr/~cousot/projets/ASTREE/