Language Workbenches, Embedded Software and Formal Verification

Transcription

1 Language Workbenches, Embedded Software and Formal Verification Markus Voelter independent/itemis +Markus Voelter Daniel Ratiu ForTISS GmbH

2

3 mbeddr 1

4

5 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

6 An extensible C with support for formal methods, requirements and PLE.

7 IDE for Everything

8 A debugger for all of that

9 SDK for building your own Language Extensions!

10 IDE for Everything JetBrains MPS Open Source Language Workbench

11

12 Challenges in embedded software development

13 Abstraction without Runtime Cost

14 C considered unsafe

15 Program Annotations

16 Static Checks and Verification

17 Product Lines and Requirement Traces

18 Separate, hard to integrate Tools

19

20 Subset of Available Extensions

21 All of C (cleaned-up)

22

23 Retargettable Build Integration

24

25 Native Support for Unit Testing and Logging

26

27

28 Physical Units

29

30 Components Interfaces Contracts Instances Mocks & Stubs

31

32

33

34 State Machines + Model Checking

35

36

37 Decision Tables + Consistency and Completeness Checks

38

39 Support for Frama-C + High-level Iterators

40 IDE Support for Frama- C Annota3ons

41 Generate Frama- C Annota3ons from Higher- level Constructs

42 Requirements Tracability

43

44

45

46 Product Line Variability

47

48

49

50

51

52 Status and Availability

53

54 Developed within LWES Language Workbenches for Embedded Systems gefördert durch das BMBF Förderkennzeichen 01 S11014

55 Most is Open Source (EPL); the rest will follow this year.

56 support for graphical early 2013

57 integration in early 2013

58

59 2 Language Engineering w/ Language Workbenches

60

61 Introduction

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

63 Concepts (abstract syntax) (concrete) Syntax semantics (generators) Tools and IDE

64 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 In-language abstraction large, anonymous and widespread sophisticated small, accessible and local limited Lifespan years to decades months to years (driven by context) Evolution slow, often standardized fast-paced Incompatible Changes almost impossible feasible

65 General Purpose C Components State Machines Domain Specific Sensor Access LEGO Robot Control

66 Big Language o a b n c m k L d e j f i h g with many first class concepts!

67 Small Language α δ L β ω λ with a few, orthogonal and poweful concepts

68 Modular Language α my L a b c d e f g h i j k l β with many optional, composable modules

69

70 Model an abstraction or simplification of reality ecosurvey.gmu.edu/glossary.htm

71 Model which ones? an abstraction or simplification of reality what should we leave out? ecosurvey.gmu.edu/glossary.htm

72 Model Purpose code generation analysis and checking platform independence stakeholder integration drives design of language!

73 Programs Languages Domains

74 deductive top down body of knowledge in the real world Domain existing software (family) inductive bottom up

75 Domain Domain existing software (family) inductive bottom up

76 Domain Hierarchy

77 Domain Hierarchy automotive avionics embedded software all programs Example Exten ded C

78 Heterogeneous Example Exten ded C

79 Heterogeneous C Statemachines Testing Example Exten ded C

80

81 Domain Hierarchy more specialized domains more specialized languages

82 Reification D n

83 Reification D n+1 == D n

84 Reification Transformation/ Generation == Language Definition

85 ?

86 ? Overspecification! Requires Semantic Analysis!

87 ! Declarative! Directly represents Semantics. Linguistic Abstraction

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

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

90 Another Example Example Exten ded C

91 Another Example Turing Complete! Requires Semantic Analysis! Example Exten ded C

92 Linguistic Abstraction Example Exten ded C

93 Linguistic Abstraction Example Exten ded C

94 Linguistic Abstraction In-Language Abstraction Libraries Classes Frameworks

95 Linguistic Abstraction Analyzable Better IDE Support In-Language Abstraction User-Definable Simpler Language

96 Linguistic Abstraction Analyzable Better IDE Support Special Treatment! In-Language Abstraction User-Definable Simpler Language

97

98 Semantics

99 Static Semantics Execution Semantics

100 Static Semantics Execution Semantics

101 Static Semantics Constraints Type Systems

102 Unique State Names Unreachable States Dead End States Example Exten ded C

103 Unique State Names Unreachable States Dead End States Easier to do on a declarative Level! Example Exten ded C

104 Unique State Names Unreachable States Dead End States Easier to do on a declarative Level! Thinking of all constraints is a coverage problem! Example Exten ded C

105 Assign fixed types What does a type system do?

106 Derive Types Assign fixed types What does a type system do?

107 Derive Types Assign fixed types Calculate Common Types What does a type system do?

108 Assign fixed types Derive Types Calculate Common Types Check Type Consistency What does a type system do?

109 Intent + Derive Check More code Better error messages Better Performance More convenient More complex checkers Harder to understand for users

110 Example Refrige rators

111

112 What does it all mean? Execution Semantics

113 Def: Semantics via mapping to lower level OB: Observable Behaviour (Test Cases)

114 Def: Semantics via mapping to lower level L D Transformation Interpretation L D-1

115 Transformation D n+1 D n

116 Transformation Example Exten ded C

117 Transformation L D Transformation L D-1 Known Semantics!

118 Transformation L D Correct!? Transformation L D-1

119 Transformation Tests (D) L D Transformation Tests (D-1) L D-1 Run tests on both levels; all pass. Coverage Problem!

120 Transformation Tests Simulators Documentation L D Transformation L D-1

121 Multi-Stage L 3 L 2 Modularization L 1 L 0

122 Multi-Stage: Reuse L 3 L 2 L 5 L 1 Reusing Later Stages L 0 Optimizations!

123 Multi-Stage: Reuse L 3 L 2 L 5 Robot Control State Machine Components L 1 C (MPS tree) L 0 C Text Example Exten ded C

124 Multi-Stage: Reuse L 3 L 2 L 5 Robot Control State Machine Consistency Model Checking Components Efficient Mappings L 0 L 1 C Type System C (MPS tree) Syntactic Correctness, Headers C Text Example Exten ded C

125 Multi-Stage: Reuse L 3 Reusing Early Stages L 2 Portability L 1 L 1b L 0 L 0b

126 Multi-Stage: Reuse L 3 L 2 L 1 L 1b Java C# Example L 0 L 0b Exten ded C

127 Multi-Stage: Preprocess Adding an optional, modular emergency stop feature

128 Reduced Expressiveness bad? maybe. good? maybe! Model Checking SMT Solving Exhaustive Search, Proof!

129

130 Language Modularity

131 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development

132 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development 4 ways of composition: Referencing Reuse Extension Reuse

133 Language Modularity, Behavior Composition and Reuse (LMR&C) increase efficiency of DSL development 4 ways of composition: distinguished regarding dependencies and fragment structure

134 Dependencies: Behavior do we have to know about the reuse when designing the languages?

135 Dependencies: Behavior do we have to know about the reuse when designing the languages? Fragment Structure: homogeneous vs. heterogeneous ( mixing languages )

136 Behavior Dependencies & Fragment Structure:

137 Behavior Dependencies & Fragment Structure:

138 Referencing

139 Referencing Dependent No containment

140 Referencing Used in Viewpoints

141 Referencing Fragment Fragment references Fragment

142 Referencing Example Refrige rators

143 Extension

144 Extension Dependent Containment

145 Extension more specialized domains more specialized languages

146 Extension D n+1 == D n

147 Extension D n+1 == D n

148 Extension Good for bottom-up (inductive) domains, and for use by technical DSLs (people) D n ==

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

150 Extension Example Exten ded C

151 Extension Example Exten ded C

152 Reuse

153 Reuse Independent No containment

154 Reuse Behavior Often the referenced language is built expecting it will be reused. Hooks may be added.

155 Embedding

156 Embedding

157 Embedding Independent Containment

158 Embedding Example Pension Plans

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

160 Challenges - Syntax Behavior Extension and Embedding requires modular concrete syntax Many tools/formalisms cannot do that

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

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

163 Challenges Trafo & Gen Referencing (I) Behavior Written specifically for the combination Can be Reused Two separate, dependent single-source transformations

164 Challenges Trafo & Gen Referencing (II) A single multi-sourced transformation

165 Challenges Trafo & Gen Referencing (III) A preprocessing trafo that changes the referenced frag in a way specified by the referencing frag

166 Challenges Trafo & Gen Extension Transformation by assimiliation, i.e. generating code in the host lang from code expr in the extension lang.

167 Challenges Trafo & Gen Extension Example Exten ded C

168 Challenges Trafo & Gen Reuse (I) Reuse of existing transformations for both fragments plus generation of adapter code

169 Challenges Trafo & Gen Reuse (II) composing transformations

170 Challenges Trafo & Gen Reuse (III) generating separate artifacts plus a weaving specification

171 Challenges Trafo & Gen Embedding (I) a purely embeddable language may not come with a generator. Assimilation (as with Extension)

172 Challenges Trafo & Gen Embedding (II) Adapter language can coordinate the transformations for the host and for the emebedded languages.

173

174 3 Formal Verification

175 Can language engineering increase the adoption of formal verification?

176 Can we make formal verification more usable and agile?

177 Our goal: formal verification for everyone

178 Challenges with using formal analyses 1) Writing the formal model 2) Specify the property to be verified 3) Interpret the analysis results

179 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

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

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

182 Adequate Languages Make the Life Simpler Analyses are simpler to define Automa3on degree grows / analyses are (computa3onally) more feasible The results of analyses can be presented in more adequate form Today s state of prac3ce: Write some program (e.g. C) and then try (very hardly) to analyze it. Today s state of the art: Write programs that can be analyzed The mbeddr approach: by using adequate language (fragments)

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 183

184 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

185 Code- based, Model- based and DSLs- based Analyses Formal analysis tools e.g. model checkers, SMT solvers Program abstrac.on Abstrac.on GPL Code Abstract models, - e.g. Statecharts Genera.on GPL Code DSL1 DSL2 C code Clean, easy to analyze DSLs DSL3... m2m transf. code gen. Challenges: - program abstrac.on - iden.fica.on of invariants - figh.ng accidental complexity Agile Formal Analyses Daniel Ra.u Challenges: - integrate with exis.ng systems - for many tasks the models are not enough expressive Challenges: - Find adequate language fragments and corresponding analyses mbeddr

186 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

187

188 Referencing Verifying State Machines

189 Model Checking

190 Model Checking

191 Out of the box verification conditions Unreachable States Dead End States Live States Transitions Nondeterminism Dead Transitions Variables out-of-bounds Check the sanity of the code

192 Have a (temporal) scope: Global User Defined Properties Before R R R After Q Q Q Between Q and R After Q Until R Q Q Q Q R R Q Q R Q that restrict a certain basic property: P not P S responds to P Define Business-Domain Specific Verification Conditions

193 Model Checking

194 Model Checking

195 Model Checking

196 Example Exten ded C

197 Example Restricted State Machines: float vars. are not allowed

198

199 Referencing Verifying Decision Tables

200 Decision Tables Example Exten ded C

201 Decision Tables Completeness: did we cover all cases? Consistency: are there overlapping cases?

202 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

203 Decision Tables

204 Decision Tables Language restric3on: non- linear expressions are not allowed

205

206 New Challenges 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

207

208 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 +Markus Voelter