In 2023, the Professional version will be updated twice, through a corrective version in Q1 2023 and an evolutionary version in Q3 2023 with the display of counter-examples in the proof interface. In 2024, the T2 EN50128 and IEC 61508 certified Professional version will be made available, as well as the Community version integrating a RUST code generator.

 

List of corrections for the Professional version Q1 2023:

  • More powerful automatic checking of proof rules Packing of pup file to a project resource
  • Launching bbatch on a given workspace is made easier
  • Archiving in Windows fixed Arguments to the `bb` (loop) command in an interactive proof are now saved in the correct order.
  • Improved type inference in the B compiler
  • Fixed the Linux installer to avoid failures in newer distributions
  • Fixed constant values in the pptranssmt translator
  • The size of the horizontal scroll bar in the proof tree is now correct.
  • XML output from bbatch for the `gs` interactive prover command is now well balanced
  • The GUI does not crash when receiving corrupted XML data from bbatch as part of internal interactions; instead, it produces diagnostic information.
  • Improved assumption selection in the `pptranssmt` translator.
  • `Force(Fast)` is now handled for projects in NG mode (i.e, in `pos` format)
  • The `iterate` operator is now correctly rendered from the proof obligation view in the component editor.
  • Correction in rules created by the SMT hammer in the interactive proof.
  • Improved support for operation calls and inlined imports in NGOP
  • Fixed an encoding issue in the proof mechanism writer `ppTransSmt`
  • Added support for various B operators in the proof mechanism writer `ppTransSmt`
  • Checking for B0 conditions in the type check phase is disabled for system projects.
  • Documentation for Event-B support has been updated with closure implementations (syntax and proof obligations).
  • Error messages displayed in the component editor can be copied to the clipboard.
  • The dialog for saving interactive proofs in the `User_Pass` theory now includes checkboxes for saving to the PMM component file, the PUP component file, or the PatchProver project file.
  • Added setting to display the host name in the main window title
  • Added custom proof obligation generator for optional Event-B proof obligations
  • The user can now undo the closure of the interactive prover (if interactive proof commands have been issued).

List of corrections for the Professional version Q3 2023:

  • Display of counterexamples in the modelling and proof interface. When using the formal B method, design errors correspond to invalid proof obligations. Atelier B automatic provers are not able to identify whether a proof failure is due to a logical error, whereas SMT solvers are able to prove a first-order logic formula but also to refute it and produce a counterexample. These counterexamples can give the user valuable insights into design errors. SMT solvers have been integrated into the most recent version of Atelier B, but only to use their proof capabilities.
Publié le 02/11/2012 |

La validation et la génération de données constantes sont devenus des thèmes importants dans le monde ferroviaire, pour démontrer la sécurité d’un système ferré.

Plusieurs travaux ont été menés dans ce domaine. On citera:

  • le développement par RATP d’un outil de vérification de données ferroviaires, initialement développé autour du moteur de calcul de prédicats B, PredicateB, de l’animateur de modèles B évènementiel Brama, et complété par la suite par le model-checker ProB;
  • les travaux de validation des données par Siemens Transportation Systems, durant le projet européen DEPLOY, en s’appuyant sur le model-checker ProB;
  • la validation et la génération de données par Alstom Transportation Systems, en s’appuyant sur le model-checker ProB, conduisant à la création d’un nouveau type de projet Atelier B: validation/génération de données.

La validation de données constantes consiste à s’assurer que les données d’exploitation d’une ligne de métro telles que la topologie des voies, la position des équipements, etc. respectent un certain corpus de règles de signalisation. Ces données constantes, téléchargées in fine à bord d’équipements de sécurité tels que des pilotes automatiques, participent à la sécurité de l’ensemble et doivent donc être validées en conséquence. Cette validation a longtemps été manuelle, compte tenu de la grande quantité d’informations à manipuler (jusqu’à 100 000 informations élémentaires et plusieurs centaines de règles).

Les progrès réalisés par les model-checkers, et par ProB en particulier, ont permis la constitution de modèles de données, s’appuyant sur le langage mathématique de B, et leur vérification de larges ensembles de données vis à vis de ce modèle, ramenant le temps de vérification de plusieurs mois à quelques heures (hors temps de modélisation) avec un niveau de confiance dans les résultats obtenus bien supérieur.

D’un point de vue technique, le modèle de données et les valeurs à qualifier sont transformés en un modèle B qui est ensuite fourni à ProB, dans le but de:

  • vérifier que les données sont compatible avec le modèle de données. En cas d’incompatibilité, ProB est à même de fournir tous les contre-exemples;
  • générer certaines données, en cas d’instanciation partielle du modèle. Si certaines valeurs ne sont pas fournies, ProB est capable de déterminer leur valeur, si une solution existe.

La validation de données s’insère dans tout cycle de développement, y compris le cycle de développement formel B.