Upload
andrea-douglas
View
213
Download
0
Tags:
Embed Size (px)
Citation preview
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/