language workbenches, embedded software formal verification · a dsl is a focussed, processable...

Language Workbenches, Embedded Software and

Formal Verification

Markus Voelter independent/itemis

[email protected]

www.voelter.de voelterblog.blogspot.de

@markusvoelter +Markus Voelter

Daniel Ratiu ForTISS GmbH

[email protected]

www.fortiss.org

mbeddr

1

An extensible version of the C programming language for Embedded Programming

C the Difference – C the Future

gefördert durch das BMBF Förderkennzeichen 01|S11014

An extensible C with support for formal methods,

requirements and PLE.

IDE for Everything

A debugger for all of that

SDK for building your own Language

Extensions!

IDE for Everything

JetBrains

MPS Open Source Language Workbench

Challenges in embedded software

development

Abstraction without

Runtime Cost

C considered unsafe

Program Annotations

Static Checks and

Verification

Product Lines and

Requirement Traces

Separate, hard to integrate Tools

Subset of Available

Extensions

All of C (cleaned-up)

Retargettable Build Integration

Native Support for Unit Testing

and Logging

Physical Units

Components Interfaces Contracts Instances

Mocks & Stubs

State Machines +

Model Checking

Decision Tables +

Consistency and Completeness

Checks

Support for Frama-C

+ High-level Iterators

IDE Support for Frama-‐C Annota3ons

Generate Frama-‐C Annota3ons from Higher-‐level Constructs

Requirements Tracability

Product Line Variability

Status and

Availability

http://mbeddr.com

LWES Language Workbenches

for Embedded Systems

Developed within

gefördert durch das BMBF Förderkennzeichen 01|S11014

Most is Open Source (EPL); the

rest will follow this year.

support for graphical early

2013

integration in early 2013

Language Engineering

w/ Language Workbenches

2

Introduction

A DSL is a focussed, processable language for describing a specific

concern when building a system in a specific domain. The abstractions

and notations used are natural/suitable for the stakeholders who

specify that particular concern.

Concepts (abstract syntax)

(concrete) Syntax

semantics (generators)

Tools and IDE

more in GPLs more in DSL Domain Size large and complex smaller and well-defined

Designed by guru or committee a few engineers and domain experts

Language Size large small

Turing-completeness almost always often not

User Community large, anonymous and widespread

small, accessible and local

In-language abstraction

sophisticated limited

Lifespan years to decades months to years (driven by context)

Evolution slow, often standardized fast-paced

Incompatible Changes almost impossible feasible

C

LEGO Robot Control

Components

State Machines

Sensor Access

General Purpose

Domain Specific

L

a b

c

d

e

f

g h i

j

k

m

n

o

with many first class concepts!

Big Language

L

α β

λ ω

δ

Small Language

and poweful concepts with a few, orthogonal

my L

α

β

a b c

d e f

g h i

j k l

Modular Language

composable modules with many optional,

an abstraction or simplification of reality

ecosurvey.gmu.edu/glossary.htm

Model

an abstraction or simplification of reality

ecosurvey.gmu.edu/glossary.htm

which ones?

what should we leave out?

Model

… code generation … analysis and checking … platform independence … stakeholder integration … drives design of

language!

Model Purpose

Programs Languages Domains

Domain

body of knowledge in the real world deductive

top down

existing software (family)

inductive bottom up

Domain

existing software (family)

inductive bottom up

Domain

Domain Hierarchy

Domain Hierarchy

all programs

embedded software

automotive avionics

Exten ded C

Example

Heterogeneous

Exten ded C

Example

Heterogeneous

Heterogeneous C

Statemachines Testing

Heterogeneous

Exten ded C

Example

Domain Hierarchy

more specialized domains more specialized languages

Reification

Dn

Reification

Dn

Dn+1

==

Reification

== Language Definition

Transformation/ Generation

? Overspecification! Requires Semantic Analysis!

! Declarative! Directly represents Semantics.

Linguistic Abstraction

Def: DSL

A DSL is a language at D that provides linguistic abstractions for common patterns and idioms of a language at D-1 when used within the domain D.

Def: DSL cont’d

A good DSL does not require the use of patterns and idioms to express semantically interesting concepts in D. Processing tools do not have to do “semantic recovery” on D programs.

Declarative!

Another Example

Exten ded C

Example

Another Example

Turing Complete! Requires Semantic Analysis!

Exten ded C

Example


Exten ded C

Example


In-Language Abstraction Libraries Classes Frameworks


In-Language Abstraction User-Definable Simpler Language

Analyzable Better IDE Support


In-Language Abstraction User-Definable Simpler Language

Analyzable Better IDE Support

Special Treatment!

Semantics

Static Semantics

Execution Semantics

Static Semantics

Constraints Type Systems

Unique State Names

Unreachable States

Dead End States

…

Exten ded C

Example

Unique State Names

Unreachable States

Dead End States

…

Easier to do on a declarative Level!

Exten ded C

Example

Unique State Names

Unreachable States

Dead End States

…

Easier to do on a declarative Level!

Thinking of all constraints is a coverage problem! Exten

ded C

Example

Assign fixed types

What does a type system do?

Assign fixed types

Derive Types


Assign fixed types

Derive Types

Calculate Common Types


Assign fixed types

Derive Types

Calculate Common Types

Check Type Consistency


Intent + Check

Derive

More code

Better error messages

Better Performance

More convenient

More complex checkers

Harder to understand for users

Refrige rators

Example

Execution Semantics

What does it all mean?

Def: Semantics … via mapping to lower level

OB: Observable Behaviour (Test Cases)

Def: Semantics … via mapping to lower level

LD

LD-1

Transformation Interpretation

Dn

Dn+1

Transformation

Transformation

Exten ded C

Example

LD

LD-1

Transformation

Known Semantics!

Transformation

LD

LD-1

Transformation Correct!?

Transformation

Transformation

LD

LD-1

Transformation

Tests (D)

Tests (D-1)

Run tests on both levels; all pass. Coverage Problem!

LD

LD-1

Transformation

Tests Simulators

Documentation

Transformation

Multi-Stage

L3

L2

L1

L0

Modularization

Multi-Stage: Reuse

L3

L2

L1

L0

Reusing Later Stages

Optimizations!

L5

Multi-Stage: Reuse

L3

L2

L1

L0

L5

Exten ded C

Example

C Text

C (MPS tree)

State Machine

Components

Robot Control

Multi-Stage: Reuse

L3

L2

L1

L0

L5

Exten ded C

Example

C Text

C (MPS tree)

State Machine

Components

Robot Control

Syntactic Correctness, Headers

C Type System

Consistency Model Checking

Efficient Mappings

Multi-Stage: Reuse

L3

L2

L1

L0

L1b

L0b

Reusing Early Stages

Portability

Multi-Stage: Reuse

L3

L2

L1

L0

L1b

L0b Exten ded C

Example

Java C#

Multi-Stage: Preprocess

Adding an optional, modular

emergency stop feature

Reduced Expressiveness

bad? maybe.

good? maybe!

Model Checking SMT Solving

Exhaustive Search, Proof!

Language Modularity

Behavior Language Modularity, Composition and Reuse (LMR&C)

increase efficiency of DSL development



Referencing Reuse Extension Reuse

4 ways of composition:



distinguished regarding dependencies and fragment structure

4 ways of composition:

Behavior Dependencies:

do we have to know about the reuse when designing the languages?

Behavior Dependencies:

do we have to know about the reuse when designing the languages?

homogeneous vs. heterogeneous („mixing languages“)

Fragment Structure:

Behavior Dependencies & Fragment Structure:

Referencing Referencing

Referencing

Dependent

No containment

Referencing

Used in Viewpoints

Referencing

Fragment

Fragment

Fragment

Referencing

references

Refrige rators

Example

Referencing

Extension

Containment

Dependent

Extension

more specialized domains more specialized languages

Extension Extension

Dn

Dn+1

==

Extension

Dn

==

Good for bottom-up (inductive) domains, and for use by technical DSLs (people)

Extension

Behavior Drawbacks tightly bound to base potentially hard to analyze the combined program

Extension

Exten ded C

Example

Extension

Extension Extension

Exten ded C

Example

Reuse Reuse

Reuse

No containment

Independent

Reuse

Reuse

Behavior Often the referenced language is built expecting it will be reused.

Hooks may be added.

Reuse

Embedding

Embedding Embedding

Containment

Independent

Embedding

Pension Plans

Example

Embedding

Behavior Embedding often uses Extension to extend the embedded language to adapt it to its new context.

Embedding

Behavior Extension and Embedding requires modular concrete syntax

Challenges - Syntax

Many tools/formalisms cannot do that

Behavior Extension: the type system of the base language must be designed to be extensible/ overridable

Challenges – Type Systems

Behavior Reuse and Embedding: Rules that affect the interplay can reside in the adapter language.

Challenges – Type Systems

Behavior Referencing (I) Challenges – Trafo & Gen

Two separate, dependent single-source transformations

Can be Reused

Written specifically for the combination

Referencing (II) Challenges – Trafo & Gen

A single multi-sourced transformation

Referencing (III) Challenges – Trafo & Gen

A preprocessing trafo that changes the referenced frag in a way specified by the

referencing frag

Extension Challenges – Trafo & Gen

Transformation by assimiliation, i.e. generating code in the host lang

from code expr in the extension lang.

Exten ded C

Example

Extension Challenges – Trafo & Gen

Reuse (I) Challenges – Trafo & Gen

Reuse of existing transformations for both fragments plus

generation of adapter code

Reuse (II) Challenges – Trafo & Gen

composing transformations

Reuse (III) Challenges – Trafo & Gen

generating separate artifacts plus a weaving specification

Embedding (I) Challenges – Trafo & Gen

Assimilation (as with Extension)

a purely embeddable language may not come with a generator.

Embedding (II) Challenges – Trafo & Gen

Adapter language can coordinate the transformations for the host and for the

emebedded languages.

Formal Verification

3

Can language engineering increase the adoption of

formal verification?

Can we make formal verification

more usable and agile?

Our goal: formal verification

for everyone

Challenges with using formal analyses

1)  Writing the formal model

2) Specify the property to be verified

3) Interpret the analysis results

Addressing the challenges

1)  Wrap the language of the analysis tool into higher level languages

2)  Define out-of-the-box analyses goals that can be automated

3)  Lift the analysis results at the abstraction level of the domain

Challenges with Building Formal Analyses Tools

•  „ [...] model construc3on problem: the seman.c gap between the ar.facts produced by so:ware developers and those accepted by current verifica.on tools. [...]

In order to use a verifica.on tool on a real program, the developer must extract an abstract mathema3cal model of the program’s salient proper3es and specify this model in the input language of the verifica3on tool. This process is both error-‐prone and .me-‐consuming “

ICSE 2000, CorbeI et. al., Bandera ...

Addressing the challenges

Define sub-‐languages that are easier to analyze and embedd them in more

expressive languages.

Allow developers to write programs directly in a sub-‐language that is

easier to analyze.

–  Analyses are simpler to define

–  Automa3on degree grows / analyses are (computa3onally) more feasible

–  The results of analyses can be presented in more adequate form

Adequate Languages Make the Life Simpler

Today’s state of prac3ce: “Write some program (e.g. C) and then try (very hardly) to analyze it.”

The mbeddr approach: “… by using adequate language (fragments)”

Today’s state of the art: “Write programs that can be analyzed ”

183

Allow SoUware Developers Make Informed Decisions ...

Either write a sub-‐system in a restricted (but verifiable language) or use the full power of a GPL

Get immediate feedback if you are (not) in the verifiable sub-‐set

Characteris3cs of Analyzable Languages

•  High modularisa3on and encapsula3on –  Small and well-‐defined interfaces

•  Clean-‐up or restrict „problema3c“ features –  Access to global state, side-‐effects, etc.

•  Raise the level of abstrac3on –  Be able to leave out unnecessary details

•  Eliminate the „accidental complexity“ –  Be able to directly express what we want without any

„encoding“

184

Code-‐based, Model-‐based and DSLs-‐based Analyses

Formal analysis tools – e.g. model checkers, SMT solvers

GPL Code

GPL Code

Abstract models, -‐ e.g. Statecharts

Abstrac.on

Program abstrac.on

Challenges: -‐ program abstrac.on -‐  iden.fica.on of invariants -‐  figh.ng accidental complexity

Genera.on

Challenges: -‐ integrate with exis.ng systems -‐ for many tasks the models are not enough expressive

C code

DSL1 DSL2 ...

DSL3

Clean, easy to analyze DSLs m

2m transf.

code gen.

Challenges: -‐ Find adequate language fragments and corresponding analyses

mbeddr Agile Formal Analyses © Daniel Ra.u

Paradigm Change

… for analyses users:

decide which parts of programs will be analyzed and use adequate language fragments that allow analysis

... for analyses developers: it is easier to extend/restrict languages than to extend

analyses to deal with intricacies of all language features

Verifying State Machines

Referencing

Model Checking

Unreachable States Dead End States

Live States

Out of the box verification conditions

Transitions Nondeterminism

Dead Transitions

Variables out-of-bounds

Check the sanity of the code

Have a (temporal) scope: Global

Before R

After Q

Between Q and R

After Q Until R

User Defined Properties

Define Business-Domain Specific Verification Conditions

… that restrict a certain basic property:

P not P S responds to P

R R

Q Q

Q Q R R Q Q

Q Q R Q

Model Checking

Exten ded C

Example

Restricted State Machines: „float“ vars. are not allowed

Example

Verifying Decision Tables

Referencing

Exten ded C

Example

Decision Tables

Completeness: did we cover all cases?

Consistency: are there overlapping cases?

Decision Tables

Easy to answer using an SMT solver

SMT = Sa3sfiability Modulo Theories -‐ extension of boolean sa.sfiability with addi.onal theories like linear arithme.c

Decision Tables

Decision Tables

Decision Tables

Language restric3on: non-‐linear expressions are not allowed

Iden3fy language fragments relevant to developers that can be easily analyzed

Ensure equivalence with the transla3on to C or, at least, increase the confidence

that they are „close enough“ for a certain analysis goal

New Challenges

The End. Most of this material is part of

Markus‘ upcoming (early 2013) book DSL Engineering. Stay in touch, it may become a free

eBook www.voelter.de

voelterblog.blogspot.de @markusvoelter +Markus Voelter

language workbenches, embedded software formal verification · a dsl is a focussed, processable...

Documents