Formal Methods ebook free download e
Formal Methods
Formal Methods Industrial Use from Model to the Code
Edited by Jean-Louis Boulanger First published 2012 in Great Britain and the United States by ISTE Ltd and John Wiley & Sons, Inc.
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as
permitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced,
stored or transmitted, in any form or by any means, with the prior permission in writing of the publishers,
or in the case of reprographic reproduction in accordance with the terms and licenses issued by the
CLA. Enquiries concerning reproduction outside these terms should be sent to the publishers at the
undermentioned address:ISTE Ltd John Wiley & Sons, Inc. 27-37 St George’s Road 111 River Street London SW19 4EU Hoboken, NJ 07030
UK USA
www.iste.co.uk www.wiley.com © ISTE Ltd 2012
The rights of Jean-Louis Boulanger to be identified as the author of this work have been asserted by him
in accordance with the Copyright, Designs and Patents Act 1988.____________________________________________________________________________________
Library of Congress Cataloging-in-Publication Data
Formal methods : industrial use from model to the code / edited by Jean-Louis Boulanger. p. cm. -- (Industrial implementation of formal methods series) Includes bibliographical references and index.ISBN 978-1-84821-362-3
1. Railroads--Management--Data processing. 2. Formal methods (Computer science) 3. Application software--Development. I. Boulanger, Jean-Louis.
TF507.F66 2012 385.0285'53--dc23 2012011496 British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library
ISBN: 978-1-84821-362-3 Printed and bound in Great Britain by CPI Group (UK) Ltd., Croydon, Surrey CR0 4YY
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi
OULANGER
Jean-Louis B Chapter 1. From Classic Languages to Formal Methods . . . . . . . . . . .
1 OULANGER Jean-Louis B 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1.2. Classic development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 1.2.1. Development process . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 1.2.2. Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 1.2.3. Specification and architecture . . . . . . . . . . . . . . . . . . . . .
18 1.2.4. Verification and validation (V&V) . . . . . . . . . . . . . . . . . . .
27 1.2.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33 1.3. Structured, semi-formal and/or formal methods . . . . . . . . . . . . .
33 1.3.1. E/E/PE system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33 1.3.2. Rail sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35 1.3.3. Taking into account techniques and formal methods . . . . . . . .
36 1.4. Formal methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 1.4.1. Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 1.4.2. Examples of formal methods . . . . . . . . . . . . . . . . . . . . . . .
39 1.5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 1.6. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49 Chapter 2. Formal Method in the Railway Sector the First Complex Application: SAET-METEOR . . . . . . . . . . . . . . .
55 OULANGER Jean-Louis B 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55 2.2. About SAET-METEOR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56 2.2.1. Decomposition of the SAET-METEOR . . . . . . . . . . . . . . . .
57 vi Formal Methods 2.2.2. Anticollision functions . . . . . . . . . . . . . . . . . . . . . . . . . .
61 2.2.3. Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62 2.3. The supplier realization process . . . . . . . . . . . . . . . . . . . . . . .
62 2.3.1. Historical context . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62 2.3.2. The hardware aspect . . . . . . . . . . . . . . . . . . . . . . . . . . .
64 2.3.3. The software aspect . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67 2.3.4. Assessment of the processes . . . . . . . . . . . . . . . . . . . . . . .
78 2.4. Process of verification and validation set up by RATP . . . . . . . . . .
78 2.4.1. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78 2.4.2. RATP methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79 2.4.3. Verification carried out by RATP . . . . . . . . . . . . . . . . . . .
79
2.4.4. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.4.5. Assessment of RATP activity . . . . . . . . . . . . . . . . . . . . . . 112
2.5. Assessment of the global approach . . . . . . . . . . . . . . . . . . . . . 114
2.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
2.7. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.7.1. Object of the track . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.7.2. Block logic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Chapter 3. The B Method and B Tools . . . . . . . . . . . . . . . . . . . . . . . 127 OULANGER Jean-Louis B
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.2. The B method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
3.2.1. The concept of abstract machines . . . . . . . . . . . . . . . . . . . 128
3.2.2. Machines with implementations . . . . . . . . . . . . . . . . . . . . 133
3.3. Verification and validation (V&V) . . . . . . . . . . . . . . . . . . . . . 137
3.3.1. Internal verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.4. B tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.4.1. General principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.4.2. Code generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.4.3. Prover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.4.4. Atelier B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.5. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.5.1. Layered development . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.5.2. Link between the project structure and the POs . . . . . . . . . . . 148
3.5.3. Cycle of development of a B project . . . . . . . . . . . . . . . . . . 148
3.6. Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.6.1. Some figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.6.2. Some users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Table of Contents vii
Chapter 4. Model-Based Design Using Simulink – Modeling, Code Generation, Verification, and Validation . . . . . . . . . . . . . . . . . 159 ONRAD OSTERMAN Mirko C and Pieter J. M
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.2. Embedded software development using Model-Based Design . . . . . 162
4.3. Case study – an electronic throttle control system . . . . . . . . . . . . 164
4.3.1. System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
®
4.3.2. Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.3.3. Automatic code generation . . . . . . . . . . . . . . . . . . . . . . . . 169
4.3.4. Code optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.3.5. Fixed-point code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.3.6. Including legacy code . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.3.7. Importing interface definitions . . . . . . . . . . . . . . . . . . . . . 172
4.3.8. Importing algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.4. Verification and validation of models and generated code . . . . . . . 173
4.4.1. Integrating verification and validation with Model-Based Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.4.2. Design verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.4.3. Reviews and static analyses at the model level . . . . . . . . . . . . 175
4.4.4. Module and integration testing at the model level . . . . . . . . . . 175
4.4.5. Code verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.4.6. Back-to-back comparison testing between model and code . . . . 176
4.4.7. Measures to prevent unintended functionality . . . . . . . . . . . . 176
4.5. Compliance with safety standards . . . . . . . . . . . . . . . . . . . . . . 177
4.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Chapter 5. Proving Global Properties with the Aid
of the SIMULINK DESIGN VERIFIER Proof Tool . . . . . . . . . . . . . . 183
ELEBARRE TIENNE
Véronique D and Jean-Frédéric E
5.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.2. Formal proof or verification method . . . . . . . . . . . . . . . . . . . . 184
5.2.1. Model verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.2.2. Formal methods and proof of correction . . . . . . . . . . . . . . . 189
5.2.3. Combining models and proof tools . . . . . . . . . . . . . . . . . . . 192
5.3. Implementation of the SIMULINK DESIGN VERIFIER tool. . . . . . 193
5.3.1. Reminders of the MATLAB modeling and verification environment . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.3.2. Case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.3.3. Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
5.3.4. Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.4. Experience feedback and methodological aspects . . . . . . . . . . . . . 211 viii Formal Methods
5.4.1. Modeling rules and convergence control . . . . . . . . . . . . . . . . 211
5.4.2. Modular proof phase . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5.4.3. Proof of global properties . . . . . . . . . . . . . . . . . . . . . . . . 214
5.4.4. Detection of counterexamples . . . . . . . . . . . . . . . . . . . . . . 217
5.5. Study case feedback and conclusions . . . . . . . . . . . . . . . . . . . . 218
5.5.1. SIMULINK model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.5.2. Proofs achieved . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
5.5.3. Incremental verification approach . . . . . . . . . . . . . . . . . . . . 220
5.6. Contributions of the methodology compared with the EN50128 normative referential . . . . . . . . . . . . . . . . . . . . . 220
5.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Chapter 6. SCADE: Implementation and Applications . . . . . . . . . . . . 225 AMUS Jean-Louis C
6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
6.2. Issues of embedded safety-critical software . . . . . . . . . . . . . . . . 225
6.2.1. Characteristics of embedded safety-critical software . . . . . . . . 225
6.2.2. Architecture of an embedded safety-critical application . . . . . . 226
6.2.3. Criticality and normative requirements for embedded safety-critical applications . . . . . . . . . . . . . . . . . . . 226
6.2.4. Complexity, cost and delays . . . . . . . . . . . . . . . . . . . . . . . 227
6.3. Origins of SCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.3.2. Initial industrial approaches . . . . . . . . . . . . . . . . . . . . . . . 228 6.3.3. “Real-time” extensions of current languages . . . . . . . . . . . . . 230
6.3.4. Synchronous formal languages dedicated to “real-time” created in laboratories . . . . . . . . . . . . . . . . . . . . . . 230
6.3.5. Birth of SCADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.4. The SCADE data-flow language . . . . . . . . . . . . . . . . . . . . . . 231
6.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.4.2. Synchronous language . . . . . . . . . . . . . . . . . . . . . . . . . . 232 6.4.3. “Data-flow” functional language . . . . . . . . . . . . . . . . . . . . 233
6.4.4. Scalar data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
6.4.5. Structured data types . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
6.4.6. Clocks, temporal operators, and causality . . . . . . . . . . . . . . . 235
6.4.7. Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.4.8. Imperative structures . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.4.9. Rigor and functional safety . . . . . . . . . . . . . . . . . . . . . . . . 239
6.5. Conclusion: extensions of languages for controllers and iterative processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.5.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.5.2. Control flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.5.3. Iterative processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Table of Contents ix
6.6. The SCADE system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.6.1. Outline of the SCADE workbench . . . . . . . . . . . . . . . . . . . 246
6.6.2. Model verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
6.6.3. Performance prediction . . . . . . . . . . . . . . . . . . . . . . . . . . 252
6.6.4. The qualified code generator . . . . . . . . . . . . . . . . . . . . . . 253
6.7. Application of SCADE in the aeronautical industry . . . . . . . . . . . 256
6.7.1. History: Aérospatiale and Thales Avionique . . . . . . . . . . . . . 256
6.7.2. Control/command type applications . . . . . . . . . . . . . . . . . . 257
6.7.3. Monitoring/alarm type applications . . . . . . . . . . . . . . . . . . 260
6.7.4. Navigation systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.8 Application of SCADE in the rail industry . . . . . . . . . . . . . . . . . 261
6.8.1. First applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
6.8.2. Applications developed for the RATP and other French metros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
6.8.3. Generic PAI-NG applications . . . . . . . . . . . . . . . . . . . . . . 263
6.8.4. Example of automated door control . . . . . . . . . . . . . . . . . . 264
6.9. Application of SCADE in the nuclear and other industries . . . . . . . 265
6.9.1. Applications in the nuclear industry . . . . . . . . . . . . . . . . . . 265
6.9.2. Deployment of SCADE in the civil nuclear industry . . . . . . . . 268
6.10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
6.11. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Chapter 7. GATeL: A V&V Platform for SCADE Models . . . . . . . . . . 273
ARRE IANC OUY UNKE Bruno M , Benjamin B , Patricia M and Christophe J7.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.2. SCADE language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
7.3. GATeL prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
7.3.1. GATeL kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
7.3.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
7.4. Assistance in the design of test selection strategies . . . . . . . . . . . . 279
7.4.1. Unfolding of SCADE operators . . . . . . . . . . . . . . . . . . . . . 279
7.4.2. Functional scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
7.5. Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
7.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Chapter 8. ControlBuild, a Development Framework
for Control Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
ORBIER
Franck C
8.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
8.2. Development of the control system . . . . . . . . . . . . . . . . . . . . . 289
8.2.1. ERTMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
8.2.2. Development process equipment . . . . . . . . . . . . . . . . . . . . 291 x Formal Methods
8.2.3. A component-based approach . . . . . . . . . . . . . . . . . . . . . . 293
8.2.4. Development methodology . . . . . . . . . . . . . . . . . . . . . . . 294
8.3. Formalisms used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
8.3.1. Assembly editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
8.3.2. IEC1131-3 languages for embedded control . . . . . . . . . . . . . 302
8.3.3. Electrical schematics for conventional control . . . . . . . . . . . . 309
8.3.4. Electromechanical and physical environment . . . . . . . . . . . . . 311
8.4. Safety arrangements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
8.4.1. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
8.4.2. Assertions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
8.4.3. Automatic test procedure execution . . . . . . . . . . . . . . . . . . 314
8.4.4. Functional tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.4.5. Code coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.4.6. SSIL2 code generation . . . . . . . . . . . . . . . . . . . . . . . . . . 315
8.4.7. Management of the project documentation . . . . . . . . . . . . . . 316
8.4.8. Traceability of requirements . . . . . . . . . . . . . . . . . . . . . . . 317
8.5. Examples of railway use cases . . . . . . . . . . . . . . . . . . . . . . . . 318
8.5.1. Specification validation . . . . . . . . . . . . . . . . . . . . . . . . . 318
8.5.2. TCMS development . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
8.5.3. Progressive integration bench – HiL . . . . . . . . . . . . . . . . . . 320
8.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
8.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Chapter 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 OULANGER Jean-Louis B
9.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
9.2. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
9.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
9.3.1. Model verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
9.3.2. Properties and requirements . . . . . . . . . . . . . . . . . . . . . . . 328
9.3.3. Implementation of formal methods . . . . . . . . . . . . . . . . . . . 330
9.4. Implementing formal methods . . . . . . . . . . . . . . . . . . . . . . . . 332
9.4.1. Conventional process . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
9.4.2. Process accounting for formal methods . . . . . . . . . . . . . . . . 333
9.4.3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
9.5. Realization of a software application . . . . . . . . . . . . . . . . . . . . 337
9.6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
9.7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
List of Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Introduction
ContextAlthough formal analysis programming techniques (see works by Hoare [HOA 69] and Dijkstra [DIJ 75]) are relatively old, the introduction of formal methods only dates from the 1980s. These techniques enable us to analyze the behavior of a software application, described in a programming language. Program correction (good behavior, program stop, etc.) is thus demonstrated through a program proof based on the weakest precondition calculation [DIJ 76].
It took until the end of the 1990s before formal methods (Z [SPI 89], VDM [JON 90] or the B-method [ABR 96, ARA 97]) could be used in industrial applications and settings.
One of the stumbling blocks was implementing them in the framework of an industrial application (large application, cost constraints or delays, etc.). This implementation is only possible using “sufficiently” mature and high-performance tools.
Where safety requirements are critical, at least two formal methods are used: the B-method [ABR 96] and the LUSTRE language [HAL 91, ARA 97] and its graphic version, named SCADE [DOR 08]. These cover one part of the specification production process according to the code and integrate one or more verification processes.
The B-method and the SCADE environment are associated with industrial tools. OULANGER Introduction written by Jean-Louis B . xii Formal Methods 1 2 For example, Atelier B and the B-Toolkit, marketed by CLEARSY and B-Core
respectively, are tools that completely cover the development cycle proposed by the B-method comprising specification, refinement, code, and proof generation. It 3 should be noted that Atelier B can be accessed for free from version 4.0 onward.
Formal methods rely on different formal verification techniques such as proofs, model checking [BAI 08] and/or simulation. The use of formal methods while in full development remains marginal, given the number of lines of code. In effect, there are currently many more Ada [ANS 83],
C [ISO 99] or C++ lines of code, which have been produced manually rather than through a formal process.
That is why other formal techniques have been implemented to verify the behavior of a software application written in a programming language such as C or Ada. The technical principle known as abstract interpretation [COU 00] of programs makes it possible to evaluate all the behaviors of a software application through a static analysis. This type of technique has, in these last few years, given 4 5 6 7 rise to several tools such as POLYSPACE , Caveat , Absint , Frama-C , and/or 8 ASTREE .
The efficacy of these static program analysis techniques has progressed greatly with the increase in power of business machines. It should be noted that these techniques generally necessitate the integration of complementary information such as pre-conditions, invariants, and/or post-conditions in the manual code. 9 SPARK Ada [BAR 03] is one approach where the Ada language [ANS 83] has been expanded to introduce these complementary elements (pre-, post-, invariant), and an adapted suite of tools has been defined.
Objective of this book
In [BOW 95, ARA 97], the first industrial feedback involving formal techniques can be found, and notably, a report on the B-method [ABR 96], the LUSTRE
1 To find out more about the CLEARSY company and Atelier B, visit www.clearsy.com.
2 The B-Toolkit was distributed by B-Core (UK) Ltd.
3 Atelier B and associated information can be obtained from www.atelierb.eu/.
4 For more information on Polyspace, visit www.mathworks.com/polyspace.
5 To find out more about Caveat, visit www-list.cea.fr/labos/fr/LSL/caveat/index.html.
6 To find out more about Absint, visit www.absint.com.
7 To find out more, visit http://frama-c.com/.
8 To find out more about ASTREE, visit www.astree.ens.fr.
9 The site www.altran-praxis.com/spark.aspx offers further information about SPARK Ada
technology.Introduction xiii 10 language [HAL 91, ARA 97] and SAO+, the predecessor to SCADE [DOR 08].
Other works such as [MON 00, MON 02, HAD 06] provide a panorama of formal methods with a more scientific point of view.
Given the presentation of the context and of the state of the literature, our objective is to present concrete examples of industrial use of formal techniques. By formal techniques, we mean the different mathematical approaches, which make it possible to demonstrate that a software application obeys some properties. While the standard use of formal techniques consists of making specification and/or design models, they are seen by a verification subject to static analysis of code, demonstration of abiding by properties, good management of floating-point calculations, etc.
This work is related to two other books by the same authors published by ISTE and John Wiley & Sons in 2012 [BOU 12a] and [BOU 12b]. The current book is dedicated to the presentation of different formals methods, such as the B-method (Chapters 2 and 3), SCADE (Chapters 6 and 7), 11 MATHLAB/SIMULINK (Chapters 4 and 5) and ControlBuild (Chapter 8). [BOU 12a] involves industrial examples of implementation of formal techniques based on static analysis such as abstract interpretation; examples of the use of
ASTREE (Chapters 2 and 3), CAVEAT (Chapter 3), CODEPEER (Chapter 6), Frama-C (Chapters 3 and 7), and POLYSPACE (Chapters 4 and 5) tools.
[BOU 12b] is dedicated to the presentation of different formal techniques, such 12 as the SPARK Ada (Chapter 1), MaTeLo (Chapter 2), AltaRica (Chapter 3), Polyspace (Chapter 4), Escher verification Studio Perfect Developer (Chapter 5) and the B method (Chapters 6 and 7).
In conclusion to this introduction, I have to thank all the manufacturers who have taken the time to redraft and improve upon these chapters.
10 It should be noted that SCADE was initially a development environment basing itself on
the LUSTRE language and that since version 6, SCADE has become an entirely separate
language (the code generator for version 6 takes most of its input from a SCADE model, and
not a LUSTRE code).11 To find out more about the ControlBuild tool, visit www.geensoft.com/en/article/controlbuild.
12 To find out more about MaTeLo, visit www.all4tec.net/index.php/All4tec/matelo-product. html. xiv Formal Methods Bibliography [ABR 96] A BRIAL J.R., The B-Book - Assigning Programs to Meanings, Cambridge University Press, Cambridge, August 1996. [ANS 83] A NSI , Norme ANSI/MIL-STD-1815A-1983, Langage de programmation Ada, 1983. [ARA 97] A RAGO , “Applications des méthodes formelles au logiciel”, Observatoire français des techniques avancées (OFTA), vol. 20, Masson, Paris, June 1997. [BAI 08] B AIER
C., K ATOEN J.-P., Principles of Model Checking, The MIT Press, Cambridge, MA, 2008.
[BAR 03] B ARNES J., High Integrity Software: The SPARK Approach to Safety and Security, Addison Wesley, Boston, 2003. [BOU 12a] B OULANGER J.-L. (ed.), Static Analysis of Software – The Abstract Interpretation, ISTE Ltd, London and John Wiley and Sons, New York, 2012. [BOU 12b] B OULANGER J.-L. (ed.), Industrial Use of Formal Methods, ISTE Ltd, London, John Wiley and Sons, New York, 2012. [BOW 95] B OWEN J.P., H INCHEY H.G., Applications of Formal Methods, Prentice Hall, Upper Saddle River, 1995. [COU 00] C OUSOT P., “Interprétation abstraite”. Technique et science informatiques, vol. 19, no. 1-3, p. 155-164, Hermès, Paris, 2000. [DIJ 75] D IJKSTRA E.W., “Guarded commands, non-determinacy and formal derivation of programs”, Communications of the ACM, vol.18, no. 8, p.453-457, August 1975. [DIJ 76] D IJKSTRA E.W., A Discipline of Programming, Prentice Hall, Upper Saddle River, 1976. [DOR 08] D ORMOY F.-X., “Scade 6 a model based solution for safety critical software development”, Embedded Real-Time Systems Conference, 2008. [HAD 06] H ADDAD S., K ORDON
F., P ETRUCCI L. (ed.), Méthodes formelles pour les systèmes répartis et coopératifs, Hermès, Paris, 2006.
[HAL 91] H ALBWACHS N., C ASPI P., R AYMOND P., P ILAUD
D., “The synchronous dataflow
programming language lustre”, Proceedings of the IEEE, vol. 79, no. 9, p. 1305-1320,
September 1991. [HOA 69] H OARE C.A.R, “An axiomatic basis for computer programming”, Communications of the ACM, vol. 12, no. 10, p. 576-580-583, 1969.[ISO 99] ISO/IEC 9899:1999, Programming languages – C, 1999.
Introduction xv
[JON 90] J ONES C.B., Systematic Software Development using VDM, Prentice Hall
International, Upper Saddle River, 1990. [MON 00] M ONIN J.-F., Introduction aux méthodes formelles, préface by H UETG., Hermès, Paris, 2000.
[MON 02] M ONIN J.-F., Understanding Formal Methods, preface by H UET , G., T RAD . M.,
Hinchey, Springer Verlag, New York, 2002.[SPI 89] S PIVEY J.-M., The Z notation – a reference Manual, Prentice Hall International, Upper
Saddle River, 1989.Chapter 1 From Classic Languages
to Formal Methods
1.1. Introduction
The introduction to this book has provided the opportunity to set formal analysis techniques in a general context. In this chapter, we are going to focus on formal methods and their implementation.
The classic development process of a software application is based on the use of a programming language (for example, Ada [ANS 83], C [ISO 99] and/or C++ [ISO 03]). These languages have a certain abstraction level in comparison to the code finally executed on the computer, a program is a set of line of code write manually.
The size of applications has gone from several thousands of lines to several hundreds of thousands of lines of code (possibly several millions for new applications). Considering the number of faults introduced by developers, it is then important to use techniques to limit the number of faults introduced and to more easily identify potential faults.
As we will show later, formal methods enable us to fulfill this double objective.
1.2. Classic development
The objective of this section is to analyze the weaknesses of the classic (meaning non-formal) process, which is implemented to make a software application.
OULANGER Chapter written by Jean-Louis B . Formal Methods: Industrial Use from Model to the Code © 2012 ISTE Ltd. Published 2012 by ISTE Ltd. Edited by Jean-Louis Boulanger
2 Formal Methods
1.2.1. Development process
1.2.1.1. Presentation The creation of a software application is broken down into stages (specification, design, coding, tests, etc.). We refer to the lifecycle. The lifecycle is necessary to describe the dependencies and sequencing between activities. Specification Architecture Integration Functional tests Needs analysis Preliminary design Specification Preliminary detailed design and Module tests tests Determination alternative and constraints of objectives, analysis Risk Prototyping
Detailed design
Module tests Coding Coding (a) next phase Planning of the Functional tests Start classic Phase of the V-cycle Simulation Integration tests Operation/maintenance (c) (b)Figure 1.1. Three possible lifecyclesThe lifecycle must take into account the progressive refinement aspect of the development as well as possible iterations. In this section, we present the lifecycle, which is used to make a software application.
As Figure 1.1 shows, there are several cycles: a) V-cycle, b) waterfall cycle,
c) spiral cycle, etc. for making a software application, but the cycle recommended by different standards (CENELEC EN 50128 [CEN 01], DO 178 [ARI 92],
IEC 61508 [IEC 98], ISO 26262 [ISO 09]) remains the V-cycle.
Figure 1.2 presents the V-cycle as it is generally presented. The objective of needs analysis is to verify adequacy to the expectations of the client andtechnological feasibility. The objective of the specification phase is to describe what
From Classic Languages to Formal Methods 3
the software must do (and not how it will do it). In the context of architecture definition, the aim is create a hierarchical breakdown of the software application into modules/components and to identify interfaces between these elements.
Needs Operation analysis maintenance Functional
Specification tests Integration Architecture tests Preliminary and
Module detailed tests design
Coding
Figure 1.2. V-cycleDescription of each module/component (data, algorithms, etc.) is achieved within the framework of the design. The design phase is often separated into two stages. The first stage, named preliminary design, aims to identify manipulated data and necessary services; the second stage, named detailed design, aims to describe all services through their algorithms. The design phase then gives rise to the coding phase.
Figure 1.2 shows that there are different test phases: module tests (focused on the lowest-level components), integration tests (focused on software and/or hardwareinterfaces), and functional tests (sometimes known as validation tests), which show that a product conforms to its specification. As for the operation/maintenance phase, it involves operational life and control of potential evolutions.
4 Formal Methods
There is a horizontal correspondence (dotted arrow) between activity specification and design and activity testing. The V-cycle is thus broken down into two phases: bottom-up phase and top-down phase. Top-down phase activity (execution of the MT/IT and FT) must be processed during the bottom-up phase. Figure 1.3 is thus closer to the V-cycle recommended.
Operation Needs analysis maintenance FT
FT Specification Specification execution
IT
IT Architecture Specification execution
Preliminary and MT MT detailed execution
Specification design Coding
Figure 1.3. V-cycle including test specifications1.2.1.2. Advantages/disadvantages The V-cycle of Figure 1.3 reveals that faults introduced in the making of the software application will be detected during the top-down phase, which has a direct impact on the cost and delays of making the software.
Experience in safety-critical applications shows that activity testing accounts for 50% to 75% of the cost of production and that the presence of faults can multiply delays in production two or three times over.
Increased delays are caused by the discovery of anomalies, their identification, analysis of their effects (impact on the safety and/or reliability of the software application), selection of anomalies to correct, analysis of anomalies, implementation
From Classic Languages to Formal Methods 5
of corrections and verification of corrections (in general, verifying correct implementation of modifications is achieved through test runs, but it will be necessary to verify that no additional modification has been implemented).
Analysis of anomalies is achieved through an impact analysis (definition 1.1) and a non-regression analysis (definition 1.2). In certain cases, non-regression is said to be total, and for this, it is necessary to re-execute the series of tests on one phase or all phases.
The objective of non-regression analysis is to minimize the cost of a new version.
EFINITION MPACT NALYSIS
D 1.1.– I A . Impact analysis of an anomaly consists of identifying modifications to make in the bottom-up phase (impact on the documents, impact on the code, impact on the description and test implementations) of production.
D 1.2.– N A . Non-regression analysis consists of determining a series of tests, which make it possible to demonstrate that the
- EFINITION ON REGRESSION NALYSIS
1 modification made has not had an effect on the rest of the software application .
In addition, it should be noted that the cost of correcting a fault is directly linked to the phase during which it is identified. In effect, detecting a fault during the functional testing phase is 10 to 100 times more expensive (not to mention higher in certain cases) than a fault identified in the module testing phase. This cost is linked to resources that have been used right up to discovery of the fault and to the difficulty of carrying out functional testing (usage of targeting equipment, necessity of taking real time into account, difficulty of observation, technical expertise of people involved, etc.).
2 Our experience feedback (in a railway system evaluator/certifier capacity) leads
us to conclude that the unitary and integration testing phases are not effective, given that manufacturers consider that:
- – module testing is useless (as a general rule, module tests are defined from the code);
- – software/software integration is reduced to a big-bang integration (integration of all the code in place of a module-by-module integration); at worst, all the code is compiled suddenly and integration is reduced to an interface verification by the compiler;
1 It should be noted that a non-regression analysis can be carried out on a software application
or on a more important element such as equipment, a subsystem, and/or a system.
2 The author of this chapter is an evaluator/certifier within the CERTIFER association
see: www.certifer.asso.fr.6 Formal Methods
- – software/hardware integration is supported by functional testing on a target. If all of the software is being executed correctly on the target machine, the integration is correct.
Identification Classification
Selection Beginning
End Analysis
Implementation V&V
Figure 1.4. Cycle management of anomaliesCost and delay management imply two necessities:
- – N.1: reducing the number of faults introduced into the application during the bottom-up phase of the V-cycle;
- – N.2: identifying faults introduced within the software application as early as possible.
1.2.2. Coding
1.2.2.1. Presentation The classic development process of a software application is based on the use of programming language, for example Ada [ANS 83, ISO 95] C [ISO 99] and/or C++
[ISO 03].
From Classic Languages to Formal Methods 7
Even if these languages have a certain abstraction level with respect to the code ultimately executed on the computer, they necessitate the writing of a line of code. It is not possible to analyze all the current programming languages for all industries. We shall analyze the advancements that have taken place in the rail sector.
1.2.2.2. Assessment
1.2.2.2.1. The Ada language The first rail applications in France were programmed in the middle of the 1980s with the Modula 2 language. Since then however, the Ada 83 language [ANS 83] has become the reference language for the development of safety-critical applications [RIC 94].
As Table 1.1 shows, in the context of applications that have a high level of criticality (SSIL3/SSIL4), the Ada language is only R (recommended); it is necessary to establish a sub-assembly of the language so that use of Ada be HR (highly recommended).
4
3 SSIL0 SSIL1 SSIL2 SSIL3 SSIL4
SSILO
Ada R HR HR R R MODULA-2 R RHR HR R PASCAL R HR HR R R NR C or C++ without restriction R NR Sub-assembl y of C or C++ R R R R R
4 Table 1.1. CENELEC EN 50128 [CEN 01] – Table A.15
Ada was designed on the initiative of the DoD (the US Department of Defense) to federate more than 400 languages or dialects used by this body since the 1970s. Ada is very widely used in the framework of embedded software applications in avionics (airbus), the space (the Ariane rocket), and the rail sector. The principal characteristic of these systems is that they require a correction of the execution.
3 The CENELEC [CEN 01], [CEN 00], [CEN 03] referential, like the CEI/IEC 61508 [IEC 98]
standard, introduces the notion of SIL for Safety Integrity Level, which can take four
values, from 1 to 4. To find out more on SIL management, we advise you to read Chapter 7 of
[BOU 11]. The notion of SSIL (Software SIL) concerns assignment of a safety level to the
software aspect. The SSIL level relates to systematic failures. SSILs can go from 0 up to 4.
SSIL0 software is software that has no impact on safety and must, at the very least, implement
the requirements of the ISO 9001:2008 [ISO 08].8 Formal Methods
The Ada 83 language [ANS 83] has advanced toward a second major standard, Ada 95 [ISO 95], which is the first object-normalized language. It provides the possibility of constructing object-oriented models. The latest version to date is called Ada 2005.