ProB Documentation - User contributions [en]

Sequent Prover

2026-05-15T13:50:35Z

Jan Gruteser:

Using ProB, sequents can be proven interactively.
For the construction of a formal proof, rules for rewriting expressions or decomposing proof goals into simpler subgoals are applied.
To discharge a proof obligation one has to prove one or more sequents, consisting of hypotheses and a goal that must be derived from the hypotheses.

Currently, <tt>.pl</tt> files with proof obligations can be loaded which are exported from Rodin. To generate these files, an Event-B component must be selected in Rodin and the option <tt>ProB Standalone > Export POs for ProB</tt> must be invoked.

All rules that are applicable to the current sequent are displayed in the Operations View.
The implemented rules include the inference and rewrite rules available in Rodin:
* https://wiki.event-b.org/index.php/Inference_Rules
* https://wiki.event-b.org/index.php/All_Rewrite_Rules

The State View shows the current sequent, including its hypotheses and goal, as well as important state properties. Furthermore, the State Visualisation presents both the current state and the preceding state, allowing a comparison between consecutive steps. By right-clicking on a predicate within this visualisation, the user can see rules that are applicable to that selected element.

(Overview img)

==== Transitions ====

Some rules require additional user input, i.e. an expression or a predicate. This is necessary, for example when it is necessary to add a new hypothesis to advance the proof, to instantiate quantifiers like the existential quantifier or perform a case distinction.

Transitions for these rules are displayed in orange / with a question mark. This indicates that the subsequent state is not computed in advance, either because the execution depends on user input, so they cannot be precomputed or it is a transition for an external provers (where no parameters are expected).

[[File:Sequent prover transitions.png|800px]]

<tt>skip_to_cont</tt> is a transition that allows you to skip the current sequent and prove it later. If it is selected here, arr ∈ &integers; ⇸ &integers; will be the next goal. <tt>CONTINUATION</tt> denotes the number of additional sequents in the proof, so now there are four sequents in total, including the current sequent.

==== Input Syntax ====

User input has to be provided in [[Summary_of_B_Syntax|B Syntax]]. Due to syntactic differences between B and Event-B, certain operators must be adapted accordingly. For instance, a cartesian product is written as '''S ** T''', exponentiation as '''a^b''' and set difference as '''S \\ T''' (note that it is written as <tt>\\</tt> in the input because of the escape character <tt>\</tt>).
<tt>finite(S)</tt> is an Event-B operator and is entered as <tt>S:FIN(S)</tt>.

To illustrate a valid input, this is an example predicate for a hypothesis to be added (x ≠ 0 &and; s ∪ t ⊂ &naturals;):

[[File:Sequent prover add hyp.png|700px]]

==== Saving Proofs ====

To save a proof, the proof trace can be stored as a <tt>.prob2trace</tt> file (1a), which can later be reloaded and reused (1b). This option allows proofs to be revised, for example by interactively replaying the trace and modifying some steps. Alternatively, proofs can be exported as HTML documents (2):

[[File:Sequent prover proof saving.png|800px]]

==== Automatic Provers ====

In addition to interactive proving, ProB allows the invocation of external automatic provers. This can be useful for determining whether a given sequent is provable at all. The following provers can be called:

* [[Tutorial Disprover|the ProB (Dis-)Prover]] which searches for counterexamples and can invalidate and prove sequents
* ProB's well-definedness prover for discharging well-definedness proof obligations
* Atelier B's mono-lemma (ml) prover and predicate prover (pp)

To use the Atelier B provers, the path to the <tt>krt</tt> tool must be set via <tt>File > Preferences > ATELIERB_KRT_PATH</tt>. If the provers from Atelier B were installed in Rodin, the <tt>krt</tt> executable might be found within Rodin's configuration directory (path is possibly <tt>/Users/.../rodin/configuration/org.eclipse.osgi/.../krt</tt>).

The question mark shown on transitions for external provers also indicates that they may not be executable. It is the case if too many or unsuitable hypotheses are selected for proving the goal.

==== Examples ====
A few export examples can be found here: https://stups.hhu-hosting.de/models/sequent_prover.

Other languages

2026-03-05T14:08:33Z

Jan Gruteser: /* Using VisB in XTL mode */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symbolic transitions using the predicate <tt>symb_trans/3</tt>. Such transitions are only available via the execute by predicate dialog and are intended for transitions that require user input or have side effects.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

Further recognised predicates are:
* <tt>prob_pragma_string(DefinionName,Value)</tt>: a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt>: number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

=== Using VisB in XTL mode ===

Since ProB 1.15.0, it is possible to use [[VisB|VisB]] with XTL specifications. For this, a B (!) definition file (<tt>.def</tt>) must be used, as with B models, which enables the use of VisB DEFINITIONS. The B definition file can the be linked to the specification using
prob_pragma_string('VISB_DEFINITIONS_FILE',PathToFile).
(or via the VisB view in ProB2-UI).
To access the value of state properties in the current state, e.g. for VisB updates, the external function <tt>STATE_PROPERTY(NameOfProp)</tt> can be used, where <tt>NameOfProp</tt> corresponds to a property of the special style <tt>'='(Name,Value)</tt> in <tt>prop/2</tt>.
A simple example can be found [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/TrafficLight/XTL?ref_type=heads here].

Note that for event predicates the parameter values must be wrapped in <tt>STRING_TO_TERM</tt>, e.g.
rec(event: "set_button", predicate: "buttonState = STRING_TO_TERM(\"on\")")

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Rodin POs and ProB

2026-01-23T12:35:21Z

Jan Gruteser:

What is the relationship between Rodin proof obligations (POs) and ProB.
In short, ProB can be made to check individual proof obligations.
During animation and model checking, ProB will compute its own
verification conditions for invariants, theorems, etc.
However, if the PROOF_INFO preference is set to true (which it is by default)
it will make use of the information about which POs are discharged to simplify
the invariant checking for Event-B models.

== ProB Prover Disprover ==

ProB can be applied to individual POs by clicking the ProB button in the Proof Control view of Rodin.

[[File:disprover_proof_control.png]]

See [[Tutorial_Disprover| the tutorial on the ProB Prover/Disprover]] for more details.

One can also export the POs of a particular Event-B machine for use with the [[Using_the_Command-Line_Version_of_ProB|command-line version of ProB]].

[[File:rodin_export_pos.png]]

This will generate a Prolog file (with .pl ending) which can be read by probcli. It will then check the individual proof obligations.
Here is an example run:

<pre>
probcli GearDoor1_mch.pl
...
Disprover Run Summary: [true-9]
Project LandingGearNew
Machine GearDoor1 (exported Sun Feb 08 10:38:51 CET 2015)
Number of POs: 9 ([INITIALISATION/safety_inv1/INV,env_start_retracting/safety_inv1/INV,env_retract_gear/safety_inv1/INV,env_start_extending/safety_inv1/INV,env_extend_gear/safety_inv1/INV,env_start_open_door/safety_inv1/INV,env_open_door/safety_inv1/INV,env_start_close_door/safety_inv1/INV,env_close_door/safety_inv1/INV])
Number of proven (within Rodin) POs: 9 ([INITIALISATION/safety_inv1/INV,env_start_retracting/safety_inv1/INV,env_retract_gear/safety_inv1/INV,env_start_extending/safety_inv1/INV,env_extend_gear/safety_inv1/INV,env_start_open_door/safety_inv1/INV,env_open_door/safety_inv1/INV,env_start_close_door/safety_inv1/INV,env_close_door/safety_inv1/INV])
ProB Disprover Analysis with timeout 300 ms
Number of proven (by ProB) POs: 9 ([INITIALISATION/safety_inv1/INV,env_start_retracting/safety_inv1/INV,env_retract_gear/safety_inv1/INV,env_start_extending/safety_inv1/INV,env_extend_gear/safety_inv1/INV,env_start_open_door/safety_inv1/INV,env_open_door/safety_inv1/INV,env_start_close_door/safety_inv1/INV,env_close_door/safety_inv1/INV])
Number of disproven (by ProB) POs: 0 ([])
Number of unproven (by ProB) POs: 0 ([])
</pre>

== ProB Model Checker ==

During animation and model checking, ProB will compute its own
verification conditions for invariants, theorems, etc.
However, if the PROOF_INFO preference is set to true (which it is by default)
it will make use of the information about which POs are discharged to simplify
the invariant checking for Event-B models.

The information about discharged proof obligations is automatically obtained by ProB from Rodin. It is also saved in the [[Tutorial_Rodin_Exporting|.eventb export files]].

In ProB Tcl/Tk (aka ProB Classic) you can inspect the so obtained specialized (simplified) invariants for each operation, by choosing one of the commands in the Debug menu:

[[File:prob_show_specialized_invariants_menu.png]]

[[File:prob_show_specialized_invariants_result.png]]

== ProB Sequent Prover ==

Since ProB 1.15.1, ProB includes a [[Sequent_Prover|Sequent Prover]] based on the inference and rewrite rules implemented in Rodin.

Download

2026-01-03T17:55:12Z

Jan Gruteser: /* macOS issues */

== Latest Release ==

Below are links for downloading the latest stable release of probcli (the command line version of ProB) and ProB Tcl/Tk (ProB with a graphical user interface written in Tcl/Tk).
Note: please use the provided start scripts (StartProB.sh or StartProBWin.bat) to start ProB.
The list of changes can be found in the [[ProB_Release_History | ProB release history]].

Details of the [[ProBLicence| ProB Licence can be found here]].
ProB is free to use and open source. For commercial support contact [https://www.stups.uni-duesseldorf.de/~leuschel/ Michael Leuschel]. In particular, we can provide access to the validation report for using ProB as a tool of class T2 or T3 within the European norm [https://de.wikipedia.org/wiki/EN_50128 EN50128].

{| class="table table-bordered wikitable" 
! Platform
! Release Date
! Download
! Dependencies
|-
| colspan="4" style="background-color:lightgrey;" | 1.15.1
|-
| Linux
| 21.12.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.1/ProB.linux64.tar.gz Tarball] 
| Java 8 or newer ([[#Java Requirements for B parser|see below]]), Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Linux|see below]]), [https://www.graphviz.org/download/ GraphViz]
|-
| Windows
| 21.12.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.1/ProB.windows64.zip Zipfile] (Tcl/Tk 8.6), [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.1/ProB.windows64-tcltk-85.zip Zipfile] (Tcl/Tk 8.5)
| Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Windows|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ GraphViz], [[Windows Installation Instructions]]
|-
| macOS
| 21.12.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.1/ProB.macos.zip Zipfile] (Universal ARM/Intel notarized) 
[https://github.com/hhu-stups/homebrew-prob Homebrew Tap]
| macOS 10.14 (Mojave) or newer, Tcl/Tk 8.6 ([[#Tcl/Tk on macOS|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ Graphviz] ([[#Graphviz_Requirements|see below]])
|}

The B parser of ProB requires Java 8 or newer. More details [[#Java Requirements for B parser|are available below]].

The Graphical User Interface of ProB Tcl/Tk requires Tcl/Tk 8.5 or 8.6. More details [[#Tcl/Tk Requirements for ProB Tcl/Tk|are available below]].
The default Tcl/Tk on macOS is broken and will result in black windows, and you have to [[#Tcl/Tk Requirements for ProB Tcl/Tk|install another version of Tcl/Tk]]. (Note: Tcl/Tk 9 is not binary compatible and cannot yet be used.)
All releases include the command-line version probcli which does not require Tcl/Tk.

Releases are compiled for the '''x86_64''' architecture (64-bit Intel).
macOS releases of ProB 1.12.0 and later also support '''aarch64''' (64-bit ARM/Apple Silicon).
The last version built for x86 (32-bit Intel) is ProB 1.8.0 (see [[DownloadPriorVersions|prior versions]]).
If you are using an unsupported architecture or system, you may still be able to [[Running ProB from source|run ProB from source]].

Note that: on macOS you still have to right-click on the application and use "Open", even though ProB Tcl/Tk (and probcli and all libraries) are signed and notarized.

=== Latest Beta Release ===

The latest beta release is [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.13.1-beta1 1.13.1-beta1].
It may be older than the latest final release.
An official beta release always passes all of ProB's tests.
However, we do not follow the stringent checklist for final releases
(e.g., checking SICStus Prolog Spider warnings, checking coverage and additional manual
UI tests).
Also, we do not store coverage reports and other information necessary for T2 certification.

=== Nightly Builds ===

More current [https://stups.hhu-hosting.de/downloads/prob/tcltk/nightly/ nightly integration builds] are also available.
These releases are usually updated every night and old versions are not stored.

Note for macOS users: Nightly builds of ProB are not signed or notarized, so macOS 10.15 and later (Catalina, Big Sur or Monterey, Ventura) will refuse to run them.
As a workaround, you will need to run <code>xattr -r -d com.apple.quarantine *</code> inside the ProB directory before launching ProB.
The stable and beta releases listed above are signed and notarized, so they will run without extra steps.

Automatically generated test [https://stups.hhu-hosting.de/internal/coverage/html/ coverage reports are also available].
They are usually updated once per week.

=== Sourcecode ===

You can download the latest Prolog sourcecode snapshot from: https://stups.hhu-hosting.de/downloads/prob/source/

The source code for the ProB parsers (B, LTL, ...) can be obtained from: https://github.com/hhu-stups/probparsers

=== Prior Versions ===

Prior Versions of ProB going back to 1.3.1 [[DownloadPriorVersions|are available for download here]].
If you are interested in still earlier releases, please have a look at the [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/ Download directory].

== Other ProB tools ==

=== ProB Jupyter Kernel ===

You can now create Jupyter Notebooks in B using the ProB Jupyter kernel.
Downloads, instructions, and source code can be found on [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel its own page].

You can [https://mybinder.org/v2/git/https%3A%2F%2Fgitlab.cs.uni-duesseldorf.de%2Fgeneral%2Fstups%2Fprob2-jupyter-kernel.git/master?filepath=notebooks try out the ProB Jupyter kernel in your browser] without installing it first.
Note that '''notebooks are not saved permanently in this online version!'''
To keep your notebooks, you ''must'' download them before closing the page.

=== ProB for Rodin ===
To install ProB for Rodin, first download a current version of Rodin (e.g., [https://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/3.9/ Rodin 3.9]). Inside Rodin, choose Help -> Install New Software and choose the pre-configured ProB update site.

More [[Tutorial Rodin First Step|detailed installation instructions and a brief tutorial]] are available.

* Nightly builds of ProB for Rodin 3 can be obtained from within Rodin by using the update site https://stups.hhu-hosting.de/rodin/prob1/nightly.

=== ProB2-UI (based on JavaFX)===

Version 1.3.0 of the new JavaFX-based [[ProB2-UI]] is available.
See the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history] for what's new.
You can use these stand-alone versions which come bundled with the right Java runtime environment:
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-1.3.0.exe Windows (x86_64) installer] - requires Windows 10 or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-aarch64-1.3.0.dmg macOS (Apple Silicon) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-x86_64-1.3.0.dmg macOS (Intel) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui_1.3.0_amd64.deb Debian (x86_64) package]

You can also download a [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui-1.3.0-multi.jar multi-platform jar], which works with Java 21 or later on all supported platforms (except macOS on arm64 - we recommend using the native macOS application instead).

Details about new features and improvements can be found in the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history], along with download links for older versions.

Snapshot builds of the current ''development'' version of ProB2-UI (1.3.1-SNAPSHOT) are also available:
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-1.3.1.exe Windows installer snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-aarch64-1.3.1.dmg macOS (Apple Silicon) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-x86_64-1.3.1.dmg macOS (Intel) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui_1.3.1_amd64.deb Debian package snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui-1.3.1-SNAPSHOT-multi.jar Multi-platform jar snapshot]

The source code for ProB2-UI is available at https://github.com/hhu-stups/prob2_ui and can be built by following [https://github.com/hhu-stups/prob2_ui#running-from-source these instructions].

The underlying [[ProB Java API]] of ProB2-UI (aka the ProB 2 kernel) is available to Java developers via [https://central.sonatype.com/artifact/de.hhu.stups/de.prob2.kernel Maven Central].
Its source code can be obtained from: https://github.com/hhu-stups/prob2_kernel.

==== macOS issues ====

When you run the macOS app for the first time, you might have to open the app ''twice'' for ProB2-UI to start properly.
This should only happen once.

The ProB2-UI macOS app releases are signed and notarized, so they should run without issues.
However, the multi-platform jar and snapshot app builds are ''not'' signed or notarized, so macOS will refuse to run them or say that the application is damaged.
As a workaround, right-click the app, select "Open", and confirm the security dialog.
If the dialog still doesn't give you an option to open the app, click "Cancel" and do the same thing again.


=== Editor Support ===

==== VSCODE ====
There is a [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] extension for the Visual Studio Code (VS Code) editor. It integrates with [[Using the Command-Line Version of ProB|command line tool probcli]] to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness Checking#VSCode|well-definedness checking]].
* [https://stups.hhu-hosting.de/downloads/vscode_plugin Download for manual installation]

==== VIM ====
A [https://github.com/bivab/prob.vim VIM plugin for ProB is available]. It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

==== BBedit ====
Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available; these do not use [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]].

== Java Requirements for B Parser ==
The B parser of ProB requires Java 8 or newer. Java 11, 17, etc. are also fully supported.
ProB 1.9.3 is the last version to support Java 7. ProB 1.5.0 is the last version to support Java 6.

You can install a Java Runtime Environment (JRE) from various sources, such as [https://adoptium.net/ Eclipse Adoptium], [https://www.azul.com/downloads/?version=java-8-lts&package=jre-fx Azul Zulu], or your system package manager.

Note: on some systems (macOS) you may have to install the full Java Development Kit (JDK), and not just the JRE, so that Java 8 becomes available to the command-line tools.
Type <code>java -version</code> to check which version is used by default for command-line tools; see also [http://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x this discussion on StackOverflow].
In case you have trouble starting the Java parser you can now set the <code>JAVA_PATH</code> preference of ProB to point to the <code>java</code> tool (or java.exe on Windows).

To check whether ProB can correctly use its Java parser you can type the following (using probcli.exe on Windows):
probcli -version -v
This will try and start the parser and obtain the parser version.
In case Java is not correctly installed you should get an error message.
If you see the error message
<tt>Unsupported major.minor version 52.0</tt>
this means you do not have Java 8 or newer installed. You can try setting the path to the correct java version by setting the JAVA_PATH preference as follows:
probcli -p JAVA_PATH path/to/java -version -v

== Tcl/Tk Requirements for ProB Tcl/Tk ==

ProB Tcl/Tk requires an installation of Tcl/Tk 8.5 or Tcl/Tk 8.6. The command-line tool probcli does not require this.

=== Tcl/Tk on macOS ===
Important note: macOS comes pre-installed with a version of Tcl/Tk which is broken.
This may result in the display of unreadable black windows or crashes in the standard file dialogs.
There are various options to install Tcl/Tk:
* with Homebrew using the [https://formulae.brew.sh/formula/tcl-tk tcl-tk formula]
* with [https://ports.macports.org/port/tcl/ MacPorts]
* use the [http://www.activestate.com/activetcl/downloads/ ActiveTcl version of Tcl/Tk]
You should probably start ProB using the <tt>StartProB.sh</tt> script: it will auto-detect Tcl/Tk versions and set the SP_TCL_DSO environment variable.
Below are more details:

==== Tcl/Tk from Homebrew or MacPorts ====

You can install a newer Tcl/Tk (e.g., 8.6.13) using [https://brew.sh Homebrew] or [https://www.macports.org MacPorts].
Note: In the earlier release 8.6.11 [https://bugs.python.org/issue44828 file open and file save dialogs will not work].
For Homebrew the command to install the[https://formulae.brew.sh/formula/tcl-tk tcl-tk formula] is:
<pre>
brew install tcl-tk
</pre>
The latest versions of Homebrew now install Tcl/Tk 9.0 which does not work yet with ProB.
In this case install
<pre>
brew install tcl-tk@8
</pre>

However, as the location of the libraries is not standard, you have to define the variable <tt>SP_TCL_DSO</tt>.
The <tt>StartProB.sh</tt> script should set SP_TCL_DSO automatically.
You can also define and export this variable yourself before starting ProB from the Terminal by typing this (you may have to adapt the link if you are using another version of Tcl/Tk):
<pre>
export SP_TCL_DSO=/opt/homebrew/Cellar/tcl-tk@8/8.6.16/lib/libtcl8.6.dylib
</pre>
If you have uses MacPorts the path is probably <tt>/opt/local/lib/libtcl.dylib</tt>.
You can also set the variable by adding <tt>-DSP_TCL_DSO=/usr/local/Cellar/tcl-tk/8.6.12/lib/libtcl8.6.dylib</tt> to the command starting ProB. You may also have to install <tt>tk-table</tt> package yourself (it is bundled with Active Tcl).

==== Active Tcl ====

The [http://www.activestate.com/activetcl/downloads/ the ActiveTcl version of Tcl/Tk] is automatically recognised by ProB and you do not have to set <tt>SP_TCL_DSO</tt>.

However, in Active Tcl/Tk 8.6 on macOS the double click in the "Operations View" or other views is not working correctly.
You have to hit the RETURN key in the "Operations View" or right-click on an operation and select "Perform ..." to execute an operation until this is fixed.
The older ersion [http://bugs.python.org/issue15853 8.5.12 has a bug related to copying text], see also [http://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997_type here]).

==== Other Notes ====
Note: on macOS Catalina or later the Tcl/Tk menu bar is sometimes not working. Switching to another application and then back to ProB seems to solve the problem.
If you see the message "<tt>macOS 11 or later required !</tt>" in the terminal when launching <tt>prob</tt> you should re-install Tcl/Tk as described above.

=== Tcl/Tk on Windows ===
We currently provide two downloads of ProB, one for Tcl/Tk 8.6 (which we recommend)
and a version for Tcl/Tk 8.5.
You can use for example the [https://www.activestate.com/products/tcl/ ActiveTcl releases].
Note: For the 64 bit version of ProB for Windows, you have to install the 64 bit Tcl/Tk 8.5 version!
ProB 1.12 (currently available as nightly build) works with both Tcl/Tk 8.5 and 8.6.
You may have to point the environment variable SP_TCL_DSO to the correct DLL before starting ProB. For Tcl/Tk 8.5 this is typically
base-tcl8.5-thread-win32-x86_64.dll.
You can either go to System -> Settings -> Advanced -> Environment Variables
or use the setx command for this:
<pre>
setx SP_TCL_DSO C:\Tcl\bin\base-tcl8.5-thread-win32-x86_64.dll
</pre>

=== Tcl/Tk on Linux ===
On Linux you can typically install Tcl/Tk using <tt>sudo apt-get install tcl8.5 tk8.5</tt>.

On very recent Linux systems (such as Ubuntu 20.04) you may want to download (and compile) [https://www.tcl.tk/software/tcltk/downloadnow85.html Tcl/Tk 8.5] or use [https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/tcl8.5_8.5.19-4_amd64.deb.html packages from earlier releases].

On Linux OpenSuse (12.3) you may have to perform the following for ProB to work:
ln -s /usr/lib/libtk8.5.so /usr/lib/libtk8.5.so.0
ln -s /usr/lib/libtcl8.5.so /usr/lib/libtcl8.5.so.0

Also, some of the feature require the table extension, which can be installed like this:
sudo apt install tk-table
Finally, support for .png ANIMATION_IMG declarations requires the Img package:
sudo apt install libtk-img

== Graphviz Requirements ==

If you wish to view various visualizations generated by ProB Tcl/Tk or probcli you will need [http://www.graphviz.org/ GraphViz].
ProB generates various graphs (state space, custom graph, machine hierarchy,...) as .dot files and then uses the command-line tool <tt>dot</tt> to layout the graph and convert it to PDF.

ProB Tcl/Tk can also use dot-file viewer such as the <tt>dotty</tt> program from GraphViz in Linux.
On macOS and Windows it is more difficult to obtain a good viewer application for dot files. VS Code with the [https://marketplace.visualstudio.com/items?itemName=tintinweb.graphviz-interactive-preview Graphviz Interactive Preview] extension is a candidate.
The commercial OmniGraffle macOS application can import .dot files. A free alternative on macOS may be [https://ports.macports.org/port/graphviz-gui/ graphviz-gui] by [https://www.macports.org MacPorts]. To install the application do this
* <tt>sudo port install graphviz-gui</tt>
The viewer can now be found in /Applications/MacPorts/Graphviz.app (you may have to set the ProB graphical viewer preference <tt>dot_viewer</tt> to this path).
If you do not manage to install a viewer, you should select Preferences -> Graphical Viewer -> PDF within ProB Tcl/Tk.
Indeed, many ProB commands work directly with the command-line tool <tt>dot</tt> which you can install on macOS with MacPorts like this:
* <tt>sudo port install graphviz</tt>
On Mac you can now install the latest version of Graphviz using [https://brew.sh HomeBrew]:

1. <tt>brew uninstall graphviz</tt>
2. <tt>brew install graphviz --with-gts</tt>
3. <tt>brew link --overwrite graphviz</tt>

Step 1. is optional; you only need to use it if you have a prior version of Graphviz installed.
Step3 links the binaries to /usr/local/bin.
This is probably better than using the [http://www.pixelglow.com/graphviz/ older version from Pixelglow].

You can also manually set the DOT (path_to_dot) preference if ProB cannot find the Graphviz dot binary you have installed.

== Short Release History ==

The full [[ProB_Release_History | ProB release history can be found here]].

'''2025-12-21'''
[[Download|ProB 1.15.1]] is available. Automatic use of operation reuse and compression for model checking. STORE_DETAILED_TRANSITION_INFOS preference and calls LTL property. Interactive proof via animator interface for Rodin PO files.

'''2025-06-26'''
[[Download|ProB 1.15.0]] is available. Interactive trace replay. Many [[VisB#VisB_DEFINITIONS |VisB]] improvements (use definition files for all models, grouping of VISB objects in a single definition, VISB_CLICK_META_INFOS, ...). Profiling can be turned on via PROFILING_INFO preference.

'''2024-02-20'''
[[Download|ProB 1.13.0]] is available. Better Rodin theory support. Template strings. Unicode improvements. READ_JSON and other new external functions. VisB support for groups and "use" element. [[Monte_Carlo_Tree_Search_Game_Play|MCTS game play]].

'''2024-02-03'''
[[Download|ProB 1.12.2-fix1]] is available.

'''2023-08-10'''
[[Download|ProB 1.12.2]] is available. [[VisB#VisB_DEFINITIONS_2 |VisB]] improvements.

'''2023-04-04'''
[[Download|ProB 1.12.0]] is available. Call stack infos, performance improvements in parser and solver, new [[LTL_Model_Checking#Supported_Syntax |LTL]] operators, [[VisB#VisB_Additional_SVG_Objects|VisB]] improvements, reals/floats for [[Event-B_Theories|Rodin theories]].

'''2021-12-29'''
[[Download|ProB 1.11.1]] is available. Highlights: identifiers between backquotes, flexible JSON trace replay, DPLLT solving command, improvements to Z3 backend.

'''2021-10-06'''
[[Download|ProB 1.11.0]] is available. Highlights: improved support for infinite sets, operation caching (OPERATION_REUSE), faster LTL checking for safety formulas, more compact .prob files, VisB HTML export, constructive Z3 translation.

'''2020-12-15'''
[[Download|ProB 1.10.0]] is available. Highlights: well-definedness prover, REAL datatype, -lint comand for VSCode and Atom, improved unsat core and error messages.

'''2020-02-19'''
[[Download|ProB 1.9.3]] is available. Highlights: performance improvements, new external functions, performance monitoring.

'''2019-11-11'''
[[Download|ProB 1.9.2]] is available. Minor bugfix release.

'''2019-11-08'''
[[Download|ProB 1.9.1]] is available. Maintenance release.

'''2019-07-12'''
[[Download|ProB 1.9.0]] is available. Highlights: improved error feedback, improved Unicode support, regular expression library, memoization.

'''2018-10-01'''
[[Download|ProB 1.8.2]] is available. Highlights: improved error feedback, support [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel Jupyter kernel], first [[Alloy|support for Alloy models]].

'''2018-03-20'''
[[Download|ProB 1.8.0]] is available. Highlights: terminal colour support, performance improvements for displaying very large values, improved symmetry breaking and constraint solving.

'''2017-10-05'''
[[Download|ProB 1.7.1]] is available. Highlights: performance, non-deterministic assigned variables shown, Z improvements, export history to HTML.

'''2017-07-11'''
[[Download|ProB 1.7.0]] is available. Highlights: improved [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], improved XML/CSV data import and export, RULE DSL language, many improvements in constraint solver.

'''2016-10-20'''
[[Download|ProB 1.6.1]] is available. Highlights: [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], LET and IF-THEN-ELSE for expressions and predicates, XML logging, XML data import, performance improvements.

'''2016-04-22'''
[[Download|ProB 1.6.0]] is available. Highlights: [[Tutorial_Directed_Model_Checking|directed model checking]], [[Using_ProB_with_Z3|Z3 available as backend]], B line comments and unicode symbols, improved error messages, performance improvements.

'''2015-02-19'''
[[Download|ProB 1.5.0]] is available. Highlights: improved random enumeration, MACE/SEM style static symmetry reduction for deferred set elements, [[State_Space_Coverage_Analyses|MC/DC coverage]] analysis for guards and invariants, [[TLC|improved TLC interface]], bug fixes and improvements including but not limited to the constraint solver.

'''2014-08-29'''
[[Download|ProB 1.4.1]], a small bugfix-only release is available. For a list of new features in 1.4.0 see below.

'''2014-08-18'''
[[Download|ProB 1.4.0]] is available. Highlights: CLP(FD)-based constraint solver enabled by default, kernel can handle more operations symbolically, [[TLC|integration of the TLC model checker]], bug fixes and performance improvements.

'''2013-03-04'''
[[Download|ProB 1.3.6]] is available. Highlights: improved constraint propagation for division, modulo, intervals, model checking progress bar, performance improvements, [[Using_ProB_with_KODKOD | improved Kodkod backend]] and use within REPL, and many more.

'''2012-10-08'''
[[Download|ProB 1.3.5]] is available. Highlights: support for external and recursive functions, optional Kodkod backend, [[TLA|TLA+ support]], performance improvements, pragmas, units inference, and many more.

'''2012-03-30'''
A first prototype of an online [[ProB_Logic_Calculator|ProB Logic Calculator]] is available.

'''2011-11-21'''
ProB 1.3.4 is available. Highlights: Evaluation View and Eval window, CSP assertion checking, improved editor, 64-bit version for Mac and Linux, performance improvements, and many more.

'''2011-02-10'''
ProB 1.3.3 and ProB for Rodin 2.3 is available. Highlights: improved performance, constrained-based deadlock checking, record detection, and many more.

'''2010-07-30'''
ProB 1.3.2 is available. Highlights: improved performance, constraint solving over integers (enable in Advanced Preferences), much improved Z support, and many more.

'''2009-12-07'''
ProB 1.3.1 is available. Highlights: new data-structure for large sets and relations (see FM 2009), multi-level validation for Event-B, improved constraint propagation for boolean connectives, and many more.

'''2009-03-20'''
ProB 1.3.0 is available for download. Highlights: New parser and integrated typechecker, install as AtelierB plugin, improved kernel with support for large sets/relations, improved CSP support, faster LTL model checker, Undo/Redo in text editor, graphical formula viewer, user definable custom animations with gifs.

Sequent Prover

2025-12-16T18:08:07Z

Jan Gruteser: Created blank page

ProB2-UI

2025-11-07T13:34:37Z

Jan Gruteser: /* Download */

'''ProB2-UI''' is the new Java-based user interface for ProB. __NOTOC__

== Download ==

'''[[Download#ProB2-UI_(based_on_JavaFX)|Download the latest version of ProB2-UI here]]'''. See also the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history].

The source code for ProB2-UI is available at https://github.com/hhu-stups/prob2_ui and can be built by following [https://github.com/hhu-stups/prob2_ui#running-from-source these instructions].

== Features ==

Compared to the original UI based on Tcl/Tk, this new UI has some unique new features:
* Projects which store formal models, ProB preferences, and verification settings
* Load Rodin models from Rodin workspaces (without having to export them within Rodin)
* Managing and storing multiple trace files for a model, being able to replay all traces
* MC/DC test-case generation
* A view for managing LTL formulas for a model
* Visualisation of models using [[VisB]] and SVG graphics
* An integrated view for all dot-based graph visualisations (state space, machine hierarchy, formulas, projection diagrams, enabling graphs, event refinement hierarchy, ....)
* An integrated view to access all table based statistics (event coverage, MC/DC coverage, read-write matrices, WD POs, ...)
* A multi-language interface, currently providing English, French, German and Russian

We have developed a small
[https://mediathek.hhu.de/watch/1c7946da-3042-423f-a1c3-06833f348ec2 video highlighting the core features] (also on [https://youtu.be/HqTlr6y-hwk YouTube]) on a model the from [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples visb-visualisation-examples]:

<html>
<iframe width='570' height='321' style='width: 570px; height: 321px; border: 1px solid #ccc;' src='https://mediathek.hhu.de/embed/1c7946da-3042-423f-a1c3-06833f348ec2' frameborder='0' allowfullscreen></iframe>
</html>

== Paper/Citing ==

Paper: [https://link.springer.com/chapter/10.1007/978-3-030-85248-1_12 Springer Link], [https://www.researchgate.net/publication/353989368_ProB2-UI_A_Java-Based_User_Interface_for_ProB ResearchGate]

BibTeX citation:

<pre>
@InProceedings{prob2ui,
author="Bendisposto, Jens
and Gele{\ss}us, David
and Jansing, Yumiko
and Leuschel, Michael
and P{\"u}tz, Antonia
and Vu, Fabian
and Werth, Michelle",
editor="Lluch Lafuente, Alberto
and Mavridou, Anastasia",
title="ProB2-UI: A Java-Based User Interface for ProB",
booktitle="Formal Methods for Industrial Critical Systems",
year="2021",
publisher="Springer International Publishing",
address="Cham",
pages="193--201",
abstract="ProB2-UI is a modern JavaFX-based user interface for the animator, constraint solver, and model checker ProB. We present the main features of the tool, especially compared to ProB's previous user interfaces and other available tools for B, Event-B, and other formalisms. We also present some of ProB2-UI's history as well as its uses in the industry since its release in 2019.",
isbn="978-3-030-85248-1"
}
</pre>

== The ProB2-UI Main Window ==

By default the main window is split into three vertical panes (see below).

* In the left pane, the Operations view , showing the operations whose preconditions and guards are true in this state (the view also uses a blue circular arrow icon when an operation does not change the state);
* In the middle the State View, containing the current state of the B machine, listing e.g., the current values of the machine variables;
* In the right pane there are a variety of subviews, which can be activated:
** [[History_View|The History of operations leading to this state (History)]]
** [[Project_View|The Project view]]
** [[Verification_View|The Verification view]]
** [[Statistics_View|The Statistics view]]

[[File:ProB2JavaFX_UI_Overview_New.png||1000px]]

== The ProB2-UI Main Menu Bar ==
The menu bar contains the various commands to access the features of ProB. It includes the menus
*File,
*Edit,
*Formula,
*Consoles,
*Perspectives,
*View,
*Window and
*Help
[[File:File.png|none]]
The File submenu allows you to create a new Project, open an existing project or a machine, open recent projects shown as list and/or clear the list of recent projects, close the ProB2-UI, save your project or reload the currently running machine.
[[File:Edit.png|none]]
The Edit submenu provides two ways to edit the current machine (either in the editor provided by the ProB2-UI or in the your operating systems standard editor) and allows to edit your general and global preferences by opening a seperate window.
[[File:Formula.png|none]]
Here you can add formulas for visualization and open the history chart window.
[[File:Consoles.png|none]]
This submenu leads to two consoles, one Groovy, one B.
[[File:Perspectives.png|none]]
The Perspectives submenu allows you to change the appearance of the main view. The default view is shown at the top and two additional perspectives (Seperated History and Seperated History and Statistics) are preset. By ''Detach Components'' the view can be shown in seperate windows. ''Load'' allows you to make your own perspective by providing an FXML file containing the views but be aware that this might ruin the ability to detach components.
[[File:View.png|none]]
This submenu allows you to adjust font and button size in the ProB2-UI.
[[File:Help.png|none]]
The Help submenu provides you with help about the ProB2-UI, information about the ProB2 UI, ProB2 kernel, ProB CLI and Java version used here and a way to report issues regarding the ProB2-UI.

Download

2025-11-07T12:00:16Z

Jan Gruteser: /* ProB2-UI (based on JavaFX) */

== Latest Release ==

Below are links for downloading the latest stable release of probcli (the command line version of ProB) and ProB Tcl/Tk (ProB with a graphical user interface written in Tcl/Tk).
Note: please use the provided start scripts (StartProB.sh or StartProBWin.bat) to start ProB.
The list of changes can be found in the [[ProB_Release_History | ProB release history]].

Details of the [[ProBLicence| ProB Licence can be found here]].
ProB is free to use and open source. For commercial support contact [https://www.stups.uni-duesseldorf.de/~leuschel/ Michael Leuschel]. In particular, we can provide access to the validation report for using ProB as a tool of class T2 or T3 within the European norm [https://de.wikipedia.org/wiki/EN_50128 EN50128].

{| class="table table-bordered wikitable" 
! Platform
! Release Date
! Download
! Dependencies
|-
| colspan="4" style="background-color:lightgrey;" | 1.15.0
|-
| Linux
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.linux64.tar.gz Tarball] 
| Java 8 or newer ([[#Java Requirements for B parser|see below]]), Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Linux|see below]]), [https://www.graphviz.org/download/ GraphViz]
|-
| Windows
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64.zip Zipfile] (Tcl/Tk 8.6), [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64-tcltk-85.zip Zipfile] (Tcl/Tk 8.5)
| Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Windows|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ GraphViz], [[Windows Installation Instructions]]
|-
| macOS
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.macos.zip Zipfile] (Universal ARM/Intel notarized) 
[https://github.com/hhu-stups/homebrew-prob Homebrew Tap]
| macOS 10.14 (Mojave) or newer, Tcl/Tk 8.6 ([[#Tcl/Tk on macOS|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ Graphviz] ([[#Graphviz_Requirements|see below]])
|}

The B parser of ProB requires Java 8 or newer. More details [[#Java Requirements for B parser|are available below]].

The Graphical User Interface of ProB Tcl/Tk requires Tcl/Tk 8.5 or 8.6. More details [[#Tcl/Tk Requirements for ProB Tcl/Tk|are available below]].
The default Tcl/Tk on macOS is broken and will result in black windows, and you have to [[#Tcl/Tk Requirements for ProB Tcl/Tk|install another version of Tcl/Tk]]. (Note: Tcl/Tk 9 is not binary compatible and cannot yet be used.)
All releases include the command-line version probcli which does not require Tcl/Tk.

Releases are compiled for the '''x86_64''' architecture (64-bit Intel).
macOS releases of ProB 1.12.0 and later also support '''aarch64''' (64-bit ARM/Apple Silicon).
The last version built for x86 (32-bit Intel) is ProB 1.8.0 (see [[DownloadPriorVersions|prior versions]]).
If you are using an unsupported architecture or system, you may still be able to [[Running ProB from source|run ProB from source]].

Note that: on macOS you still have to right-click on the application and use "Open", even though ProB Tcl/Tk (and probcli and all libraries) are signed and notarized.

=== Latest Beta Release ===

The latest beta release is [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.13.1-beta1 1.13.1-beta1].
It may be older than the latest final release.
An official beta release always passes all of ProB's tests.
However, we do not follow the stringent checklist for final releases
(e.g., checking SICStus Prolog Spider warnings, checking coverage and additional manual
UI tests).
Also, we do not store coverage reports and other information necessary for T2 certification.

=== Nightly Builds ===

More current [https://stups.hhu-hosting.de/downloads/prob/tcltk/nightly/ nightly integration builds] are also available.
These releases are usually updated every night and old versions are not stored.

Note for macOS users: Nightly builds of ProB are not signed or notarized, so macOS 10.15 and later (Catalina, Big Sur or Monterey, Ventura) will refuse to run them.
As a workaround, you will need to run <code>xattr -r -d com.apple.quarantine *</code> inside the ProB directory before launching ProB.
The stable and beta releases listed above are signed and notarized, so they will run without extra steps.

Automatically generated test [https://stups.hhu-hosting.de/internal/coverage/html/ coverage reports are also available].
They are usually updated once per week.

=== Sourcecode ===

You can download the latest Prolog sourcecode snapshot from: https://stups.hhu-hosting.de/downloads/prob/source/

The source code for the ProB parsers (B, LTL, ...) can be obtained from: https://github.com/hhu-stups/probparsers

=== Prior Versions ===

Prior Versions of ProB going back to 1.3.1 [[DownloadPriorVersions|are available for download here]].
If you are interested in still earlier releases, please have a look at the [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/ Download directory].

== Other ProB tools ==

=== ProB Jupyter Kernel ===

You can now create Jupyter Notebooks in B using the ProB Jupyter kernel.
Downloads, instructions, and source code can be found on [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel its own page].

You can [https://mybinder.org/v2/git/https%3A%2F%2Fgitlab.cs.uni-duesseldorf.de%2Fgeneral%2Fstups%2Fprob2-jupyter-kernel.git/master?filepath=notebooks try out the ProB Jupyter kernel in your browser] without installing it first.
Note that '''notebooks are not saved permanently in this online version!'''
To keep your notebooks, you ''must'' download them before closing the page.

=== ProB for Rodin ===
To install ProB for Rodin, first download a current version of Rodin (e.g., [https://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/3.9/ Rodin 3.9]). Inside Rodin, choose Help -> Install New Software and choose the pre-configured ProB update site.

More [[Tutorial Rodin First Step|detailed installation instructions and a brief tutorial]] are available.

* Nightly builds of ProB for Rodin 3 can be obtained from within Rodin by using the update site https://stups.hhu-hosting.de/rodin/prob1/nightly.

=== ProB2-UI (based on JavaFX)===

Version 1.3.0 of the new JavaFX-based [[ProB2-UI]] is available.
See the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history] for what's new.
You can use these stand-alone versions which come bundled with the right Java runtime environment:
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-1.3.0.exe Windows (x86_64) installer] - requires Windows 10 or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-aarch64-1.3.0.dmg macOS (Apple Silicon) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-x86_64-1.3.0.dmg macOS (Intel) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui_1.3.0_amd64.deb Debian (x86_64) package]

You can also download a [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui-1.3.0-multi.jar multi-platform jar], which works with Java 21 or later on all supported platforms (except macOS on arm64 - we recommend using the native macOS application instead).

Details about new features and improvements can be found in the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history], along with download links for older versions.

Snapshot builds of the current ''development'' version of ProB2-UI (1.3.1-SNAPSHOT) are also available:
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-1.3.1.exe Windows installer snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-aarch64-1.3.1.dmg macOS (Apple Silicon) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB2-UI-x86_64-1.3.1.dmg macOS (Intel) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui_1.3.1_amd64.deb Debian package snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui-1.3.1-SNAPSHOT-multi.jar Multi-platform jar snapshot]

The source code for ProB2-UI is available at https://github.com/hhu-stups/prob2_ui and can be built by following [https://github.com/hhu-stups/prob2_ui#running-from-source these instructions].

The underlying [[ProB Java API]] of ProB2-UI (aka the ProB 2 kernel) is available to Java developers via [https://central.sonatype.com/artifact/de.hhu.stups/de.prob2.kernel Maven Central].
Its source code can be obtained from: https://github.com/hhu-stups/prob2_kernel.

==== macOS issues ====

When you run the macOS app for the first time, you might have to open the app ''twice'' for ProB 2 UI to start properly.
This should only happen once.

The ProB 2 UI macOS app releases are signed and notarized, so they should run without issues.
However, the multi-platform jar and snapshot app builds are ''not'' signed or notarized, so macOS will refuse to run them or say that the application is damaged.
As a workaround, right-click the app, select "Open", and confirm the security dialog.
If the dialog still doesn't give you an option to open the app, click "Cancel" and do the same thing again.


=== Editor Support ===

==== VSCODE ====
There is a [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] extension for the Visual Studio Code (VS Code) editor. It integrates with [[Using the Command-Line Version of ProB|command line tool probcli]] to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness Checking#VSCode|well-definedness checking]].
* [https://stups.hhu-hosting.de/downloads/vscode_plugin Download for manual installation]

==== VIM ====
A [https://github.com/bivab/prob.vim VIM plugin for ProB is available]. It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

==== BBedit ====
Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available; these do not use [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]].

== Java Requirements for B Parser ==
The B parser of ProB requires Java 8 or newer. Java 11, 17, etc. are also fully supported.
ProB 1.9.3 is the last version to support Java 7. ProB 1.5.0 is the last version to support Java 6.

You can install a Java Runtime Environment (JRE) from various sources, such as [https://adoptium.net/ Eclipse Adoptium], [https://www.azul.com/downloads/?version=java-8-lts&package=jre-fx Azul Zulu], or your system package manager.

Note: on some systems (macOS) you may have to install the full Java Development Kit (JDK), and not just the JRE, so that Java 8 becomes available to the command-line tools.
Type <code>java -version</code> to check which version is used by default for command-line tools; see also [http://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x this discussion on StackOverflow].
In case you have trouble starting the Java parser you can now set the <code>JAVA_PATH</code> preference of ProB to point to the <code>java</code> tool (or java.exe on Windows).

To check whether ProB can correctly use its Java parser you can type the following (using probcli.exe on Windows):
probcli -version -v
This will try and start the parser and obtain the parser version.
In case Java is not correctly installed you should get an error message.
If you see the error message
<tt>Unsupported major.minor version 52.0</tt>
this means you do not have Java 8 or newer installed. You can try setting the path to the correct java version by setting the JAVA_PATH preference as follows:
probcli -p JAVA_PATH path/to/java -version -v

== Tcl/Tk Requirements for ProB Tcl/Tk ==

ProB Tcl/Tk requires an installation of Tcl/Tk 8.5 or Tcl/Tk 8.6. The command-line tool probcli does not require this.

=== Tcl/Tk on macOS ===
Important note: macOS comes pre-installed with a version of Tcl/Tk which is broken.
This may result in the display of unreadable black windows or crashes in the standard file dialogs.
There are various options to install Tcl/Tk:
* with Homebrew using the [https://formulae.brew.sh/formula/tcl-tk tcl-tk formula]
* with [https://ports.macports.org/port/tcl/ MacPorts]
* use the [http://www.activestate.com/activetcl/downloads/ ActiveTcl version of Tcl/Tk]
You should probably start ProB using the <tt>StartProB.sh</tt> script: it will auto-detect Tcl/Tk versions and set the SP_TCL_DSO environment variable.
Below are more details:

==== Tcl/Tk from Homebrew or MacPorts ====

You can install a newer Tcl/Tk (e.g., 8.6.13) using [https://brew.sh Homebrew] or [https://www.macports.org MacPorts].
Note: In the earlier release 8.6.11 [https://bugs.python.org/issue44828 file open and file save dialogs will not work].
For Homebrew the command to install the[https://formulae.brew.sh/formula/tcl-tk tcl-tk formula] is:
<pre>
brew install tcl-tk
</pre>
The latest versions of Homebrew now install Tcl/Tk 9.0 which does not work yet with ProB.
In this case install
<pre>
brew install tcl-tk@8
</pre>

However, as the location of the libraries is not standard, you have to define the variable <tt>SP_TCL_DSO</tt>.
The <tt>StartProB.sh</tt> script should set SP_TCL_DSO automatically.
You can also define and export this variable yourself before starting ProB from the Terminal by typing this (you may have to adapt the link if you are using another version of Tcl/Tk):
<pre>
export SP_TCL_DSO=/opt/homebrew/Cellar/tcl-tk@8/8.6.16/lib/libtcl8.6.dylib
</pre>
If you have uses MacPorts the path is probably <tt>/opt/local/lib/libtcl.dylib</tt>.
You can also set the variable by adding <tt>-DSP_TCL_DSO=/usr/local/Cellar/tcl-tk/8.6.12/lib/libtcl8.6.dylib</tt> to the command starting ProB. You may also have to install <tt>tk-table</tt> package yourself (it is bundled with Active Tcl).

==== Active Tcl ====

The [http://www.activestate.com/activetcl/downloads/ the ActiveTcl version of Tcl/Tk] is automatically recognised by ProB and you do not have to set <tt>SP_TCL_DSO</tt>.

However, in Active Tcl/Tk 8.6 on macOS the double click in the "Operations View" or other views is not working correctly.
You have to hit the RETURN key in the "Operations View" or right-click on an operation and select "Perform ..." to execute an operation until this is fixed.
The older ersion [http://bugs.python.org/issue15853 8.5.12 has a bug related to copying text], see also [http://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997_type here]).

==== Other Notes ====
Note: on macOS Catalina or later the Tcl/Tk menu bar is sometimes not working. Switching to another application and then back to ProB seems to solve the problem.
If you see the message "<tt>macOS 11 or later required !</tt>" in the terminal when launching <tt>prob</tt> you should re-install Tcl/Tk as described above.

=== Tcl/Tk on Windows ===
We currently provide two downloads of ProB, one for Tcl/Tk 8.6 (which we recommend)
and a version for Tcl/Tk 8.5.
You can use for example the [https://www.activestate.com/products/tcl/ ActiveTcl releases].
Note: For the 64 bit version of ProB for Windows, you have to install the 64 bit Tcl/Tk 8.5 version!
ProB 1.12 (currently available as nightly build) works with both Tcl/Tk 8.5 and 8.6.
You may have to point the environment variable SP_TCL_DSO to the correct DLL before starting ProB. For Tcl/Tk 8.5 this is typically
base-tcl8.5-thread-win32-x86_64.dll.
You can either go to System -> Settings -> Advanced -> Environment Variables
or use the setx command for this:
<pre>
setx SP_TCL_DSO C:\Tcl\bin\base-tcl8.5-thread-win32-x86_64.dll
</pre>

=== Tcl/Tk on Linux ===
On Linux you can typically install Tcl/Tk using <tt>sudo apt-get install tcl8.5 tk8.5</tt>.

On very recent Linux systems (such as Ubuntu 20.04) you may want to download (and compile) [https://www.tcl.tk/software/tcltk/downloadnow85.html Tcl/Tk 8.5] or use [https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/tcl8.5_8.5.19-4_amd64.deb.html packages from earlier releases].

On Linux OpenSuse (12.3) you may have to perform the following for ProB to work:
ln -s /usr/lib/libtk8.5.so /usr/lib/libtk8.5.so.0
ln -s /usr/lib/libtcl8.5.so /usr/lib/libtcl8.5.so.0

Also, some of the feature require the table extension, which can be installed like this:
sudo apt install tk-table
Finally, support for .png ANIMATION_IMG declarations requires the Img package:
sudo apt install libtk-img

== Graphviz Requirements ==

If you wish to view various visualizations generated by ProB Tcl/Tk or probcli you will need [http://www.graphviz.org/ GraphViz].
ProB generates various graphs (state space, custom graph, machine hierarchy,...) as .dot files and then uses the command-line tool <tt>dot</tt> to layout the graph and convert it to PDF.

ProB Tcl/Tk can also use dot-file viewer such as the <tt>dotty</tt> program from GraphViz in Linux.
On macOS and Windows it is more difficult to obtain a good viewer application for dot files. VS Code with the [https://marketplace.visualstudio.com/items?itemName=tintinweb.graphviz-interactive-preview Graphviz Interactive Preview] extension is a candidate.
The commercial OmniGraffle macOS application can import .dot files. A free alternative on macOS may be [https://ports.macports.org/port/graphviz-gui/ graphviz-gui] by [https://www.macports.org MacPorts]. To install the application do this
* <tt>sudo port install graphviz-gui</tt>
The viewer can now be found in /Applications/MacPorts/Graphviz.app (you may have to set the ProB graphical viewer preference <tt>dot_viewer</tt> to this path).
If you do not manage to install a viewer, you should select Preferences -> Graphical Viewer -> PDF within ProB Tcl/Tk.
Indeed, many ProB commands work directly with the command-line tool <tt>dot</tt> which you can install on macOS with MacPorts like this:
* <tt>sudo port install graphviz</tt>
On Mac you can now install the latest version of Graphviz using [https://brew.sh HomeBrew]:

1. <tt>brew uninstall graphviz</tt>
2. <tt>brew install graphviz --with-gts</tt>
3. <tt>brew link --overwrite graphviz</tt>

Step 1. is optional; you only need to use it if you have a prior version of Graphviz installed.
Step3 links the binaries to /usr/local/bin.
This is probably better than using the [http://www.pixelglow.com/graphviz/ older version from Pixelglow].

You can also manually set the DOT (path_to_dot) preference if ProB cannot find the Graphviz dot binary you have installed.

== Short Release History ==

The full [[ProB_Release_History | ProB release history can be found here]].

'''2024-02-20'''
[[Download|ProB 1.13.0]] is available. Better Rodin theory support. Template strings. Unicode improvements. READ_JSON and other new external functions. VisB support for groups and "use" element. [[Monte_Carlo_Tree_Search_Game_Play|MCTS game play]].

'''2024-02-03'''
[[Download|ProB 1.12.2-fix1]] is available.

'''2023-08-10'''
[[Download|ProB 1.12.2]] is available. [[VisB#VisB_DEFINITIONS_2 |VisB]] improvements.

'''2023-04-04'''
[[Download|ProB 1.12.0]] is available. Call stack infos, performance improvements in parser and solver, new [[LTL_Model_Checking#Supported_Syntax |LTL]] operators, [[VisB#VisB_Additional_SVG_Objects|VisB]] improvements, reals/floats for [[Event-B_Theories|Rodin theories]].

'''2021-12-29'''
[[Download|ProB 1.11.1]] is available. Highlights: identifiers between backquotes, flexible JSON trace replay, DPLLT solving command, improvements to Z3 backend.

'''2021-10-06'''
[[Download|ProB 1.11.0]] is available. Highlights: improved support for infinite sets, operation caching (OPERATION_REUSE), faster LTL checking for safety formulas, more compact .prob files, VisB HTML export, constructive Z3 translation.

'''2020-12-15'''
[[Download|ProB 1.10.0]] is available. Highlights: well-definedness prover, REAL datatype, -lint comand for VSCode and Atom, improved unsat core and error messages.

'''2020-02-19'''
[[Download|ProB 1.9.3]] is available. Highlights: performance improvements, new external functions, performance monitoring.

'''2019-11-11'''
[[Download|ProB 1.9.2]] is available. Minor bugfix release.

'''2019-11-08'''
[[Download|ProB 1.9.1]] is available. Maintenance release.

'''2019-07-12'''
[[Download|ProB 1.9.0]] is available. Highlights: improved error feedback, improved Unicode support, regular expression library, memoization.

'''2018-10-01'''
[[Download|ProB 1.8.2]] is available. Highlights: improved error feedback, support [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel Jupyter kernel], first [[Alloy|support for Alloy models]].

'''2018-03-20'''
[[Download|ProB 1.8.0]] is available. Highlights: terminal colour support, performance improvements for displaying very large values, improved symmetry breaking and constraint solving.

'''2017-10-05'''
[[Download|ProB 1.7.1]] is available. Highlights: performance, non-deterministic assigned variables shown, Z improvements, export history to HTML.

'''2017-07-11'''
[[Download|ProB 1.7.0]] is available. Highlights: improved [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], improved XML/CSV data import and export, RULE DSL language, many improvements in constraint solver.

'''2016-10-20'''
[[Download|ProB 1.6.1]] is available. Highlights: [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], LET and IF-THEN-ELSE for expressions and predicates, XML logging, XML data import, performance improvements.

'''2016-04-22'''
[[Download|ProB 1.6.0]] is available. Highlights: [[Tutorial_Directed_Model_Checking|directed model checking]], [[Using_ProB_with_Z3|Z3 available as backend]], B line comments and unicode symbols, improved error messages, performance improvements.

'''2015-02-19'''
[[Download|ProB 1.5.0]] is available. Highlights: improved random enumeration, MACE/SEM style static symmetry reduction for deferred set elements, [[State_Space_Coverage_Analyses|MC/DC coverage]] analysis for guards and invariants, [[TLC|improved TLC interface]], bug fixes and improvements including but not limited to the constraint solver.

'''2014-08-29'''
[[Download|ProB 1.4.1]], a small bugfix-only release is available. For a list of new features in 1.4.0 see below.

'''2014-08-18'''
[[Download|ProB 1.4.0]] is available. Highlights: CLP(FD)-based constraint solver enabled by default, kernel can handle more operations symbolically, [[TLC|integration of the TLC model checker]], bug fixes and performance improvements.

'''2013-03-04'''
[[Download|ProB 1.3.6]] is available. Highlights: improved constraint propagation for division, modulo, intervals, model checking progress bar, performance improvements, [[Using_ProB_with_KODKOD | improved Kodkod backend]] and use within REPL, and many more.

'''2012-10-08'''
[[Download|ProB 1.3.5]] is available. Highlights: support for external and recursive functions, optional Kodkod backend, [[TLA|TLA+ support]], performance improvements, pragmas, units inference, and many more.

'''2012-03-30'''
A first prototype of an online [[ProB_Logic_Calculator|ProB Logic Calculator]] is available.

'''2011-11-21'''
ProB 1.3.4 is available. Highlights: Evaluation View and Eval window, CSP assertion checking, improved editor, 64-bit version for Mac and Linux, performance improvements, and many more.

'''2011-02-10'''
ProB 1.3.3 and ProB for Rodin 2.3 is available. Highlights: improved performance, constrained-based deadlock checking, record detection, and many more.

'''2010-07-30'''
ProB 1.3.2 is available. Highlights: improved performance, constraint solving over integers (enable in Advanced Preferences), much improved Z support, and many more.

'''2009-12-07'''
ProB 1.3.1 is available. Highlights: new data-structure for large sets and relations (see FM 2009), multi-level validation for Event-B, improved constraint propagation for boolean connectives, and many more.

'''2009-03-20'''
ProB 1.3.0 is available for download. Highlights: New parser and integrated typechecker, install as AtelierB plugin, improved kernel with support for large sets/relations, improved CSP support, faster LTL model checker, Undo/Redo in text editor, graphical formula viewer, user definable custom animations with gifs.

Handbook/Advanced Features

2025-10-28T07:09:15Z

Jan Gruteser:

= [[Bash Completion]] =
{{:Bash Completion}}

= [[B2SAT]] =
{{:B2SAT}}

= [[Common Subexpression Elimination]] =
{{:Common Subexpression Elimination}}

= [[PROBPATH|The ProB Search Path]] =
{{:PROBPATH}}
{{DISPLAYTITLE:Handbook/Advanced Features}} 

= [[TLC]] =
{{:TLC}}

= [[Generating Documents with ProB and Latex]] =
{{:Generating Documents with ProB and Latex}}

= [[Using ProB with Atelier B]] =
{{:Using ProB with Atelier B}}

= [[Using ProB with KODKOD]] =
{{:Using ProB with KODKOD}}

= [[Using ProB with Z3]] =
{{:Using ProB with Z3}}

Download

2025-10-13T11:35:50Z

Jan Gruteser: /* Editor Support */

== Latest Release ==

Below are links for downloading the latest stable release of probcli (the command line version of ProB) and ProB Tcl/Tk (ProB with a graphical user interface written in Tcl/Tk).
Note: please use the provided start scripts (StartProB.sh or StartProBWin.bat) to start ProB.
The list of changes can be found in the [[ProB_Release_History | ProB release history]].

Details of the [[ProBLicence| ProB Licence can be found here]].
ProB is free to use and open source. For commercial support contact [https://www.stups.uni-duesseldorf.de/~leuschel/ Michael Leuschel]. In particular, we can provide access to the validation report for using ProB as a tool of class T2 or T3 within the European norm [https://de.wikipedia.org/wiki/EN_50128 EN50128].

{| class="table table-bordered wikitable" 
! Platform
! Release Date
! Download
! Dependencies
|-
| colspan="4" style="background-color:lightgrey;" | 1.15.0
|-
| Linux
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.linux64.tar.gz Tarball] 
| Java 8 or newer ([[#Java Requirements for B parser|see below]]), Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Linux|see below]]), [https://www.graphviz.org/download/ GraphViz]
|-
| Windows
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64.zip Zipfile] (Tcl/Tk 8.6), [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64-tcltk-85.zip Zipfile] (Tcl/Tk 8.5)
| Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Windows|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ GraphViz], [[Windows Installation Instructions]]
|-
| macOS
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.macos.zip Zipfile] (Universal ARM/Intel notarized) 
[https://github.com/hhu-stups/homebrew-prob Homebrew Tap]
| macOS 10.14 (Mojave) or newer, Tcl/Tk 8.6 ([[#Tcl/Tk on macOS|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ Graphviz] ([[#Graphviz_Requirements|see below]])
|}

The B parser of ProB requires Java 8 or newer. More details [[#Java Requirements for B parser|are available below]].

The Graphical User Interface of ProB Tcl/Tk requires Tcl/Tk 8.5 or 8.6. More details [[#Tcl/Tk Requirements for ProB Tcl/Tk|are available below]].
The default Tcl/Tk on macOS is broken and will result in black windows, and you have to [[#Tcl/Tk Requirements for ProB Tcl/Tk|install another version of Tcl/Tk]]. (Note: Tcl/Tk 9 is not binary compatible and cannot yet be used.)
All releases include the command-line version probcli which does not require Tcl/Tk.

Releases are compiled for the '''x86_64''' architecture (64-bit Intel).
macOS releases of ProB 1.12.0 and later also support '''aarch64''' (64-bit ARM/Apple Silicon).
The last version built for x86 (32-bit Intel) is ProB 1.8.0 (see [[DownloadPriorVersions|prior versions]]).
If you are using an unsupported architecture or system, you may still be able to [[Running ProB from source|run ProB from source]].

Note that: on macOS you still have to right-click on the application and use "Open", even though ProB Tcl/Tk (and probcli and all libraries) are signed and notarized.

=== Latest Beta Release ===

The latest beta release is [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.13.1-beta1 1.13.1-beta1].
It may be older than the latest final release.
An official beta release always passes all of ProB's tests.
However, we do not follow the stringent checklist for final releases
(e.g., checking SICStus Prolog Spider warnings, checking coverage and additional manual
UI tests).
Also, we do not store coverage reports and other information necessary for T2 certification.

=== Nightly Builds ===

More current [https://stups.hhu-hosting.de/downloads/prob/tcltk/nightly/ nightly integration builds] are also available.
These releases are usually updated every night and old versions are not stored.

Note for macOS users: Nightly builds of ProB are not signed or notarized, so macOS 10.15 and later (Catalina, Big Sur or Monterey, Ventura) will refuse to run them.
As a workaround, you will need to run <code>xattr -r -d com.apple.quarantine *</code> inside the ProB directory before launching ProB.
The stable and beta releases listed above are signed and notarized, so they will run without extra steps.

Automatically generated test [https://stups.hhu-hosting.de/internal/coverage/html/ coverage reports are also available].
They are usually updated once per week.

=== Sourcecode ===

You can download the latest Prolog sourcecode snapshot from: https://stups.hhu-hosting.de/downloads/prob/source/

The source code for the ProB parsers (B, LTL, ...) can be obtained from: https://github.com/hhu-stups/probparsers

=== Prior Versions ===

Prior Versions of ProB going back to 1.3.1 [[DownloadPriorVersions|are available for download here]].
If you are interested in still earlier releases, please have a look at the [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/ Download directory].

== Other ProB tools ==

=== ProB Jupyter Kernel ===

You can now create Jupyter Notebooks in B using the ProB Jupyter kernel.
Downloads, instructions, and source code can be found on [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel its own page].

You can [https://mybinder.org/v2/git/https%3A%2F%2Fgitlab.cs.uni-duesseldorf.de%2Fgeneral%2Fstups%2Fprob2-jupyter-kernel.git/master?filepath=notebooks try out the ProB Jupyter kernel in your browser] without installing it first.
Note that '''notebooks are not saved permanently in this online version!'''
To keep your notebooks, you ''must'' download them before closing the page.

=== ProB for Rodin ===
To install ProB for Rodin, first download a current version of Rodin (e.g., [https://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/3.9/ Rodin 3.9]). Inside Rodin, choose Help -> Install New Software and choose the pre-configured ProB update site.

More [[Tutorial Rodin First Step|detailed installation instructions and a brief tutorial]] are available.

* Nightly builds of ProB for Rodin 3 can be obtained from within Rodin by using the update site https://stups.hhu-hosting.de/rodin/prob1/nightly.

=== ProB2-UI (based on JavaFX)===

Version 1.3.0 of the new JavaFX-based [[ProB2-UI]] is available.
See the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history] for what's new.
You can use these stand-alone versions which come bundled with the right Java runtime environment:
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-1.3.0.exe Windows (x86_64) installer] - requires Windows 10 or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-aarch64-1.3.0.dmg macOS (Apple Silicon) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-x86_64-1.3.0.dmg macOS (Intel) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui_1.3.0_amd64.deb Debian (x86_64) package]

You can also download a [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui-1.3.0-multi.jar multi-platform jar], which works with Java 21 or later on all supported platforms (except macOS on arm64 - we recommend using the native macOS application instead).

Details about new features and improvements can be found in the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history], along with download links for older versions.

Snapshot builds of the current ''development'' version of ProB2-UI (1.3.1-SNAPSHOT) are also available:
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-1.3.1.exe Windows installer snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-aarch64-1.3.1.dmg macOS (Apple Silicon) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-x86_64-1.3.1.dmg macOS (Intel) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui_1.3.1_amd64.deb Debian package snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui-1.3.1-SNAPSHOT-multi.jar Multi-platform jar snapshot]

The source code for ProB2-UI is available at https://github.com/hhu-stups/prob2_ui and can be built by following [https://github.com/hhu-stups/prob2_ui#running-from-source these instructions].

The underlying [[ProB Java API]] of ProB2-UI (aka the ProB 2 kernel) is available to Java developers via [https://central.sonatype.com/artifact/de.hhu.stups/de.prob2.kernel Maven Central].
Its source code can be obtained from: https://github.com/hhu-stups/prob2_kernel.

==== macOS issues ====

When you run the macOS app for the first time, you might have to open the app ''twice'' for ProB 2 UI to start properly.
This should only happen once.

The ProB 2 UI macOS app releases are signed and notarized, so they should run without issues.
However, the multi-platform jar and snapshot app builds are ''not'' signed or notarized, so macOS will refuse to run them or say that the application is damaged.
As a workaround, right-click the app, select "Open", and confirm the security dialog.
If the dialog still doesn't give you an option to open the app, click "Cancel" and do the same thing again.


=== Editor Support ===

* There is a [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] extension for the Visual Studio Code (VS Code) editor. It integrates with [[Using the Command-Line Version of ProB|command line tool probcli]] to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness Checking#VSCode|well-definedness checking]].
** [https://stups.hhu-hosting.de/downloads/vscode_plugin Download for manual installation]

* A [https://github.com/bivab/prob.vim VIM plugin for ProB is available]. It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

* Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available; these do not use [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]].

== Java Requirements for B Parser ==
The B parser of ProB requires Java 8 or newer. Java 11, 17, etc. are also fully supported.
ProB 1.9.3 is the last version to support Java 7. ProB 1.5.0 is the last version to support Java 6.

You can install a Java Runtime Environment (JRE) from various sources, such as [https://adoptium.net/ Eclipse Adoptium], [https://www.azul.com/downloads/?version=java-8-lts&package=jre-fx Azul Zulu], or your system package manager.

Note: on some systems (macOS) you may have to install the full Java Development Kit (JDK), and not just the JRE, so that Java 8 becomes available to the command-line tools.
Type <code>java -version</code> to check which version is used by default for command-line tools; see also [http://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x this discussion on StackOverflow].
In case you have trouble starting the Java parser you can now set the <code>JAVA_PATH</code> preference of ProB to point to the <code>java</code> tool (or java.exe on Windows).

To check whether ProB can correctly use its Java parser you can type the following (using probcli.exe on Windows):
probcli -version -v
This will try and start the parser and obtain the parser version.
In case Java is not correctly installed you should get an error message.
If you see the error message
<tt>Unsupported major.minor version 52.0</tt>
this means you do not have Java 8 or newer installed. You can try setting the path to the correct java version by setting the JAVA_PATH preference as follows:
probcli -p JAVA_PATH path/to/java -version -v

== Tcl/Tk Requirements for ProB Tcl/Tk ==

ProB Tcl/Tk requires an installation of Tcl/Tk 8.5 or Tcl/Tk 8.6. The command-line tool probcli does not require this.

=== Tcl/Tk on macOS ===
Important note: macOS comes pre-installed with a version of Tcl/Tk which is broken.
This may result in the display of unreadable black windows or crashes in the standard file dialogs.
There are various options to install Tcl/Tk:
* with Homebrew using the [https://formulae.brew.sh/formula/tcl-tk tcl-tk formula]
* with [https://ports.macports.org/port/tcl/ MacPorts]
* use the [http://www.activestate.com/activetcl/downloads/ ActiveTcl version of Tcl/Tk]
You should probably start ProB using the <tt>StartProB.sh</tt> script: it will auto-detect Tcl/Tk versions and set the SP_TCL_DSO environment variable.
Below are more details:

==== Tcl/Tk from Homebrew or MacPorts ====

You can install a newer Tcl/Tk (e.g., 8.6.13) using [https://brew.sh Homebrew] or [https://www.macports.org MacPorts].
Note: In the earlier release 8.6.11 [https://bugs.python.org/issue44828 file open and file save dialogs will not work].
For Homebrew the command to install the[https://formulae.brew.sh/formula/tcl-tk tcl-tk formula] is:
<pre>
brew install tcl-tk
</pre>
The latest versions of Homebrew now install Tcl/Tk 9.0 which does not work yet with ProB.
In this case install
<pre>
brew install tcl-tk@8
</pre>

However, as the location of the libraries is not standard, you have to define the variable <tt>SP_TCL_DSO</tt>.
The <tt>StartProB.sh</tt> script should set SP_TCL_DSO automatically.
You can also define and export this variable yourself before starting ProB from the Terminal by typing this (you may have to adapt the link if you are using another version of Tcl/Tk):
<pre>
export SP_TCL_DSO=/opt/homebrew/Cellar/tcl-tk@8/8.6.16/lib/libtcl8.6.dylib
</pre>
If you have uses MacPorts the path is probably <tt>/opt/local/lib/libtcl.dylib</tt>.
You can also set the variable by adding <tt>-DSP_TCL_DSO=/usr/local/Cellar/tcl-tk/8.6.12/lib/libtcl8.6.dylib</tt> to the command starting ProB. You may also have to install <tt>tk-table</tt> package yourself (it is bundled with Active Tcl).

==== Active Tcl ====

The [http://www.activestate.com/activetcl/downloads/ the ActiveTcl version of Tcl/Tk] is automatically recognised by ProB and you do not have to set <tt>SP_TCL_DSO</tt>.

However, in Active Tcl/Tk 8.6 on macOS the double click in the "Operations View" or other views is not working correctly.
You have to hit the RETURN key in the "Operations View" or right-click on an operation and select "Perform ..." to execute an operation until this is fixed.
The older ersion [http://bugs.python.org/issue15853 8.5.12 has a bug related to copying text], see also [http://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997_type here]).

==== Other Notes ====
Note: on macOS Catalina or later the Tcl/Tk menu bar is sometimes not working. Switching to another application and then back to ProB seems to solve the problem.
If you see the message "<tt>macOS 11 or later required !</tt>" in the terminal when launching <tt>prob</tt> you should re-install Tcl/Tk as described above.

=== Tcl/Tk on Windows ===
We currently provide two downloads of ProB, one for Tcl/Tk 8.6 (which we recommend)
and a version for Tcl/Tk 8.5.
You can use for example the [https://www.activestate.com/products/tcl/ ActiveTcl releases].
Note: For the 64 bit version of ProB for Windows, you have to install the 64 bit Tcl/Tk 8.5 version!
ProB 1.12 (currently available as nightly build) works with both Tcl/Tk 8.5 and 8.6.
You may have to point the environment variable SP_TCL_DSO to the correct DLL before starting ProB. For Tcl/Tk 8.5 this is typically
base-tcl8.5-thread-win32-x86_64.dll.
You can either go to System -> Settings -> Advanced -> Environment Variables
or use the setx command for this:
<pre>
setx SP_TCL_DSO C:\Tcl\bin\base-tcl8.5-thread-win32-x86_64.dll
</pre>

=== Tcl/Tk on Linux ===
On Linux you can typically install Tcl/Tk using <tt>sudo apt-get install tcl8.5 tk8.5</tt>.

On very recent Linux systems (such as Ubuntu 20.04) you may want to download (and compile) [https://www.tcl.tk/software/tcltk/downloadnow85.html Tcl/Tk 8.5] or use [https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/tcl8.5_8.5.19-4_amd64.deb.html packages from earlier releases].

On Linux OpenSuse (12.3) you may have to perform the following for ProB to work:
ln -s /usr/lib/libtk8.5.so /usr/lib/libtk8.5.so.0
ln -s /usr/lib/libtcl8.5.so /usr/lib/libtcl8.5.so.0

Also, some of the feature require the table extension, which can be installed like this:
sudo apt install tk-table
Finally, support for .png ANIMATION_IMG declarations requires the Img package:
sudo apt install libtk-img

== Graphviz Requirements ==

If you wish to view various visualizations generated by ProB Tcl/Tk or probcli you will need [http://www.graphviz.org/ GraphViz].
ProB generates various graphs (state space, custom graph, machine hierarchy,...) as .dot files and then uses the command-line tool <tt>dot</tt> to layout the graph and convert it to PDF.

ProB Tcl/Tk can also use dot-file viewer such as the <tt>dotty</tt> program from GraphViz in Linux.
On macOS and Windows it is more difficult to obtain a good viewer application for dot files. VS Code with the [https://marketplace.visualstudio.com/items?itemName=tintinweb.graphviz-interactive-preview Graphviz Interactive Preview] extension is a candidate.
The commercial OmniGraffle macOS application can import .dot files. A free alternative on macOS may be [https://ports.macports.org/port/graphviz-gui/ graphviz-gui] by [https://www.macports.org MacPorts]. To install the application do this
* <tt>sudo port install graphviz-gui</tt>
The viewer can now be found in /Applications/MacPorts/Graphviz.app (you may have to set the ProB graphical viewer preference <tt>dot_viewer</tt> to this path).
If you do not manage to install a viewer, you should select Preferences -> Graphical Viewer -> PDF within ProB Tcl/Tk.
Indeed, many ProB commands work directly with the command-line tool <tt>dot</tt> which you can install on macOS with MacPorts like this:
* <tt>sudo port install graphviz</tt>
On Mac you can now install the latest version of Graphviz using [https://brew.sh HomeBrew]:

1. <tt>brew uninstall graphviz</tt>
2. <tt>brew install graphviz --with-gts</tt>
3. <tt>brew link --overwrite graphviz</tt>

Step 1. is optional; you only need to use it if you have a prior version of Graphviz installed.
Step3 links the binaries to /usr/local/bin.
This is probably better than using the [http://www.pixelglow.com/graphviz/ older version from Pixelglow].

You can also manually set the DOT (path_to_dot) preference if ProB cannot find the Graphviz dot binary you have installed.

== Short Release History ==

The full [[ProB_Release_History | ProB release history can be found here]].

'''2024-02-20'''
[[Download|ProB 1.13.0]] is available. Better Rodin theory support. Template strings. Unicode improvements. READ_JSON and other new external functions. VisB support for groups and "use" element. [[Monte_Carlo_Tree_Search_Game_Play|MCTS game play]].

'''2024-02-03'''
[[Download|ProB 1.12.2-fix1]] is available.

'''2023-08-10'''
[[Download|ProB 1.12.2]] is available. [[VisB#VisB_DEFINITIONS_2 |VisB]] improvements.

'''2023-04-04'''
[[Download|ProB 1.12.0]] is available. Call stack infos, performance improvements in parser and solver, new [[LTL_Model_Checking#Supported_Syntax |LTL]] operators, [[VisB#VisB_Additional_SVG_Objects|VisB]] improvements, reals/floats for [[Event-B_Theories|Rodin theories]].

'''2021-12-29'''
[[Download|ProB 1.11.1]] is available. Highlights: identifiers between backquotes, flexible JSON trace replay, DPLLT solving command, improvements to Z3 backend.

'''2021-10-06'''
[[Download|ProB 1.11.0]] is available. Highlights: improved support for infinite sets, operation caching (OPERATION_REUSE), faster LTL checking for safety formulas, more compact .prob files, VisB HTML export, constructive Z3 translation.

'''2020-12-15'''
[[Download|ProB 1.10.0]] is available. Highlights: well-definedness prover, REAL datatype, -lint comand for VSCode and Atom, improved unsat core and error messages.

'''2020-02-19'''
[[Download|ProB 1.9.3]] is available. Highlights: performance improvements, new external functions, performance monitoring.

'''2019-11-11'''
[[Download|ProB 1.9.2]] is available. Minor bugfix release.

'''2019-11-08'''
[[Download|ProB 1.9.1]] is available. Maintenance release.

'''2019-07-12'''
[[Download|ProB 1.9.0]] is available. Highlights: improved error feedback, improved Unicode support, regular expression library, memoization.

'''2018-10-01'''
[[Download|ProB 1.8.2]] is available. Highlights: improved error feedback, support [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel Jupyter kernel], first [[Alloy|support for Alloy models]].

'''2018-03-20'''
[[Download|ProB 1.8.0]] is available. Highlights: terminal colour support, performance improvements for displaying very large values, improved symmetry breaking and constraint solving.

'''2017-10-05'''
[[Download|ProB 1.7.1]] is available. Highlights: performance, non-deterministic assigned variables shown, Z improvements, export history to HTML.

'''2017-07-11'''
[[Download|ProB 1.7.0]] is available. Highlights: improved [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], improved XML/CSV data import and export, RULE DSL language, many improvements in constraint solver.

'''2016-10-20'''
[[Download|ProB 1.6.1]] is available. Highlights: [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], LET and IF-THEN-ELSE for expressions and predicates, XML logging, XML data import, performance improvements.

'''2016-04-22'''
[[Download|ProB 1.6.0]] is available. Highlights: [[Tutorial_Directed_Model_Checking|directed model checking]], [[Using_ProB_with_Z3|Z3 available as backend]], B line comments and unicode symbols, improved error messages, performance improvements.

'''2015-02-19'''
[[Download|ProB 1.5.0]] is available. Highlights: improved random enumeration, MACE/SEM style static symmetry reduction for deferred set elements, [[State_Space_Coverage_Analyses|MC/DC coverage]] analysis for guards and invariants, [[TLC|improved TLC interface]], bug fixes and improvements including but not limited to the constraint solver.

'''2014-08-29'''
[[Download|ProB 1.4.1]], a small bugfix-only release is available. For a list of new features in 1.4.0 see below.

'''2014-08-18'''
[[Download|ProB 1.4.0]] is available. Highlights: CLP(FD)-based constraint solver enabled by default, kernel can handle more operations symbolically, [[TLC|integration of the TLC model checker]], bug fixes and performance improvements.

'''2013-03-04'''
[[Download|ProB 1.3.6]] is available. Highlights: improved constraint propagation for division, modulo, intervals, model checking progress bar, performance improvements, [[Using_ProB_with_KODKOD | improved Kodkod backend]] and use within REPL, and many more.

'''2012-10-08'''
[[Download|ProB 1.3.5]] is available. Highlights: support for external and recursive functions, optional Kodkod backend, [[TLA|TLA+ support]], performance improvements, pragmas, units inference, and many more.

'''2012-03-30'''
A first prototype of an online [[ProB_Logic_Calculator|ProB Logic Calculator]] is available.

'''2011-11-21'''
ProB 1.3.4 is available. Highlights: Evaluation View and Eval window, CSP assertion checking, improved editor, 64-bit version for Mac and Linux, performance improvements, and many more.

'''2011-02-10'''
ProB 1.3.3 and ProB for Rodin 2.3 is available. Highlights: improved performance, constrained-based deadlock checking, record detection, and many more.

'''2010-07-30'''
ProB 1.3.2 is available. Highlights: improved performance, constraint solving over integers (enable in Advanced Preferences), much improved Z support, and many more.

'''2009-12-07'''
ProB 1.3.1 is available. Highlights: new data-structure for large sets and relations (see FM 2009), multi-level validation for Event-B, improved constraint propagation for boolean connectives, and many more.

'''2009-03-20'''
ProB 1.3.0 is available for download. Highlights: New parser and integrated typechecker, install as AtelierB plugin, improved kernel with support for large sets/relations, improved CSP support, faster LTL model checker, Undo/Redo in text editor, graphical formula viewer, user definable custom animations with gifs.

Download

2025-10-13T11:34:48Z

Jan Gruteser: /* Editor Support */

== Latest Release ==

Below are links for downloading the latest stable release of probcli (the command line version of ProB) and ProB Tcl/Tk (ProB with a graphical user interface written in Tcl/Tk).
Note: please use the provided start scripts (StartProB.sh or StartProBWin.bat) to start ProB.
The list of changes can be found in the [[ProB_Release_History | ProB release history]].

Details of the [[ProBLicence| ProB Licence can be found here]].
ProB is free to use and open source. For commercial support contact [https://www.stups.uni-duesseldorf.de/~leuschel/ Michael Leuschel]. In particular, we can provide access to the validation report for using ProB as a tool of class T2 or T3 within the European norm [https://de.wikipedia.org/wiki/EN_50128 EN50128].

{| class="table table-bordered wikitable" 
! Platform
! Release Date
! Download
! Dependencies
|-
| colspan="4" style="background-color:lightgrey;" | 1.15.0
|-
| Linux
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.linux64.tar.gz Tarball] 
| Java 8 or newer ([[#Java Requirements for B parser|see below]]), Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Linux|see below]]), [https://www.graphviz.org/download/ GraphViz]
|-
| Windows
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64.zip Zipfile] (Tcl/Tk 8.6), [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.windows64-tcltk-85.zip Zipfile] (Tcl/Tk 8.5)
| Tcl/Tk 8.5 or 8.6 ([[#Tcl/Tk on Windows|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ GraphViz], [[Windows Installation Instructions]]
|-
| macOS
| 26.6.2025
| [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.15.0/ProB.macos.zip Zipfile] (Universal ARM/Intel notarized) 
[https://github.com/hhu-stups/homebrew-prob Homebrew Tap]
| macOS 10.14 (Mojave) or newer, Tcl/Tk 8.6 ([[#Tcl/Tk on macOS|see below]]), Java 8 or newer ([[#Java Requirements for B parser|see below]]), [https://www.graphviz.org/download/ Graphviz] ([[#Graphviz_Requirements|see below]])
|}

The B parser of ProB requires Java 8 or newer. More details [[#Java Requirements for B parser|are available below]].

The Graphical User Interface of ProB Tcl/Tk requires Tcl/Tk 8.5 or 8.6. More details [[#Tcl/Tk Requirements for ProB Tcl/Tk|are available below]].
The default Tcl/Tk on macOS is broken and will result in black windows, and you have to [[#Tcl/Tk Requirements for ProB Tcl/Tk|install another version of Tcl/Tk]]. (Note: Tcl/Tk 9 is not binary compatible and cannot yet be used.)
All releases include the command-line version probcli which does not require Tcl/Tk.

Releases are compiled for the '''x86_64''' architecture (64-bit Intel).
macOS releases of ProB 1.12.0 and later also support '''aarch64''' (64-bit ARM/Apple Silicon).
The last version built for x86 (32-bit Intel) is ProB 1.8.0 (see [[DownloadPriorVersions|prior versions]]).
If you are using an unsupported architecture or system, you may still be able to [[Running ProB from source|run ProB from source]].

Note that: on macOS you still have to right-click on the application and use "Open", even though ProB Tcl/Tk (and probcli and all libraries) are signed and notarized.

=== Latest Beta Release ===

The latest beta release is [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/1.13.1-beta1 1.13.1-beta1].
It may be older than the latest final release.
An official beta release always passes all of ProB's tests.
However, we do not follow the stringent checklist for final releases
(e.g., checking SICStus Prolog Spider warnings, checking coverage and additional manual
UI tests).
Also, we do not store coverage reports and other information necessary for T2 certification.

=== Nightly Builds ===

More current [https://stups.hhu-hosting.de/downloads/prob/tcltk/nightly/ nightly integration builds] are also available.
These releases are usually updated every night and old versions are not stored.

Note for macOS users: Nightly builds of ProB are not signed or notarized, so macOS 10.15 and later (Catalina, Big Sur or Monterey, Ventura) will refuse to run them.
As a workaround, you will need to run <code>xattr -r -d com.apple.quarantine *</code> inside the ProB directory before launching ProB.
The stable and beta releases listed above are signed and notarized, so they will run without extra steps.

Automatically generated test [https://stups.hhu-hosting.de/internal/coverage/html/ coverage reports are also available].
They are usually updated once per week.

=== Sourcecode ===

You can download the latest Prolog sourcecode snapshot from: https://stups.hhu-hosting.de/downloads/prob/source/

The source code for the ProB parsers (B, LTL, ...) can be obtained from: https://github.com/hhu-stups/probparsers

=== Prior Versions ===

Prior Versions of ProB going back to 1.3.1 [[DownloadPriorVersions|are available for download here]].
If you are interested in still earlier releases, please have a look at the [https://stups.hhu-hosting.de/downloads/prob/tcltk/releases/ Download directory].

== Other ProB tools ==

=== ProB Jupyter Kernel ===

You can now create Jupyter Notebooks in B using the ProB Jupyter kernel.
Downloads, instructions, and source code can be found on [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel its own page].

You can [https://mybinder.org/v2/git/https%3A%2F%2Fgitlab.cs.uni-duesseldorf.de%2Fgeneral%2Fstups%2Fprob2-jupyter-kernel.git/master?filepath=notebooks try out the ProB Jupyter kernel in your browser] without installing it first.
Note that '''notebooks are not saved permanently in this online version!'''
To keep your notebooks, you ''must'' download them before closing the page.

=== ProB for Rodin ===
To install ProB for Rodin, first download a current version of Rodin (e.g., [https://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/3.9/ Rodin 3.9]). Inside Rodin, choose Help -> Install New Software and choose the pre-configured ProB update site.

More [[Tutorial Rodin First Step|detailed installation instructions and a brief tutorial]] are available.

* Nightly builds of ProB for Rodin 3 can be obtained from within Rodin by using the update site https://stups.hhu-hosting.de/rodin/prob1/nightly.

=== ProB2-UI (based on JavaFX)===

Version 1.3.0 of the new JavaFX-based [[ProB2-UI]] is available.
See the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history] for what's new.
You can use these stand-alone versions which come bundled with the right Java runtime environment:
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-1.3.0.exe Windows (x86_64) installer] - requires Windows 10 or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-aarch64-1.3.0.dmg macOS (Apple Silicon) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/ProB%202%20UI-x86_64-1.3.0.dmg macOS (Intel) application DMG] (not signed/notarized yet! [[#macOS issues|see below]]) - requires macOS 11 (Big Sur) or later
* [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui_1.3.0_amd64.deb Debian (x86_64) package]

You can also download a [https://stups.hhu-hosting.de/downloads/prob2/1.3.0/prob2-ui-1.3.0-multi.jar multi-platform jar], which works with Java 21 or later on all supported platforms (except macOS on arm64 - we recommend using the native macOS application instead).

Details about new features and improvements can be found in the [https://github.com/hhu-stups/prob2_ui/blob/develop/doc/prob2ui_release_history.md release history], along with download links for older versions.

Snapshot builds of the current ''development'' version of ProB2-UI (1.3.1-SNAPSHOT) are also available:
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-1.3.1.exe Windows installer snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-aarch64-1.3.1.dmg macOS (Apple Silicon) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/ProB%202%20UI-x86_64-1.3.1.dmg macOS (Intel) application DMG snapshot] (not signed/notarized! [[#macOS issues|see below]])
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui_1.3.1_amd64.deb Debian package snapshot]
* [https://stups.hhu-hosting.de/downloads/prob2/snapshot/prob2-ui-1.3.1-SNAPSHOT-multi.jar Multi-platform jar snapshot]

The source code for ProB2-UI is available at https://github.com/hhu-stups/prob2_ui and can be built by following [https://github.com/hhu-stups/prob2_ui#running-from-source these instructions].

The underlying [[ProB Java API]] of ProB2-UI (aka the ProB 2 kernel) is available to Java developers via [https://central.sonatype.com/artifact/de.hhu.stups/de.prob2.kernel Maven Central].
Its source code can be obtained from: https://github.com/hhu-stups/prob2_kernel.

==== macOS issues ====

When you run the macOS app for the first time, you might have to open the app ''twice'' for ProB 2 UI to start properly.
This should only happen once.

The ProB 2 UI macOS app releases are signed and notarized, so they should run without issues.
However, the multi-platform jar and snapshot app builds are ''not'' signed or notarized, so macOS will refuse to run them or say that the application is damaged.
As a workaround, right-click the app, select "Open", and confirm the security dialog.
If the dialog still doesn't give you an option to open the app, click "Cancel" and do the same thing again.


=== Editor Support ===

* There is a [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] extension for the VSCode editor. It integrates with [[Using the Command-Line Version of ProB|command line tool probcli]] to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness Checking#VSCode|well-definedness checking]].
** [https://stups.hhu-hosting.de/downloads/vscode_plugin Download for manual installation]

* A [https://github.com/bivab/prob.vim VIM plugin for ProB is available]. It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

* Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available; these do not use [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]].

== Java Requirements for B Parser ==
The B parser of ProB requires Java 8 or newer. Java 11, 17, etc. are also fully supported.
ProB 1.9.3 is the last version to support Java 7. ProB 1.5.0 is the last version to support Java 6.

You can install a Java Runtime Environment (JRE) from various sources, such as [https://adoptium.net/ Eclipse Adoptium], [https://www.azul.com/downloads/?version=java-8-lts&package=jre-fx Azul Zulu], or your system package manager.

Note: on some systems (macOS) you may have to install the full Java Development Kit (JDK), and not just the JRE, so that Java 8 becomes available to the command-line tools.
Type <code>java -version</code> to check which version is used by default for command-line tools; see also [http://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x this discussion on StackOverflow].
In case you have trouble starting the Java parser you can now set the <code>JAVA_PATH</code> preference of ProB to point to the <code>java</code> tool (or java.exe on Windows).

To check whether ProB can correctly use its Java parser you can type the following (using probcli.exe on Windows):
probcli -version -v
This will try and start the parser and obtain the parser version.
In case Java is not correctly installed you should get an error message.
If you see the error message
<tt>Unsupported major.minor version 52.0</tt>
this means you do not have Java 8 or newer installed. You can try setting the path to the correct java version by setting the JAVA_PATH preference as follows:
probcli -p JAVA_PATH path/to/java -version -v

== Tcl/Tk Requirements for ProB Tcl/Tk ==

ProB Tcl/Tk requires an installation of Tcl/Tk 8.5 or Tcl/Tk 8.6. The command-line tool probcli does not require this.

=== Tcl/Tk on macOS ===
Important note: macOS comes pre-installed with a version of Tcl/Tk which is broken.
This may result in the display of unreadable black windows or crashes in the standard file dialogs.
There are various options to install Tcl/Tk:
* with Homebrew using the [https://formulae.brew.sh/formula/tcl-tk tcl-tk formula]
* with [https://ports.macports.org/port/tcl/ MacPorts]
* use the [http://www.activestate.com/activetcl/downloads/ ActiveTcl version of Tcl/Tk]
You should probably start ProB using the <tt>StartProB.sh</tt> script: it will auto-detect Tcl/Tk versions and set the SP_TCL_DSO environment variable.
Below are more details:

==== Tcl/Tk from Homebrew or MacPorts ====

You can install a newer Tcl/Tk (e.g., 8.6.13) using [https://brew.sh Homebrew] or [https://www.macports.org MacPorts].
Note: In the earlier release 8.6.11 [https://bugs.python.org/issue44828 file open and file save dialogs will not work].
For Homebrew the command to install the[https://formulae.brew.sh/formula/tcl-tk tcl-tk formula] is:
<pre>
brew install tcl-tk
</pre>
The latest versions of Homebrew now install Tcl/Tk 9.0 which does not work yet with ProB.
In this case install
<pre>
brew install tcl-tk@8
</pre>

However, as the location of the libraries is not standard, you have to define the variable <tt>SP_TCL_DSO</tt>.
The <tt>StartProB.sh</tt> script should set SP_TCL_DSO automatically.
You can also define and export this variable yourself before starting ProB from the Terminal by typing this (you may have to adapt the link if you are using another version of Tcl/Tk):
<pre>
export SP_TCL_DSO=/opt/homebrew/Cellar/tcl-tk@8/8.6.16/lib/libtcl8.6.dylib
</pre>
If you have uses MacPorts the path is probably <tt>/opt/local/lib/libtcl.dylib</tt>.
You can also set the variable by adding <tt>-DSP_TCL_DSO=/usr/local/Cellar/tcl-tk/8.6.12/lib/libtcl8.6.dylib</tt> to the command starting ProB. You may also have to install <tt>tk-table</tt> package yourself (it is bundled with Active Tcl).

==== Active Tcl ====

The [http://www.activestate.com/activetcl/downloads/ the ActiveTcl version of Tcl/Tk] is automatically recognised by ProB and you do not have to set <tt>SP_TCL_DSO</tt>.

However, in Active Tcl/Tk 8.6 on macOS the double click in the "Operations View" or other views is not working correctly.
You have to hit the RETURN key in the "Operations View" or right-click on an operation and select "Perform ..." to execute an operation until this is fixed.
The older ersion [http://bugs.python.org/issue15853 8.5.12 has a bug related to copying text], see also [http://sourceforge.net/tracker/?func=detail&aid=3555211&group_id=12997&atid=112997_type here]).

==== Other Notes ====
Note: on macOS Catalina or later the Tcl/Tk menu bar is sometimes not working. Switching to another application and then back to ProB seems to solve the problem.
If you see the message "<tt>macOS 11 or later required !</tt>" in the terminal when launching <tt>prob</tt> you should re-install Tcl/Tk as described above.

=== Tcl/Tk on Windows ===
We currently provide two downloads of ProB, one for Tcl/Tk 8.6 (which we recommend)
and a version for Tcl/Tk 8.5.
You can use for example the [https://www.activestate.com/products/tcl/ ActiveTcl releases].
Note: For the 64 bit version of ProB for Windows, you have to install the 64 bit Tcl/Tk 8.5 version!
ProB 1.12 (currently available as nightly build) works with both Tcl/Tk 8.5 and 8.6.
You may have to point the environment variable SP_TCL_DSO to the correct DLL before starting ProB. For Tcl/Tk 8.5 this is typically
base-tcl8.5-thread-win32-x86_64.dll.
You can either go to System -> Settings -> Advanced -> Environment Variables
or use the setx command for this:
<pre>
setx SP_TCL_DSO C:\Tcl\bin\base-tcl8.5-thread-win32-x86_64.dll
</pre>

=== Tcl/Tk on Linux ===
On Linux you can typically install Tcl/Tk using <tt>sudo apt-get install tcl8.5 tk8.5</tt>.

On very recent Linux systems (such as Ubuntu 20.04) you may want to download (and compile) [https://www.tcl.tk/software/tcltk/downloadnow85.html Tcl/Tk 8.5] or use [https://ubuntu.pkgs.org/18.04/ubuntu-universe-amd64/tcl8.5_8.5.19-4_amd64.deb.html packages from earlier releases].

On Linux OpenSuse (12.3) you may have to perform the following for ProB to work:
ln -s /usr/lib/libtk8.5.so /usr/lib/libtk8.5.so.0
ln -s /usr/lib/libtcl8.5.so /usr/lib/libtcl8.5.so.0

Also, some of the feature require the table extension, which can be installed like this:
sudo apt install tk-table
Finally, support for .png ANIMATION_IMG declarations requires the Img package:
sudo apt install libtk-img

== Graphviz Requirements ==

If you wish to view various visualizations generated by ProB Tcl/Tk or probcli you will need [http://www.graphviz.org/ GraphViz].
ProB generates various graphs (state space, custom graph, machine hierarchy,...) as .dot files and then uses the command-line tool <tt>dot</tt> to layout the graph and convert it to PDF.

ProB Tcl/Tk can also use dot-file viewer such as the <tt>dotty</tt> program from GraphViz in Linux.
On macOS and Windows it is more difficult to obtain a good viewer application for dot files. VS Code with the [https://marketplace.visualstudio.com/items?itemName=tintinweb.graphviz-interactive-preview Graphviz Interactive Preview] extension is a candidate.
The commercial OmniGraffle macOS application can import .dot files. A free alternative on macOS may be [https://ports.macports.org/port/graphviz-gui/ graphviz-gui] by [https://www.macports.org MacPorts]. To install the application do this
* <tt>sudo port install graphviz-gui</tt>
The viewer can now be found in /Applications/MacPorts/Graphviz.app (you may have to set the ProB graphical viewer preference <tt>dot_viewer</tt> to this path).
If you do not manage to install a viewer, you should select Preferences -> Graphical Viewer -> PDF within ProB Tcl/Tk.
Indeed, many ProB commands work directly with the command-line tool <tt>dot</tt> which you can install on macOS with MacPorts like this:
* <tt>sudo port install graphviz</tt>
On Mac you can now install the latest version of Graphviz using [https://brew.sh HomeBrew]:

1. <tt>brew uninstall graphviz</tt>
2. <tt>brew install graphviz --with-gts</tt>
3. <tt>brew link --overwrite graphviz</tt>

Step 1. is optional; you only need to use it if you have a prior version of Graphviz installed.
Step3 links the binaries to /usr/local/bin.
This is probably better than using the [http://www.pixelglow.com/graphviz/ older version from Pixelglow].

You can also manually set the DOT (path_to_dot) preference if ProB cannot find the Graphviz dot binary you have installed.

== Short Release History ==

The full [[ProB_Release_History | ProB release history can be found here]].

'''2024-02-20'''
[[Download|ProB 1.13.0]] is available. Better Rodin theory support. Template strings. Unicode improvements. READ_JSON and other new external functions. VisB support for groups and "use" element. [[Monte_Carlo_Tree_Search_Game_Play|MCTS game play]].

'''2024-02-03'''
[[Download|ProB 1.12.2-fix1]] is available.

'''2023-08-10'''
[[Download|ProB 1.12.2]] is available. [[VisB#VisB_DEFINITIONS_2 |VisB]] improvements.

'''2023-04-04'''
[[Download|ProB 1.12.0]] is available. Call stack infos, performance improvements in parser and solver, new [[LTL_Model_Checking#Supported_Syntax |LTL]] operators, [[VisB#VisB_Additional_SVG_Objects|VisB]] improvements, reals/floats for [[Event-B_Theories|Rodin theories]].

'''2021-12-29'''
[[Download|ProB 1.11.1]] is available. Highlights: identifiers between backquotes, flexible JSON trace replay, DPLLT solving command, improvements to Z3 backend.

'''2021-10-06'''
[[Download|ProB 1.11.0]] is available. Highlights: improved support for infinite sets, operation caching (OPERATION_REUSE), faster LTL checking for safety formulas, more compact .prob files, VisB HTML export, constructive Z3 translation.

'''2020-12-15'''
[[Download|ProB 1.10.0]] is available. Highlights: well-definedness prover, REAL datatype, -lint comand for VSCode and Atom, improved unsat core and error messages.

'''2020-02-19'''
[[Download|ProB 1.9.3]] is available. Highlights: performance improvements, new external functions, performance monitoring.

'''2019-11-11'''
[[Download|ProB 1.9.2]] is available. Minor bugfix release.

'''2019-11-08'''
[[Download|ProB 1.9.1]] is available. Maintenance release.

'''2019-07-12'''
[[Download|ProB 1.9.0]] is available. Highlights: improved error feedback, improved Unicode support, regular expression library, memoization.

'''2018-10-01'''
[[Download|ProB 1.8.2]] is available. Highlights: improved error feedback, support [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel Jupyter kernel], first [[Alloy|support for Alloy models]].

'''2018-03-20'''
[[Download|ProB 1.8.0]] is available. Highlights: terminal colour support, performance improvements for displaying very large values, improved symmetry breaking and constraint solving.

'''2017-10-05'''
[[Download|ProB 1.7.1]] is available. Highlights: performance, non-deterministic assigned variables shown, Z improvements, export history to HTML.

'''2017-07-11'''
[[Download|ProB 1.7.0]] is available. Highlights: improved [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], improved XML/CSV data import and export, RULE DSL language, many improvements in constraint solver.

'''2016-10-20'''
[[Download|ProB 1.6.1]] is available. Highlights: [[Generating_Documents_with_ProB_and_Latex |Latex document generation]], LET and IF-THEN-ELSE for expressions and predicates, XML logging, XML data import, performance improvements.

'''2016-04-22'''
[[Download|ProB 1.6.0]] is available. Highlights: [[Tutorial_Directed_Model_Checking|directed model checking]], [[Using_ProB_with_Z3|Z3 available as backend]], B line comments and unicode symbols, improved error messages, performance improvements.

'''2015-02-19'''
[[Download|ProB 1.5.0]] is available. Highlights: improved random enumeration, MACE/SEM style static symmetry reduction for deferred set elements, [[State_Space_Coverage_Analyses|MC/DC coverage]] analysis for guards and invariants, [[TLC|improved TLC interface]], bug fixes and improvements including but not limited to the constraint solver.

'''2014-08-29'''
[[Download|ProB 1.4.1]], a small bugfix-only release is available. For a list of new features in 1.4.0 see below.

'''2014-08-18'''
[[Download|ProB 1.4.0]] is available. Highlights: CLP(FD)-based constraint solver enabled by default, kernel can handle more operations symbolically, [[TLC|integration of the TLC model checker]], bug fixes and performance improvements.

'''2013-03-04'''
[[Download|ProB 1.3.6]] is available. Highlights: improved constraint propagation for division, modulo, intervals, model checking progress bar, performance improvements, [[Using_ProB_with_KODKOD | improved Kodkod backend]] and use within REPL, and many more.

'''2012-10-08'''
[[Download|ProB 1.3.5]] is available. Highlights: support for external and recursive functions, optional Kodkod backend, [[TLA|TLA+ support]], performance improvements, pragmas, units inference, and many more.

'''2012-03-30'''
A first prototype of an online [[ProB_Logic_Calculator|ProB Logic Calculator]] is available.

'''2011-11-21'''
ProB 1.3.4 is available. Highlights: Evaluation View and Eval window, CSP assertion checking, improved editor, 64-bit version for Mac and Linux, performance improvements, and many more.

'''2011-02-10'''
ProB 1.3.3 and ProB for Rodin 2.3 is available. Highlights: improved performance, constrained-based deadlock checking, record detection, and many more.

'''2010-07-30'''
ProB 1.3.2 is available. Highlights: improved performance, constraint solving over integers (enable in Advanced Preferences), much improved Z support, and many more.

'''2009-12-07'''
ProB 1.3.1 is available. Highlights: new data-structure for large sets and relations (see FM 2009), multi-level validation for Event-B, improved constraint propagation for boolean connectives, and many more.

'''2009-03-20'''
ProB 1.3.0 is available for download. Highlights: New parser and integrated typechecker, install as AtelierB plugin, improved kernel with support for large sets/relations, improved CSP support, faster LTL model checker, Undo/Redo in text editor, graphical formula viewer, user definable custom animations with gifs.

Editors for ProB

2025-10-13T11:31:37Z

Jan Gruteser: /* Visual Studio Code */

== ProB Tcl/Tk Editor ==

ProB Tcl/Tk contains an editor in which syntax errors are displayed and which can be used to edit B, CSP, Z and TLA+ models.
The editor of Tcl/Tk, however, has a few limitations:
* it can become very slow with long or very long lines
* the syntax highlighting can become slow with very large files. Hence, syntax highlighting is automatically turned off in some circumstances (when more than 50,000 characters are encountered or when a line is longer than 500 characters).

It is possible to open the files in an external editor. You can setup the editor to be used by modifying the preference "Path to External Text Editor" in the "Advanced Preferences" list (available in the "Preferences" menu).
You can then use the command "Open FILE in external editor" in the "File" menu to open your main specification file with this editor. You can also use the command-key shortcut "Cmd-E" for this.

== Launching the editor in probcli ==

The [[Using_the_Command-Line_Version_of_ProB|probcli]] REPL (read-eval-print-loop) supports the command <tt>:e</tt> to open the current file in the external editor, as specified in the "EDITOR" preference.
You can set this preference using
probcli -repl -p EDITOR PATH
In case errors occurred with the last command, this will also try and move the cursor to the corresponding location in the file.

== External Editors ==

=== Visual Studio Code ===
There is a package called [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] available for the Visual Studio Code (VS Code) editor.
A <tt>.vsix</tt> file can be obtained [https://stups.hhu-hosting.de/downloads/vscode_plugin here] (for manual installation).
The plugin adds syntax highlighting and snippets for the specification languages B and Event-B to VS Code.
It integrates with probcli to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness_Checking#VSCode|well-definedness checking]]. There is also support for ProB's [[Rules-DSL|Rules-DSL]].

=== VIM ===

A [https://github.com/bivab/prob.vim VIM plugin for ProB is available].
It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

=== Atom ===

There is a package [https://atom.io/packages/language-b-eventb language-b-eventb] available for the Atom editor.
It adds syntax highlighting and snippets for the specification languages B and Event-B to Atom.
It integrates with probcli to obtain error markers for syntax and type errors.

With the Atom plugin you can now also visualize WD (well-definedness) issues in your B machines. See [https://youtu.be/td7CKFkAvaw this small demo video].

Note that Atom is no longer being updated as of [https://github.blog/2022-06-08-sunsetting-atom/ December 2022].

=== BBEdit ===

Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available.

=== Emacs ===

A package [[File:b-mode.el.zip]] is available.

Editors for ProB

2025-10-13T11:31:07Z

Jan Gruteser: /* External Editors */

== ProB Tcl/Tk Editor ==

ProB Tcl/Tk contains an editor in which syntax errors are displayed and which can be used to edit B, CSP, Z and TLA+ models.
The editor of Tcl/Tk, however, has a few limitations:
* it can become very slow with long or very long lines
* the syntax highlighting can become slow with very large files. Hence, syntax highlighting is automatically turned off in some circumstances (when more than 50,000 characters are encountered or when a line is longer than 500 characters).

It is possible to open the files in an external editor. You can setup the editor to be used by modifying the preference "Path to External Text Editor" in the "Advanced Preferences" list (available in the "Preferences" menu).
You can then use the command "Open FILE in external editor" in the "File" menu to open your main specification file with this editor. You can also use the command-key shortcut "Cmd-E" for this.

== Launching the editor in probcli ==

The [[Using_the_Command-Line_Version_of_ProB|probcli]] REPL (read-eval-print-loop) supports the command <tt>:e</tt> to open the current file in the external editor, as specified in the "EDITOR" preference.
You can set this preference using
probcli -repl -p EDITOR PATH
In case errors occurred with the last command, this will also try and move the cursor to the corresponding location in the file.

== External Editors ==

=== Visual Studio Code ===
There is a package called [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] available for the Visual Studio Code (VS Code) editor.
A <tt>.vsix</tt> file can be obtained [https://stups.hhu-hosting.de/downloads/vscode_plugin here] (for manual installation).
The plugin adds syntax highlighting and snippets for the specification languages B and Event-B to VS Code.
It integrates with probcli to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness_Checking#VSCode|well-definedness checking]]. There is also support for ProB's [[Rules-DSL|B Rules-DSL]].

=== VIM ===

A [https://github.com/bivab/prob.vim VIM plugin for ProB is available].
It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

=== Atom ===

There is a package [https://atom.io/packages/language-b-eventb language-b-eventb] available for the Atom editor.
It adds syntax highlighting and snippets for the specification languages B and Event-B to Atom.
It integrates with probcli to obtain error markers for syntax and type errors.

With the Atom plugin you can now also visualize WD (well-definedness) issues in your B machines. See [https://youtu.be/td7CKFkAvaw this small demo video].

Note that Atom is no longer being updated as of [https://github.blog/2022-06-08-sunsetting-atom/ December 2022].

=== BBEdit ===

Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available.

=== Emacs ===

A package [[File:b-mode.el.zip]] is available.

Editors for ProB

2025-10-13T11:29:51Z

Jan Gruteser: /* VSCode */

== ProB Tcl/Tk Editor ==

ProB Tcl/Tk contains an editor in which syntax errors are displayed and which can be used to edit B, CSP, Z and TLA+ models.
The editor of Tcl/Tk, however, has a few limitations:
* it can become very slow with long or very long lines
* the syntax highlighting can become slow with very large files. Hence, syntax highlighting is automatically turned off in some circumstances (when more than 50,000 characters are encountered or when a line is longer than 500 characters).

It is possible to open the files in an external editor. You can setup the editor to be used by modifying the preference "Path to External Text Editor" in the "Advanced Preferences" list (available in the "Preferences" menu).
You can then use the command "Open FILE in external editor" in the "File" menu to open your main specification file with this editor. You can also use the command-key shortcut "Cmd-E" for this.

== Launching the editor in probcli ==

The [[Using_the_Command-Line_Version_of_ProB|probcli]] REPL (read-eval-print-loop) supports the command <tt>:e</tt> to open the current file in the external editor, as specified in the "EDITOR" preference.
You can set this preference using
probcli -repl -p EDITOR PATH
In case errors occurred with the last command, this will also try and move the cursor to the corresponding location in the file.

== External Editors ==

=== VIM ===

A [https://github.com/bivab/prob.vim VIM plugin for ProB is available].
It shows a quick fix list of parse and type errors for classical B machines (.mch) using the [[Using_the_Command-Line_Version_of_ProB|command line tool probcli]]. VIM has builtin syntax highlighting support for [https://github.com/vim/vim/blob/master/runtime/syntax/b.vim B].

=== Visual Studio Code ===
There is a package called [https://github.com/hhu-stups/b-language-extension B/ProB Language Support] available for the Visual Studio Code (VS Code) editor.
A <tt>.vsix</tt> file can be obtained [https://stups.hhu-hosting.de/downloads/vscode_plugin here] (for manual installation).
The plugin adds syntax highlighting and snippets for the specification languages B and Event-B to VS Code.
It integrates with probcli to obtain error markers for syntax and type errors. It can also be used for [[Well-Definedness_Checking#VSCode|well-definedness checking]]. There is also support for ProB's [[Rules-DSL|B Rules-DSL]].

=== Atom ===

There is a package [https://atom.io/packages/language-b-eventb language-b-eventb] available for the Atom editor.
It adds syntax highlighting and snippets for the specification languages B and Event-B to Atom.
It integrates with probcli to obtain error markers for syntax and type errors.

With the Atom plugin you can now also visualize WD (well-definedness) issues in your B machines. See [https://youtu.be/td7CKFkAvaw this small demo video].

Note that Atom is no longer being updated as of [https://github.blog/2022-06-08-sunsetting-atom/ December 2022].

=== BBEdit ===

Some [https://github.com/leuschel/bbedit-prob BBedit Language modules for B, TLA+, CSP and Prolog] are available.

=== Emacs ===

A package [[File:b-mode.el.zip]] is available.

Using ProB with Atelier B

2025-10-12T15:44:28Z

Jan Gruteser: /* Atelier B Plugin */

[[Category:User Manual]]

== Atelier B Plugin ==

ProB Tcl/Tk can be installed as a plugin for Atelier B, so that ProB can be launched directly from within [http://www.atelierb.eu/ Atelier B] projects.
With this you can animate and model check B machines directly from within the IDE of Atelier-B.

The easiest is to perform the menu command "Install AtelierB 4 Plugin..." in the Help menu of ProB Tcl/Tk. This will create a file called <tt>probtclk.etool</tt> in an extensions folder next to Atelier B's bbin folder. The extensions folder is created if necessary.

Note: as the layout of Atelier-B's directories has changed, you need to use ProB 1.12.0 or newer for Atelier-B 4.7.1 or newer on macOS.
You can also create the above file yourself.

Here is a typical <tt>probtclk.etool</tt> file (where PathToProB depends on your location of the ProB installation folder containing the prob and probcli binaries):
<pre>
<externalTool category="component" name="ProBTclTk" label="&Animate with ProB (Tcl/Tk)">
<toolParameter name="editor" type="tool" configure="yes"
default="PathToProB/StartProB.sh" />
<command>${editor}</command>
<param>${componentPath}</param>
</externalTool>
</pre>

Note, you can also [[ProB2-UI]] within Atelier-B by creating a suitable file <tt>prob2ui.etool</tt> in this extensions folder. Here is a typical file for macOS; the path needs to be adapted for your location and operating system (we plan to provide an installer within ProB2-UI):
<pre>
<externalTool category="component" name="ProB2UI" label="&Animate with ProB2-UI">
<toolParameter name="editor" type="tool" configure="yes"
default="/Applications/Development/ProB/ProB 2 UI.app/Contents/MacOS/ProB 2 UI" />
<command>${editor}</command>
<param>--machine-file</param>
<param>${componentPath}</param>
</externalTool>
</pre>

After installing the plugins you can launch ProB for selected B machines by right-clicking on a B machine within Atelier B:

[[File:ProB_AtelierB_StartProB_Menu.png|300px|center]]

== ProB as Atelier B Prover==
Atelier B also enables to use ProB as a prover/disprover in the interactive proof window.
For this you need to set the ProB_Path resource to point to probcli (command-line version of ProB). To do this you need to add the following line to the resource file of your project (replacing PATH by the the path on your machine to probcli):
ATB*PR*ProB_Path:PATH/probcli

[[File:ProB_AtelierB_Resource.png|600px|center]]

Then you can type, e.g., the command <tt>prob(1)</tt>in the interactive proof window.

[[File:ProB_AtelierB_Proof.png|600px|center]]

Two commands are provided within Atelier-B:
* <tt>prob(n)</tt> tries to prove the goal with the selected hypotheses (selected using rp.n as is done for th e pp command of Atelier-B)
* <tt>prob(n|t)</tt> is similar but also limits the execution time of ProB to t seconds

Atelier-B will call probcli using the commands <tt>-cbc_assertions_tautology_proof</tt> and <tt>-cbc_result_file</tt> after having encoded the proof obligation into the ASSERTIONS clause of a generated B machine.

The generated machine typically has the form:
<pre>
MACHINE probNr
SETS ...
CONSTANTS ...
PROPERTIES
<< ALL HYPOTHESES >>
ASSERTIONS
( <<SELECTED HYPOTHESES >>
=>
<< PROOF GOAL >>
)
END
</pre>

== Using the Atelier B Provers inside ProB ==

In the REPL of probcli you can [[Proving_Theorems_in_the_ProB_REPL#Calling_Atelier-B_Provers | call the provers ML and PP of Atelier-B]].

== Differences with Atelier B ==

As of version 1.3, ProB contains a much improved parser which tries be compliant with
Atelier B but provides extra features.

=== Extra Features of ProB ===

* Identifiers: ProB also allows identifiers consisting of a single letter. ProB also accepts enumerated set elements to be used as identifiers. Arbitrary identifiers can be used in backquotes (e..g, <tt>`id-1*`</tt>)

* Lexing: The Atelier-B parser (<tt>bcomp</tt>) reports a lexical error (<tt>illegal token |-</tt>) if the vertical bar (|) of a lambda abstraction is followed directly by the minus sign.

* Typing:
** ProB makes use of a unification-based type inference algorithm. As such, typing information can not only flow from left-to-right inside a formula, but also from right-to-left. For example, it is sufficient to type <tt>xx<:yy & yy<:NAT</tt> instead of typing both <tt>xx</tt> and <tt>yy</tt> in ProB.
** Similar to Rodin, ProB extracts typing information from all predicates. As such, it is sufficient to write <tt>xx/:{1,2}</tt> to assign a type to <tt>xx</tt>.
** the fields of records are normalized (sorted); hence the predicate <tt>rec(a:0,b:1) = rec(b:y,a:x)</tt> is correctly typed for ProB.
** As of version 1.12.1 you can apply prj1 and prj2 without providing the type arguments. For example, you can write <tt>prj2(prj1(1|->2|->3))</tt> instead of <tt>prj2(INTEGER,INTEGER)(prj1(INTEGER*INTEGER,INTEGER)(1|->2|->3))</tt>.

* DEFINITIONS: the definitions and its arguments are checked by ProB. We believe this to be an important feature for a formal method language. However, as such, every DEFINITION must be either a predicate, an expression or a substitution. You '''cannot''' use, for example, lists of identifiers as a definition. Also, for the moment, the arguments to DEFINITIONS have to be expressions. Finally, when replacing DEFINITIONS the associativity is not changed. E.g., with <tt>PLUS(x,y) == x+y</tt>, the expression <tt>PLUS(2,3)*10</tt> will evaluate to 50 (and not to 32 as with Atelier-B).

* for a LET substitution, Atelier-B does not allow introduced identifiers to be used in the right-hand side of equations; ProB allows <tt>LET x,y BE x=2 & y=x*x IN ... END</tt> but only if the preference <tt>ALLOW_COMPLEX_LETS</tt> is set to TRUE.

* ProB allows WHILE loops and sequential composition in abstract machines

* ProB now allows the IF-THEN-ELSE for expressions and predicates: <tt>IF x<0 THEN -x ELSE x END</tt>

* ProB now allows LET constructs for expressions and predicates

* ProB allows <tt>btrue</tt> and <tt>bfalse</tt> as predicates.

* ProB allows to use the Event-B relation operators <tt><<-></tt>, <tt><->></tt>, <tt><<->></tt>

* ProB allows escape codes (\n, \', \", see above) and supports UTF-8 characters in strings, and ProB allows multi-line string literals written using three apostrophes (<tt>"''''string''''"</tt>) as well as template strings using three backquotes (e.g., <tt>```1+2=${1+2}```</tt>)

* ProB allows WHILE loops and sequential composition in abstract machines

* Some of the sequence operators can be applied to strings (unless you set the preference STRING_AS_SEQUENCE to FALSE): <tt>size</tt>, <tt>rev</tt>, <tt>^</tt>, <tt>conc</tt>

* As of version 1.12.1 you can write Event-B style set comprehensions with an extra expression like {x•x:1..10|x*x}. You have to use the middle dot, the bullet (•) or a Unicode dot for this, though.

* ProB comes with several libraries of [[External_Functions | external functions]] for string manipulations, mathematical functions, Hilbert's choice operator, etc.

=== Differences ===
* for ProB the order of fields in a record is not relevant (internally the fields are sorted), Atelier-B reports a type error if the order of the name of the fields changes

* [[Well-Definedness_Checking|Well-definedness]]: ProB will try to check if your predicates are well-defined during animation or model checking, but there is currently no guarantee that all well-definedness errors will be detected. To be on the safe side, you should ensure that your formulas are well-defined according to the left-to-right definition of well-definedness employed in Rodin for Event-B. ProB now has a [[Well-Definedness_Checking|static checker for well-definedness]] which you can use for this. Note, however, that ProB may re-order conjuncts if this improves well-definedness. For example, for <tt>x:0..3 & y=10/x & x /=0</tt> ProB will not report an error as the conjunct <tt>x/=0</tt> is processed before the division. Indeed, while this predicate is not well-defined according to Rodin's left-to-right rule, it is well-defined according to the more liberal commutative definition of well-definedness.

== Reflexive Closure ==

In version 1.8.0 (March 2018) ProB changed the definition of the transitive and reflexive closure operator of B.
PorB now uses to the mathematical definition:
<pre> closure(X) = id(TypeOfX) \/ closure1(X)
</pre>
This means that <tt>closure({1|->2}) </tt>is now infinite and contains for example the pair <tt>3|->3</tt>. The same holds for <tt> iterate({1|->2},0)</tt>.
The previous definition was closure(X) = id(ran(X)\/dom(X)) \/ closure1(X) and
the definition in Atelier-B was closure(X) = id(dom(X)) \/ closure1(X).
However, both were not compatible with the following law in the B-Book on page 169:
<pre> r[a] <: a => closure(r)[a]=a
</pre>
Take r = {1|->2}, then r[{3}] <: {3}.
So, according to the law we have: <tt> closure(r)[{3}] = {3}</tt>.

In the next version of Atelier-B in 2025 closure(R) will be defined as "the smallest relation
that contains R that is transitive and reflexive."
This corresponds to ProB's definition prior to version 1.8.0 closure(X) = id(ran(X)\/dom(X)) \/ closure1(X) and is thus different to the B-Book.
ProB may provide a preference in the next release to allow the user to choose between the two interpretations.

=== Limitations ===

* Parsing: ProB will require parentheses around the comma, the relational composition, and parallel product operators. For example, you cannot write <tt>r2=rel;rel</tt>. You need to write <tt>r2=(rel;rel)</tt>. This allows ProB to distinguish the relational composition from the sequential composition (or other uses of the semicolon). You also generally need to put BEGIN and END around the sequential composition operator, e.g., <tt>Op = BEGIN x:=1;y:=2 END</tt>.
* Similarly, tuples without parentheses are not supported; write (a,b,c) instead of a,b,c

* Unsupported Operators:
** Trees and binary trees: some tree operators (mirror, infix) are not supported by ProB. The tree operators may disappear in future version of Atelier B and may also disappear from ProB.
** <tt>VALUES</tt>: This clause of the <tt>IMPLEMENTATION</tt> machines is not yet fully supported;

* There are also some general limitations wrt refinements. See [[Current Limitations#Multiple Machines and Refinements]] for more details.

Template:ProBSourceCode

2025-10-08T12:20:40Z

Jan Gruteser:

The kernel of ProB is written in Prolog and you can download the latest Prolog sourcecode snapshot from: https://stups.hhu-hosting.de/downloads/prob/source/

You may also wish to obtain related Java sources:
* The source code for the ProB parsers (B, LTL, ...) can be obtained from: [https://github.com/hhu-stups/probparsers https://github.com/hhu-stups/probparsers].
* The ProB2-Java-API (also known as ProB2) source code can be obtained from: [https://github.com/hhu-stups/prob2_kernel https://github.com/hhu-stups/prob2_kernel].
* The ProB2-Java-FX UI source code can be obtained from: [https://github.com/hhu-stups/prob2_ui https://github.com/hhu-stups/prob2_ui].
* The B to Java value translator can also be useful and is a separate project: [https://github.com/hhu-stups/value-translator https://github.com/hhu-stups/value-translator].
* The Plugin for Rodin is also a separate project: [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob_rodin_plugin https://gitlab.cs.uni-duesseldorf.de/general/stups/prob_rodin_plugin].
* The Alloy to B translator is here: [https://github.com/hhu-stups/alloy2b https://github.com/hhu-stups/alloy2b].
* The TLC4B B to TLA+ translator is here: [https://gitlab.cs.uni-duesseldorf.de/general/stups/tlc4b https://gitlab.cs.uni-duesseldorf.de/general/stups/tlc4b].
* The TLA2B TLA+ to B translator is here: [https://gitlab.cs.uni-duesseldorf.de/general/stups/tla2bAST https://gitlab.cs.uni-duesseldorf.de/general/stups/tla2bAST].

Other languages

2025-10-06T16:34:17Z

Jan Gruteser: XTL VisB

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symbolic transitions using the predicate <tt>symb_trans/3</tt>. Such transitions are only available via the execute by predicate dialog and are intended for transitions that require user input or have side effects.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

Further recognised predicates are:
* <tt>prob_pragma_string(DefinionName,Value)</tt>: a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt>: number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

=== Using VisB in XTL mode ===

Since ProB 1.15.0, it is possible to use [[VisB|VisB]] with XTL specifications. For this, a B (!) definition file (<tt>.def</tt>) must be used, as with B models, which enables the use of VisB DEFINITIONS. The B definition file can the be linked to the specification using
prob_pragma_string('VISB_DEFINITIONS_FILE',PathToFile).
(or via the VisB view in ProB2-UI).
To access the value of state properties in the current state, e.g. for VisB updates, the external function <tt>STATE_PROPERTY(NameOfProp)</tt> can be used, where <tt>NameOfProp</tt> corresponds to a property of the special style <tt>'='(Name,Value)</tt> in <tt>prop/2</tt>.

Note that for event predicates the parameter values must be wrapped in <tt>STRING_TO_TERM</tt>, e.g.
rec(event: "set_button", predicate: "buttonState = STRING_TO_TERM(\"on\")")

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Team

2025-10-06T16:22:09Z

Jan Gruteser: Links gefixt

ProB is based on research and implemention effort by:
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/team/leuschel Michael Leuschel],
* Michael Butler,
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/team/bendisposto Jens Bendisposto],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Ivaylo Dobrikov],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Dominik Hansen],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Philipp Körner],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Sebastian Krings],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Lukas Ladenberger],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni David Schneider],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Joshua Schmidt],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Daniel Plagge],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Marc Fontaine],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Fabian Fritz],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/alumni Corina Spermann],
* Joy Clark,
* David Geleßus,
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/team/gruteser Jan Gruteser],
* [https://www.cs.hhu.de/lehrstuehle-und-arbeitsgruppen/softwaretechnik-und-programmiersprachen/unser-team/team/vu Fabian Vu],
* Antonia Pütz,
* Sherin Schneider,
* Yumiko Takahashi,
* Miles Vella,
* Michelle Werth,
* Michael Jastram,
* Philip Hoefges,
* Edward Turner,
* Dennis Winter,
* Sonja Holl,
* Jens Krüger,
* Michael Birkhoff,
* Carla Ferreira,
* Stéphane Lo Presti,
* Leonid Mikhailov,
* Laksono Adhianto, ...

Part of the research and development was conducted within various research projects, such as the EPSRC funded projects ABCD and iMoc, the EU funded projects [http://rodin.cs.ncl.ac.uk/ Rodin], [http://www.deploy-project.eu/ Deploy] and [http://www.advance-ict.eu/ Advance] as well as the [http://www.dfg.de/ DFG] projects [http://www.gepavas.de/ Gepavas], Gepavas II and IVOIRE.

Other languages

2025-10-06T08:13:07Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symbolic transitions using the predicate <tt>symb_trans/3</tt>. Such transitions are only available via the execute by predicate dialog and are intended for transitions that require user input or have side effects.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

Further recognised predicates are:
* <tt>prob_pragma_string(DefinionName,Value)</tt>: a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt>: number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T08:12:32Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symbolic transitions using the predicate <tt>symb_trans/3</tt>. Such transitions are only available via the execute by predicate dialog and are intended for transitions that require user input or have side effects.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

Further recognised predicates are:
* <tt>prob_pragma_string(DefinionName,Value)</tt> a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt> number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T07:46:58Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symbolic transitions using the predicate <tt>symb_trans/3</tt>. Such transitions are only available via the execute by predicate dialog and are intended for transitions that require user input or have side effects.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

* <tt>prob_pragma_string(DefinionName,Value)</tt> a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt> number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T07:45:07Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

As of ProB 1.15.0, it is possible to specify symoblic transitions using the predicate <tt>symb_trans/3</tt>.
<tt>symb_trans_enabled(Name,State)</tt> can be optionally used to mark states in which a symbolic transition is potentially enabled (not guaranteed).

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).
For symbolic transitions it is required to provide parameter names.

* <tt>prob_pragma_string(DefinionName,Value)</tt> a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt> number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T07:41:05Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).
Static properties, such as parameter names, can be provided using <tt>trans_prop(TransName,Prop)</tt>, e.g.
trans_prop(set_button,param_names(['ButtonState'])).

* <tt>prob_pragma_string(DefinionName,Value)</tt> a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt> number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T07:38:21Z

Jan Gruteser: /* All recognised Prolog Predicates */

[[Category:User Manual]]
[[Category:Developer Manual]]

== XTL Prolog Format for Transition Systems ==

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

=== All recognised Prolog Predicates ===

To provide dynamic transition properties, such as descriptions, the two predicates <tt>trans/4</tt> and <tt>start/2</tt> can be used, where the last parameter is a list of properties, e.g.
trans(toggle_button,button(A),button(B),[description(toggle_from_to(A,B))]) :- toggle(A,B).

* <tt>prob_pragma_string(DefinionName,Value)</tt> a way to mimic B DEFINITION Strings in XTL mode
* <tt>nr_state_properties(Nr)</tt> number of state properties displayed in the state view
* <tt>heuristic_function_active</tt>
* <tt>heuristic_function_result(State,Res)</tt>

The following can be used to set up an animation image matrix with corresponding actions:
* <tt>animation_image(Nr,Path)</tt>
* <tt>animation_function_result(State,List)</tt> where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* <tt>animation_image_right_click_transition(Row,Col,TransitionTemplate)</tt>
* <tt>animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)</tt>

An example for visualisation can be found at [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]].

=== Examples ===

The following predicates specify a simple button:

start(button(on)).
trans(toggle_button,button(X),button(Y)) :- toggle(X,Y).
trans(set_button(X),_,button(X)) :- X=on ; X=off.
prop(button(X),'='(button,X)).
toggle(on,off).
toggle(off,on).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

Other languages

2025-10-06T07:29:37Z

Jan Gruteser: /* Examples */

Other languages

2025-10-06T07:27:35Z

Jan Gruteser: /* XTL Prolog Format for Transition Systems */

Other languages

2025-10-06T07:25:49Z

Jan Gruteser: /* All recognised Prolog predicates */

Other languages

2025-10-06T07:25:06Z

Jan Gruteser: /* XTL Prolog Format for Transition Systems */

Other languages

2025-10-06T07:22:49Z

Jan Gruteser: /* XTL Prolog Format for Transition Systems */

[[Category:User Manual]]
[[Category:Developer Manual]]

= XTL Prolog Format for Transition Systems =

You can also use ProB to animate and model check other specification languages by writing your own Prolog interpreter. To do this you should create a Prolog file with the .P extension and which defines three predicates:
* <tt>trans/3</tt>: this predicate should compute for every state (second argument), the outgoing transitions (first argument), and the resulting new states (third argument)
* <tt>prop/2</tt>: this predicate should compute the properties for the states of your system
* <tt>start/1</tt>: this defines the initial states of your system

For example, the following defines a system with two states (a and b) and two transitions (lock and unlock):

start(a).
trans(lock,a,b).
trans(unlock,b,a).
prop(X,X).

These Prolog files can be loaded with ProB's open command (be sure to use the .P extension and to either choose "All files" or "Other Formalisms" in the file filtering menu).

Another simple example for a very basic process algebra is as follows:

% start(PossibleInitialState)
start(choice(pref(a,stop),intl(pref(b,pref(c,stop)),pref(d,stop)))).

% trans(Event, StateBefore, StateAfter)
trans(A,pref(A,P),P). % action prefix
trans(A,intl(P,Q),intl(P2,Q)) :- trans(A,P,P2). % interleave
trans(A,intl(P,Q),intl(P,Q2)) :- trans(A,Q,Q2).
trans(A,par(P,Q),par(P2,Q2)) :- trans(A,P,P2), trans(A,Q,Q2). % parallel composition
trans(A,choice(P,Q),P2) :- trans(A,P,P2). % choice
trans(A,choice(P,Q),Q2) :- trans(A,Q,Q2).

% prop(State, PropertyOfState)
prop(pref(A,P),prefix).
prop(intl(P,Q),interleave).
prop(A,A).

If you have a working interpreter, you can also contact the ProB developers in order for your interpreter to be included in the standard ProB distribution (in the style of the CSP-M or Promela interpreters).
With this you can add syntax highlighting, error highlighting in the source code, highlighting during animation, support for new LTL properties,...

Another, slightly more elaborate example, is the following interpreter for regular expressions:

/* A simple animator for regular expressions */

start('|'('.'('*'(a),b) , '.'('*'(b),a))).

trans(_,[],_) :- !,fail.
trans(X,X,[]) :- atomic(X),!.
trans(X,'|'(R1,R2),R) :-
trans(X,R1,R) ; trans(X,R2,R).
trans(X,'.'(R1,B),R) :- trans(X,R1,R2),
gen_concat(R2,B,R).
trans(X,'?'(R1),R) :-
trans(X,R1,R) ; (X=epsilon,R=[]).
trans(epsilon,'*'(_R1),[]).
trans(X,'*'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).
trans(X,'+'(R1),R) :-
trans(X,R1,R2),
gen_concat(R2,'*'(R1),R).

gen_concat(R1,R2,R) :-
(R1=[] -> R = R2 ; R = '.'(R1,R2)).

prop(X,X).

Finally, a more complex example is [[Rush_Hour_XTL|an encoding of the Rush Hour puzzle]] which also includes a graphical visualisation (using the <tt>animation_function_result</tt> predicate recognised by ProB as of version 1.4.0-rc3).

== Other recognised Prolog predicates ==

The following can be used to set up an animation image matrix with corresponding actions:
* animation_image(Nr,Path)
* animation_function_result(State,List) where List is a list of terms of the form ((Row,Col),Img) where Img is either a declared animation_image number or another Prolog term
* animation_image_right_click_transition(Row,Col,TransitionTemplate)
* animation_image_click_transition(FromRow,FromCol,ToRow,ToCol,ListOfTransitionTemplates,ImageNr)

== Promela ==

Version 1.2.7 of ProB (July 2008) was able to open Promela files. This mode provided source-level highlighting during animation. The main purpose was to debug and animate Promela specifications in a user-friendly way. We do not plan to compete in terms of model checking speed with Spin (Spin compiles Promela to C code, ProB uses a Prolog interpreter). To animate a Promela model, simply open the file with the .pml or .prom extension with the "File->Open..." command. You will have to choose "Other Formalisms" or "All Files" in the filter pop-up-menu to be able to select the file.

This direct support of Promela files has been discontinued, but the Promela interpreter is still available as an XTL Prolog specification (see above) and can thus be used to animate Promela specifications with ProB.

ProB's Prolog Datastructures

2025-07-09T08:02:35Z

Jan Gruteser: /* Data Values */

== Data Values ==

Integer value:
int(Nr)
where Nr is an integer

Booleans:
pred_true
pred_false

Enumerated or deferred set elements:
fd(Nr,Type)
where Nr is an integer >= 1 and Type is an atom representing the type of enumerated/deferred set

Strings
string(S)
where S is an atom

Pairs/couples
(Val1,Val2)
where Val1 and Val2 are values

Records
rec(Fields)
where Fields is a list of terms:
field(Name,Val)
where Name is atom representing the field name and Val is a value.

The fields are sorted by name!

Sets
Here is an overview of the set representations:
[]
[Val|Set]
avl_set(AVL)
closure(P,T,B)
global_set(GS)
freetype(T)

The empty set is encoded as the empty list.
[]
This represents a set containing at least the value Val and the rest:
[Val|Set]
Note that Set can in principle be any other form (e.g., avl_set(.)).
The predicate <tt>expand_custom_set_to_list</tt> can be used to transform a set into a form using only the empty list and the <tt>[.|.]</tt> functor.

The next are called custom explicit sets, they always represent a fully known set.

A set can be represented by a non-empty AVL tree:
avl_set(AVL)

Given a list of parameter identifiers, a list of types and a predicate AST B, we can represent the set {P| P:T & B} as follows:
closure(P,T,B)

There are custom representations for complete types, these may be phased out in the future and replaced by the closure(.,.,.) representation:
global_set(GS)
freetype(T)

Freetype values
freeval(Id,Case,Value)

Constructor for denoting special values (undefined values, experimental support for reals,..)
term(Term)

<tt>term(undefined)</tt> is used for uninitialised variables (e.g., when using the B <tt>VAR</tt> construct).
<tt>term(floating(Nr))</tt> is currently used for floating numbers, but this will probably change in the future.

== AST (Abstract Syntax Tree) ==

An AST node has the form:
b(Expr,Type,Infos)

Expr generally has the form Functor(AST1,...,ASTk). Below we list possible cases.
The predicate <tt>syntaxelement</tt> in bsyntaxtree.pl lists all allowed forms of Expr.
Type is either <tt>pred</tt> for predicates, <tt>subst</tt> for substitutions or the value type for expressions, see below.
Infos contains information about the AST node and is explained next.

=== Information list ===
Infos should be a ground list of informations.
Some important information fields are:
contains_wd_condition
used_ids(Ids)
nodeid(PositionInfo)
refers_to_old_state(References)

=== AST types ===
Possible types are:
pred
subst
integer
real
boolean
string
global(G)
couple(Type1,Type2)
record(FieldTypes)
set(Type)
seq(Type)
freetype(F)
where FieldTypes is a list containing:
field(Name,Type)

The <tt>real</tt> type has been added in version 1.10 of ProB.

=== Operators without arguments ===

boolean_false
boolean_true
bool_set
...

=== Unary operators ===

card(AST)
domain(AST)
front(AST)
...

=== Binary operators ===

cartesian_product(AST1,AST2)
composition(AST1,AST2)
concat(AST1,AST2)
conjunct(AST1,AST2)
...

=== Special operators ===

general_sum(Ids,AST,AST)
general_product(Ids,AST,AST)
lambda(Ids,AST,AST)
quantified_union(Ids,AST,AST)
quantified_intersection(Ids,AST,AST)
set_extension(ListOfASTs)
sequence_extension(ListOfASTs)
...

LTL Model Checking

2025-06-13T16:10:21Z

Jan Gruteser:

[[Category:User Manual]]__NOTOC__
ProB provides support for LTL (linear temporal logic) model checking. For an introduction to LTL see the [http://en.wikipedia.org/wiki/Linear_temporal_logic Wikipedia Article].

To use this feature, select "Check LTL/CTL Assertions" in the "Verify" menu. The feature can also be accessed by the key combination "Ctrl+L" under Windows and Linux, and by the key combination "Cmd+L" under MacOS. The following window appears:

[[File:ltlviewer.png]]

All LTL formulas that are given in the "DEFINITIONS" section of a B machine are displayed in the list box of the LTL/CTL Assertions Viewer. For CSP-M specifications all LTL formulas given in the LTL pragmas of the loaded CSP-M file will be shown in the viewer. (For more detailed information of how LTL/CTL assertions can be stored into B and CSP-M models see Section '''Storing LTL Assertions into a Model''').

A new LTL formula can be entered in the entry below the list box. (We explain the supported syntax below). The typed formula can then be either added to the list box by clicking the "Add" button or directly checked by clicking the "Check" button. Before doing that assure whether you are in the proper frame ("Add LTL Formula") of the bottom part of the LTL viewer.

The LTL model checker can be started for an LTL formula by performing a double-click on the respective formula or typing "Enter" after selecting the respective formula. Each LTL formula in the list box has on the left hand side a symbol that indicates what is the status of the respective formula. An LTL formula can have one of the following statuses (status symbols may differ under different operating systems):

* ? – The formula has not been checked yet.
* ✔ – The formula is true for all valid paths.
* ✘ – A counterexample for the formula has been found, i.e. there is a path that violates the formula. In case the formula has been just checked on the model the animator is navigated to the last state of the counterexample. The full path can then be seen in the history. The counterexample can be also obtained by the dotty-viewer after a second double-click on the formula in the assertions’ viewer.
* ⌚ – The formula is currently checked.
* ! – The formula check has been aborted by an unexpected error occurrence.
* ∞ – The formula check is incomplete, i.e. no counterexample was found so far, but the absence of a path that does not satisfy the formula can not be guaranteed because the state space was not fully explored. A new check can be started by a double-click.

All formulas can be checked by "Assertions -> Check All Assertions" in the menu bar. All formulas will be then checked from top to bottom in the list box.

Additionally, the viewer provides a context menu for the list box elements. The context menu can be popped-up by a right-mouse-click on a formula from the list box, and it performs a set of actions available to be performed on the currently selected formula (see Figure below).

[[File:ltlviewercontext.png]]

The old LTL and CTL dialogs can be accessed from "OldLtlViewers" in the menu bar.

==LTL Preferences==

There is a set of options coming with the LTL model checker. In this section we give a brief overview of the preferences. The LTL preferences can be viewed by selecting "LTL Preferences" in the "Preferences" menu of the LTL/CTL Assertions Viewer.

'''Exploring new states''' 
The LTL model checker searches in the already explored search space of the model. If a state is encountered that has not been explored before, the state will be explored (i.e. all transitions to successor states are computed). The number of how often this can happen is limited by the field "Max no. of new states".
Depending on the LTL formula, a partially explored state space can be sufficient to find a counterexample or to assure the absence of a counterexample. If there's still the possibility of a counterexample in the remaining unexplored state space, the user will get a message.

'''Optimizing the process of LTL model checking''' 
The process of model checking can be optimized for B and Event-B models by using partial order reduction. The idea of partial order reduction is to execute only a subset of all enabled actions in each state. Thus, only a part of the original state space is checked for the checked property. The reduction of the state space depends on the number of concurrent and independent actions in the model, as well as on the property being checked.

'''With Safety Check''' 
This checks whether a formula is a safety property or not.
If it is, this property is treated in an optimised way.
In some cases, this means that not the entire state space has to be computed.
For this optimisation to work, ProB needs the LTL2BA translator.
You can download and put it into ProB's lib folder, by choosing
Download and Install LTL2BA Tool
from the Help menu.
More details can be found below.

'''Search Options''' 
The model checker searches for a counterexample (i.e. a path that does not satisfy the current formula). Where the checked paths through the model's search space start depend on the following options in the LTL Preferences’ menu:
# ''Start search in initialization'' All paths that start in a state of the initialization of the machine are checked.
# ''Start search in current state'' All paths that start in the current state are checked.
# ''Start in initialization, but check formula in current state'' All paths that start in a state of the initialization of the machine are checked, but the formula is mapped to the current state. For example, this option can be used to check properties like "Is this state only reachable directly after executing operation `xy`?": The formula would be `Y[xy]`. This is equivalent to "G (current => f)" with f as the entered formula and using the option "Start search in initialization".
Note: Whereas `Y true` is always false when checked with option 1 or 2, it is usually true (but not in all cases) for option 3.

=== Supported Syntax ===

ProB supports LTL[e], an extended version of LTL. In contrast to the standard LTL, LTL[e] provides also support for propositions on transitions, not only on states. In practice, writing propositions on transitions is allowed by using the constructs `e(...)` and `[...]`. (see below). The LTL model checker of ProB supports Past-LTL[e] as well.

* Atomic propositions can be one of the following:
** Predicates can be written in curly braces: `{...}`. E.g. `{card(someset) > 1}`
** To check if an operation is enabled in a state use `e(Op)`, where `Op` is the name of the operation.
** To start a search from the current state of the animation use `current` (see the section '''LTL Preferences''' for more information).
** To check if a state has no outgoing transition leading to a different state use `sink`. This can be useful for finding "pseudo"-deadlocks, i.e. states where only query-operations are enabled that do not change the state. Note that `sink` holds for deadlock states as well.
** For checking if a state is a deadlock state the atomic proposition ` deadlock ` can be used.
** To check if a set of operations is disabled in a state use `deadlock(Op1,Op2,...,Opk)`, where Op1,Op2,...,Opk with k>0 are operations of the model. It is also possible to check if specific representations of an operation with arguments are disabled in a state using pattern-matching, e.g.: `deadlock(Op(1),Op(3))`.
** By means of `deterministic(Op1,Op2,...,Opk)`, where Op1,Op2,...,Opk with k>0 are operations of the model, one can check if maximum one of the operations Op1,Op2,...,Opk is enabled in a state.
** To check if exactly one operation from a set of operations Op1,Op2,...,Opk is enabled in a state use `controller(Op1,Op2,…,Opk)`.

* Transition propositions:
** If the next executed operation in the path is `Op`, the expression `[Op]` can be used. Also patter-matching for the arguments of the operation is supported. E.g. `[Op(3,4*v)]` checks if the next operation is `Op` and that the first argument is 3 and the third argument is `4*v` where `v` is a variable of the machine. Arbitrary B expressions can be used as patterns. Constants and variables of the machine can be used. Variables have the values of the state where the operations starts.
** The following are now also available in ProB 1.12:
*** `unchanged({BExpr})` check if the B expression BExpr is unchanged compared to the next state
*** `changed({BExpr}) ` check if the BExpr is changed by the next transition
*** `decreasing({BExpr})` check if the BExpr will decrease due to the next transition
***` increasing({BExpr}) ` check if the BExpr will increase due to the next transition
*** ` BA({BPred}) ` check before-after B predicate BPred on current and next state, where x$0 refers to value in current (before) state, and x to value in next (after) state

* Logical operators
** `true` and `false`
** `not`: negation
** `&`, `or` and `=>`: conjunction, disjunction and implication

* Temporal operators (future)
** `G f`: globally
** `F f`: finally
** `X f`: next
** `f U g`: until
** `f W g`: weak until
** `f R g`: release

* Temporal operators (past)
** `H f`: history (dual to G)
** `O f`: once (dual to F)
** `Y f`: yesterday (dual to X)
** `f S g`: since (dual to until)
** `f T g`: trigger (dual to release)

* Fairness operators
** `WF(Op)` or `wf(Op)`: weak fairness, where ` Op` is an operation
** `SF(Op)`or `sf(Op)`: strong fairness, where ` Op` is an operation
** `WEF`: weak fairness for all possible operations
** `SEF`: strong fairness for all possible operations

==Safety Properties ==

For safety properties ProB uses another checking algorithm, to avoid having to explore the entire SCC (strongly connected component) of a counter example.
In general this requires installing the LTL2BA tool (see Help menu), but the following patterns are supported directly without LTL2BA:
G StateProposition
G (StateProposition => X StateProposition)
where StateProposition is either an atomic proposition ({Pred}, e(Op), [Op], deadlock,...) or a propositional operators (not, &, =>, or) applied to StatePropositions.

Here are a few example patterns covered by the above:

G {Pred} Invariant
G(e(Op) => {Pred}) Necessary precondition for operation Op
G({Pred} => e(Op)) Sufficient precondition for operation Op
G([Op] => X{Pred}) Postcondition of operation Op
G(e(Op1) => not(e(Op2))) Enabling relations between operations
G(not(deadlock(Op1,...,Opk))) Relative deadlock freedom
G(deterministic(Op1,...,Opk)) Relative deadlock freedom
G(controller(Op1,...,Opk)) Relative deadlock freedom and determinism

==Setting Fairness Constraints==

Fairness is a notion where the search for counterexamples is restricted to paths that do not ignore infinitely the execution of a set of enabled operations imposed by the user as "fair" constraints. One possibility to set fairness constraints in ProB is to encode them in the LTL[e] formula intended to be checked. For example, for a given LTL[e] formula "f" a set of weak fairness conditions {a1,…,an} can be given as follows:
(FG e(a1) => GF [a1]) & … & (FG e(an) => GF [an]) => f.
In a similar way, strong fairness constraints can be imposed expressed by means of an LTL[e] formula:
(GF e(a1) => GF [a1]) & … & (GF e(an) => GF [an]) => f.

Checking fairness in this way is very often considered to be inefficient as usually the number of atoms (the possible valuations of the property) of the LTL property is exponential in the size of the formula.<ref>O. Lichtenstein and A. Pnueli: ''Checking that Finite State Concurrent Programs Satisfy Their Linear Specification''. POPL '85, Proceedings of the 12th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, ACM, 1985</ref> For this reason, the search algorithm of the LTL model checker has been extended in order to allow fairness to be checked efficiently. In addition, new operators have been added to the ProB’s LTL parser for setting fairness constraints to an LTL[e] property. The new operators are ''WF(-)'' and ''SF(-)'' and both accept as argument an operation. The fairness constraints must be given by means of implication: "fair => f", where "f" is the property to be checked and "fair" the fairness constraints.

In particular, "fair" can have one of the forms: "wfair", "sfair", "wfair & sfair", and "sfair & wfair", where "wfair" and "sfair" represent the imposed weak and strong fairness constraints, respectively.

Basically, "wfair" and "sfair" are expressed by means of logical formulas having the following syntax:

* Weak fair conditions ("wfair"):
** `WF(a)`, where `a` is an operation
** `&` and `or`: conjunction and disjunction

* Strong fair conditions ("sfair"):
** `SF(a)`, where `a` is an operation
** `&` and `or`: conjunction and disjunction

For instance, if we want to check an LTL property "f" on paths that are weak fair in regard to the operations "a" and "b" and additionally strong fair in regard to "c" or "d", then this can be given as follows:
(WF(a) & WF(b)) & (SF(c) or SF(d)) => f

Note that the operators ''WF(-)'' and ''SF(-)'' cannot appear on the right side of the fairness implication. Basically, ''WF(-)'' and ''SF(-)'' can be described by the following equivalences:
WF(a) ≡ (FG e(a) => GF [a]) and SF(a) ≡ (GF e(a) => GF [a]), where a is an operation.

For setting fairness constraints on all possible operations of the model being checked use the operators "WEF" and "SEF". For instance, if "f" is a liveness property and we want to restrict the search only to strongly fair paths, then we can impose the fairness constraints by means of the formula "SEF => f".

The grammar for imposing fairness constraints by means of the fairness implication ("fair => f") looks as follows:

fair ::= WEF | SEF | wfair | sfair | wfair & sfair | sfair & wfair 
wfair ::= wf(a) | ( wfair ) | wfair & wfair | wfair or wfair 
sfair ::= sf(a) | ( sfair ) | sfair & sfair | sfair or sfair

where "a" is a transition proposition.

==Storing LTL Assertions in the Model==

'''Storing LTL formulas in B machines''' 
LTL formulas can be stored in the `DEFINITIONS` section of a B machine. The name of the definition must start with `ASSERT_LTL` and a string must be specified. In case there is more than one LTL assertion given in the ‘DEFINITIONS’ section, the particular LTL assertions must be separated by semicolon. For example:

DEFINITIONS
ASSERT_LTL == "G (e(SetCruiseSpeed) => e(CruiseBecomesNotAllowed))";
ASSERT_LTL1 == "G (e(CruiseBecomesNotAllowed) => e(SetCruiseSpeed))";
ASSERT_LTL2 == "G (e(CruiseBecomesNotAllowed) => (ObstacleDisappears))"

'''Storing LTL formulas in CSP-M specifications''' 
LTL formulas can be stored within pragmas in CSP-M specifications. A pragma in which a single LTL formula is stored is given by "{-# assert_ltl "f" "c" #-}", where "assert_ltl" indicates the type of the information stored in the pragma (there are currently two types: assert_ltl and assert_ctl), and is followed by the LTL formula `f` and a comment `c` (the comment is optional). Both, the LTL formula and the comment, must be enclosed in double quotes.
It is also possible to give several LTL formulas in a single pragma within which the corresponding LTL assertions are separated by semicolon. For example:

{-# assert_ltl "SF(enter.1) & WF(req.1) => GF([enter.1])";
assert_ltl "SF(enter.2) & WF(req.2) => GF([enter.2])";
assert_ltl "GF [enter.1] & GF [enter.2]" "Should fail."#-}

Note that a semicolon must not follow the last assertion in a pragma.

For CSP-M specifications, it is also possible to assert LTL-formulae to particular processes in the model. This is possible by means of ``assert`` declarations, which have been recently included to the CSP-M grammar of the ProB CSP-M parser:

assert P |= LTL: "ltl-formula",
where `P` is an arbitrary process and `ltl-formula` an LTL formula.

==LTL Formulas in a Separate File==

With the command line version of ProB it is possible to check several LTL[e] formulae with one call. The command has the following syntax
probcli -ltlfile FILE ...
The file FILE contains one or more sections where each section has the form
[Name] Formula
The formula itself can spread several lines. Additional comments can be added with a leading #.
If a counter-example is found, the trace of the counter-example is saved into the file ltlce_Name.trace, where "Name" is the name of the formula in the LTL file.

One also can check a single LTL[e] formula ''F'' using the option '-ltlformula' as follows:
probcli -ltlformula "F" ...

==LTL Formulae in a Separate File==

With the command line version of ProB it is possible to check several LTL[e] formulae with one call. The command has the following syntax
probcli -ltlfile FILE ...
The file FILE contains one or more sections where each section has the form
[Name] Formula
The formula itself can spread in several lines. Additional comments can be added with a leading #.
If a counter-example is found, the trace of the counter-example is saved into the file ltlce_Name.trace, where "Name" is the name of the formula in the LTL file.

One also can check a single LTL[e] formula ''F'' using the option '-ltlformula' as follows:
probcli -ltlformula "F" ...

==LTL Model Checker Output==
The output provided by the LTL model checker can sometimes reveal some interesting statistical facts about the model and the property being checked on the model. The LTL model checker of ProB uses the tableau approach for checking an LTL[e] formula on a formal model. To check whether a model ''M'' satisfies a given formula ''f'', the algorithm generates a search graph, called also tableau graph, composed from the tableau of the formula and the state space of the model. If there is a path in the search graph that is a model for ''f'', then the formula is satisfiable. The nodes of the search graph are called ''atoms''.

Basically, using the tableau approach we prove that ''M'' satisfies ''f'' by negating the given formula and searching for a path fulfilling ''¬f''. If such a path is found, then we infer that ''M'' violates ''f''. Otherwise, if no path is found that satisfies ''¬f'', we conclude that ''M |= f''. The LTL model checking algorithm of ProB is based on searching for strongly connected components (SCCs) with certain properties to determine whether ''M'' satisfies ''f''. Finding such an SCC that can be reached from an initial state of ''M'' is a witness for a counter-example for ''f''. Sometimes, we use fairness to ignore such SCCs that do not fulfill the imposed fairness constraints in order to not impede proving a property by returning of non-fair paths as counter-examples.

The LTL model checker algorithm of ProB is implemented in C using a callback mechanism for evaluating the atomic propositions and the outgoing transitions in SICStus Prolog. (For each state of the model a callback will be performed.) Additionally, the search for SCCs is based on the Tarjan's algorithm. In the terminal all messages coming from the LTL model checker are preceded either by "LTL (current statistics): " or "LTL model checking:". The output from the LTL model checker can give helpful insights about the model and the model checking process.

Consider the CSP specifications "dphil_ltl8.csp" representing a model of the dining philosophers problem for eight philosophers which resolves the starvation problem by always forcing the first philosopher to pick up first the right fork instead of the left one. In other words, "dphil_ltl8.csp" has no deadlock states. Checking the LTL formula "GF [eat.0]" from the command line will produce the following output:

<pre>
$ probcli -ltlformula "GF [eat.0]" dphil_ltl8.csp
....
LTL model checking formula
% parsing_ltl_formula
% initialising_ltlc
starting_model_checking

LTL (current statistics): 13280 atoms, 10070 transitions generated, and 2631 callbacks needed.

LTL model checking: found counter-example (lasso-form): intro length = 1126, path in SCC of length = 5
LTL model checking: memory usage approx. 1924 KiB, 14104 atoms and 10724 transitions generated
LTL model checking: total time 22492ms, 2803 callbacks needed 22465ms, netto 26ms.
! An error occurred !
! source(ltl)
! Model Check Counter-Example found for:
! GF [eat.0]

Formula FALSE.

Runtime: 22220 ms
! *** error occurred ***
! ltl
</pre>

As one can clearly see from the output, the LTL model checker fails to prove "GF [eat.0]" on the model since it has found a counter-example for the formula. Note that the ProB LTL model checker explores the search graph and the state space dynamically. The above data is to be understand as follows:
* 14104 atoms - the LTL model checker needed to explore 14104 atoms to find a counter-example for the formula.
* 2803 callbacks needed - to explore the search graph the model checker makes callbacks in order to explore the state space of the model being checked (the exploration runs dynamically) and compute the successor states in the tableau graph. In this case the model checker has needed to explore 2803 states till it finds a counter-example for the formula
* memory usage approx. 1924 KiB - the memory needed to explore the tableau graph
* found counter-example (lasso-form) - means that the counter-example being found is path beginning in an initial state of the model and reaching a state that closes a cycle:
** intro length = 1126: the length of the sub-path from an initial state to the entry point of the cycle
** path in SCC of length = 5: the cycle is comprised of five states
* total time 22492ms - the LTL model checker needed about 23 seconds to find the counter-example. Here a distinction between the time needed to explore the state space of the model (2803 callbacks needed 22465ms) and the time spent for generating the tableau graph + the time for identifying the self-fulfilling SCC (netto 26ms)
* LTL (current statistics) - an intermediate data information is given each 20 seconds spent from the last current data information.

In the example above one can prove the LTL[e] formula "GF [eat.0]" on dphil_ltl6.csp using fairness. One can impose, for example, strong fairness conditions on all transitions of the model and thus verify that "GF [eat.0]" is satisfied under strong fairness. The call looks as follows:
<pre>
$ probcli -ltlformula "SEF => GF [eat.0]" dphil_ltl8.csp
...
LTL model checking formula
% parsing_ltl_formula
% initialising_ltlc
starting_model_checking
LTL (current statistics): 13016 atoms, 9834 transitions generated, and 2578 callbacks needed.
LTL (fairness): 0 strongly connected components were rejected, 0 callbacks needed.

LTL (current statistics): 27540 atoms, 44422 transitions generated, and 5123 callbacks needed.
LTL (fairness): 284 strongly connected components were rejected, 843 callbacks needed.
.....
LTL (current statistics): 85980 atoms, 267821 transitions generated, and 19733 callbacks needed.
LTL (fairness): 454 strongly connected components were rejected, 1924 callbacks needed.

LTL (current statistics): 95648 atoms, 364288 transitions generated, and 22150 callbacks needed.
LTL (fairness): 773 strongly connected components were rejected, 3085 callbacks needed.

LTL model checking: memory usage approx. 13829 KiB, 96500 atoms and 381625 transitions generated
LTL model checking: total time 190887ms, 22363 callbacks needed 186690ms, netto 467ms.
LTL model checking (fairness): 800 strongly connected components were rejected.
LTL model checking (fairness): total fairness checking time 3729ms, 3246 callbacks needed 3452ms, netto 277ms.
LTL Formula TRUE.
No counter example found for SEF => GF [eat.0].
Runtime: 188370 ms
</pre>

In the above check no fair counter-example could be found for the formula "GF [eat.0]". For this check the search graph comprises 96500 atoms and 381625 transitions, far more than the previous formula check (without fairness assumptions). Since no fair counter-example was found we can infer that the whole state space of the model was explored. Further, since we know from above that 22363 callbacks were needed to explore the search graph, we can infer that the state space of the model has in total 22363 states.

In the output above there is also some information about the fairness checking being performed for the model checker run. Form the fairness statistics we can see that the model checker has refuted 800 SCCs in total, i.e. there were 800 SCCs in the search graph that could serve as a counter-example for "GF [eat.0]" in case no fairness constraints were imposed.

== Other Relevant Tutorials about LTL Model Checking ==
A brief tutorial on visualizing LTL counter-examples in the Rodin tool can be found [[Tutorial LTL Counter-example View|here]].

A tutorial of a simple case study, where setting fairness constraints to some of the LTL properties is required, can be found [[Mutual Exclusion (Fairness)|here]

== Summary of CTL Syntax supported by ProB ==

CTL formulas f can be constructed from:

- atomic propositions:
{ Pred } to check if a B predicate Pred holds in the current state, e.g. {card(someset) > 1}
e(op) to check if an operation op is enabled

- propositional logic operators:
not f
f or g
f & g
f => g

- temporal operators:
EX f there is a next state satisfying f
EX[Op] f there is a next state via Op satisfying f, e.g. EX[reset]{db={}}
AX f all next states satisfy f
EF f there exists a path where f holds in the future
EG f there exists a path where f holds globally
AF f for all paths f holds in the future
AG f for all paths f holds globally
E f U g there exists a path where f holds until g

Note: a model satisfies a CTL formula iff the formula holds in all initial states.

== References ==
<references />

LTL Model Checking

2025-06-13T15:54:43Z

Jan Gruteser: /* Summary of CTL Syntax supported by ProB */

[[Category:User Manual]]__NOTOC__
ProB provides support for LTL (linear temporal logic) model checking. For an introduction to LTL see the [http://en.wikipedia.org/wiki/Linear_temporal_logic Wikipedia Article].

To use this feature, select "Check LTL/CTL Assertions" in the "Verify" menu. The feature can also be accessed by the key combination "Ctrl+L" under Windows and Linux, and by the key combination "Cmd+L" under MacOS. The following window appears:

[[File:ltlviewer.png]]

All LTL formulas that are given in the "DEFINTIONS" section of a B machine are displayed in the list box of the LTL/CTL Assertions Viewer. For CSP-M specifications all LTL formulas given in the LTL pragmas of the loaded CSP-M file will be shown in the viewer. (For more detailed information of how LTL/CTL assertions can be stored into B and CSP-M models see Section '''Storing LTL Assertions into a Model''').

A new LTL formula can be entered in the entry below the list box. (We explain the supported syntax below). The typed formula can then be either added to the list box by clicking the "Add" button or directly checked by clicking the "Check" button. Before doing that assure whether you are in the proper frame ("Add LTL Formula") of the bottom part of the LTL viewer.

The LTL model checker can be started for an LTL formula by performing a double-click on the respective formula or typing "Enter" after selecting the respective formula. Each LTL formula in the list box has on the left hand side a symbol that indicates what is the status of the respective formula. An LTL formula can have one of the following statuses (status symbols may differ under different operating systems):

* ? – The formula has not been checked yet.
* ✔ – The formula is true for all valid paths.
* ✘ – A counterexample for the formula has been found, i.e. there is a path that violates the formula. In case the formula has been just checked on the model the animator is navigated to the last state of the counterexample. The full path can then be seen in the history. The counterexample can be also obtained by the dotty-viewer after a second double-click on the formula in the assertions’ viewer.
* ⌚ – The formula is currently checked.
* ! – The formula check has been aborted by an unexpected error occurrence.
* ∞ – The formula check is incomplete, i.e. no counterexample was found so far, but the absence of a path that does not satisfy the formula can not be guaranteed because the state space was not fully explored. A new check can be started by a double-click.

All formulas can be checked by "Assertions -> Check All Assertions" in the menu bar. All formulas will be then checked from top to bottom in the list box.

Additionally, the viewer provides a context menu for the list box elements. The context menu can be popped-up by a right-mouse-click on a formula from the list box, and it performs a set of actions available to be performed on the currently selected formula (see Figure below).

[[File:ltlviewercontext.png]]

The old LTL and CTL dialogs can be accessed from "OldLtlViewers" in the menu bar.

==LTL Preferences==

There is a set of options coming with the LTL model checker. In this section we give a brief overview of the preferences. The LTL preferences can be viewed by selecting "LTL Preferences" in the "Preferences" menu of the LTL/CTL Assertions Viewer.

'''Exploring new states''' 
The LTL model checker searches in the already explored search space of the model. If a state is encountered that has not been explored before, the state will be explored (i.e. all transitions to successor states are computed). The number of how often this can happen is limited by the field "Max no. of new states".
Depending on the LTL formula, a partially explored state space can be sufficient to find a counterexample or to assure the absence of a counterexample. If there's still the possibility of a counterexample in the remaining unexplored state space, the user will get a message.

'''Optimizing the process of LTL model checking''' 
The process of model checking can be optimized for B and Event-B models by using partial order reduction. The idea of partial order reduction is to execute only a subset of all enabled actions in each state. Thus, only a part of the original state space is checked for the checked property. The reduction of the state space depends on the number of concurrent and independent actions in the model, as well as on the property being checked.

'''With Safety Check''' 
This checks whether a formula is a safety property or not.
If it is, this property is treated in an optimised way.
In some cases, this means that not the entire state space has to be computed.
For this optimisation to work, ProB needs the LTL2BA translator.
You can download and put it into ProB's lib folder, by choosing
Download and Install LTL2BA Tool
from the Help menu.
More details can be found below.

'''Search Options''' 
The model checker searches for a counterexample (i.e. a path that does not satisfy the current formula). Where the checked paths through the model's search space start depend on the following options in the LTL Preferences’ menu:
# ''Start search in initialization'' All paths that start in a state of the initialization of the machine are checked.
# ''Start search in current state'' All paths that start in the current state are checked.
# ''Start in initialization, but check formula in current state'' All paths that start in a state of the initialization of the machine are checked, but the formula is mapped to the current state. For example, this option can be used to check properties like "Is this state only reachable directly after executing operation `xy`?": The formula would be `Y[xy]`. This is equivalent to "G (current => f)" with f as the entered formula and using the option "Start search in initialization".
Note: Whereas `Y true` is always false when checked with option 1 or 2, it is usually true (but not in all cases) for option 3.

=== Supported Syntax ===

ProB supports LTL[e], an extended version of LTL. In contrast to the standard LTL, LTL[e] provides also support for propositions on transitions, not only on states. In practice, writing propositions on transitions is allowed by using the constructs `e(...)` and `[...]`. (see below). The LTL model checker of ProB supports Past-LTL[e] as well.

* Atomic propositions can be one of the following:
** Predicates can be written in curly braces: `{...}`. E.g. `{card(someset) > 1}`
** To check if an operation is enabled in a state use `e(Op)`, where `Op` is the name of the operation.
** To start a search from the current state of the animation use `current` (see the section '''LTL Preferences''' for more information).
** To check if a state has no outgoing transition leading to a different state use `sink`. This can be useful for finding "pseudo"-deadlocks, i.e. states where only query-operations are enabled that do not change the state. Note that `sink` holds for deadlock states as well.
** For checking if a state is a deadlock state the atomic proposition ` deadlock ` can be used.
** To check if a set of operations is disabled in a state use `deadlock(Op1,Op2,...,Opk)`, where Op1,Op2,...,Opk with k>0 are operations of the model. It is also possible to check if specific representations of an operation with arguments are disabled in a state using pattern-matching, e.g.: `deadlock(Op(1),Op(3))`.
** By means of `deterministic(Op1,Op2,...,Opk)`, where Op1,Op2,...,Opk with k>0 are operations of the model, one can check if maximum one of the operations Op1,Op2,...,Opk is enabled in a state.
** To check if exactly one operation from a set of operations Op1,Op2,...,Opk is enabled in a state use `controller(Op1,Op2,…,Opk)`.

* Transition propositions:
** If the next executed operation in the path is `Op`, the expression `[Op]` can be used. Also patter-matching for the arguments of the operation is supported. E.g. `[Op(3,4*v)]` checks if the next operation is `Op` and that the first argument is 3 and the third argument is `4*v` where `v` is a variable of the machine. Arbitrary B expressions can be used as patterns. Constants and variables of the machine can be used. Variables have the values of the state where the operations starts.
** The following are now also available in ProB 1.12:
*** `unchanged({BExpr})` check if the B expression BExpr is unchanged compared to the next state
*** `changed({BExpr}) ` check if the BExpr is changed by the next transition
*** `decreasing({BExpr})` check if the BExpr will decrease due to the next transition
***` increasing({BExpr}) ` check if the BExpr will increase due to the next transition
*** ` BA({BPred}) ` check before-after B predicate BPred on current and next state, where x$0 refers to value in current (before) state, and x to value in next (after) state

* Logical operators
** `true` and `false`
** `not`: negation
** `&`, `or` and `=>`: conjunction, disjunction and implication

* Temporal operators (future)
** `G f`: globally
** `F f`: finally
** `X f`: next
** `f U g`: until
** `f W g`: weak until
** `f R g`: release

* Temporal operators (past)
** `H f`: history (dual to G)
** `O f`: once (dual to F)
** `Y f`: yesterday (dual to X)
** `f S g`: since (dual to until)
** `f T g`: trigger (dual to release)

* Fairness operators
** `WF(Op)` or `wf(Op)`: weak fairness, where ` Op` is an operation
** `SF(Op)`or `sf(Op)`: strong fairness, where ` Op` is an operation
** `WEF`: weak fairness for all possible operations
** `SEF`: strong fairness for all possible operations

==Safety Properties ==

For safety properties ProB uses another checking algorithm, to avoid having to explore the entire SCC (strongly connected component) of a counter example.
In general this requires installing the LTL2BA tool (see Help menu), but the following patterns are supported directly without LTL2BA:
G StateProposition
G (StateProposition => X StateProposition)
where StateProposition is either an atomic proposition ({Pred}, e(Op), [Op], deadlock,...) or a propositional operators (not, &, =>, or) applied to StatePropositions.

Here are a few example patterns covered by the above:

G {Pred} Invariant
G(e(Op) => {Pred}) Necessary precondition for operation Op
G({Pred} => e(Op)) Sufficient precondition for operation Op
G([Op] => X{Pred}) Postcondition of operation Op
G(e(Op1) => not(e(Op2))) Enabling relations between operations
G(not(deadlock(Op1,...,Opk))) Relative deadlock freedom
G(deterministic(Op1,...,Opk)) Relative deadlock freedom
G(controller(Op1,...,Opk)) Relative deadlock freedom and determinism

==Setting Fairness Constraints==

Fairness is a notion where the search for counterexamples is restricted to paths that do not ignore infinitely the execution of a set of enabled operations imposed by the user as "fair" constraints. One possibility to set fairness constraints in ProB is to encode them in the LTL[e] formula intended to be checked. For example, for a given LTL[e] formula "f" a set of weak fairness conditions {a1,…,an} can be given as follows:
(FG e(a1) => GF [a1]) & … & (FG e(an) => GF [an]) => f.
In a similar way, strong fairness constraints can be imposed expressed by means of an LTL[e] formula:
(GF e(a1) => GF [a1]) & … & (GF e(an) => GF [an]) => f.

Checking fairness in this way is very often considered to be inefficient as usually the number of atoms (the possible valuations of the property) of the LTL property is exponential in the size of the formula.<ref>O. Lichtenstein and A. Pnueli: ''Checking that Finite State Concurrent Programs Satisfy Their Linear Specification''. POPL '85, Proceedings of the 12th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages, ACM, 1985</ref> For this reason, the search algorithm of the LTL model checker has been extended in order to allow fairness to be checked efficiently. In addition, new operators have been added to the ProB’s LTL parser for setting fairness constraints to an LTL[e] property. The new operators are ''WF(-)'' and ''SF(-)'' and both accept as argument an operation. The fairness constraints must be given by means of implication: "fair => f", where "f" is the property to be checked and "fair" the fairness constraints.

In particular, "fair" can have one of the forms: "wfair", "sfair", "wfair & sfair", and "sfair & wfair", where "wfair" and "sfair" represent the imposed weak and strong fairness constraints, respectively.

Basically, "wfair" and "sfair" are expressed by means of logical formulas having the following syntax:

* Weak fair conditions ("wfair"):
** `WF(a)`, where `a` is an operation
** `&` and `or`: conjunction and disjunction

* Strong fair conditions ("sfair"):
** `SF(a)`, where `a` is an operation
** `&` and `or`: conjunction and disjunction

For instance, if we want to check an LTL property "f" on paths that are weak fair in regard to the operations "a" and "b" and additionally strong fair in regard to "c" or "d", then this can be given as follows:
(WF(a) & WF(b)) & (SF(c) or SF(d)) => f

Note that the operators ''WF(-)'' and ''SF(-)'' cannot appear on the right side of the fairness implication. Basically, ''WF(-)'' and ''SF(-)'' can be described by the following equivalences:
WF(a) ≡ (FG e(a) => GF [a]) and SF(a) ≡ (GF e(a) => GF [a]), where a is an operation.

For setting fairness constraints on all possible operations of the model being checked use the operators "WEF" and "SEF". For instance, if "f" is a liveness property and we want to restrict the search only to strongly fair paths, then we can impose the fairness constraints by means of the formula "SEF => f".

The grammar for imposing fairness constraints by means of the fairness implication ("fair => f") looks as follows:

fair ::= WEF | SEF | wfair | sfair | wfair & sfair | sfair & wfair 
wfair ::= wf(a) | ( wfair ) | wfair & wfair | wfair or wfair 
sfair ::= sf(a) | ( sfair ) | sfair & sfair | sfair or sfair

where "a" is a transition proposition.

==Storing LTL Assertions in the Model==

'''Storing LTL formulas in B machines''' 
LTL formulas can be stored in the `DEFINITIONS` section of a B machine. The name of the definition must start with `ASSERT_LTL` and a string must be specified. In case there is more than one LTL assertion given in the ‘DEFINITIONS’ section, the particular LTL assertions must be separated by semicolon. For example:

DEFINITIONS
ASSERT_LTL == "G (e(SetCruiseSpeed) => e(CruiseBecomesNotAllowed))";
ASSERT_LTL1 == "G (e(CruiseBecomesNotAllowed) => e(SetCruiseSpeed))";
ASSERT_LTL2 == "G (e(CruiseBecomesNotAllowed) => (ObstacleDisappears))"

'''Storing LTL formulas in CSP-M specifications''' 
LTL formulas can be stored within pragmas in CSP-M specifications. A pragma in which a single LTL formula is stored is given by "{-# assert_ltl "f" "c" #-}", where "assert_ltl" indicates the type of the information stored in the pragma (there are currently two types: assert_ltl and assert_ctl), and is followed by the LTL formula `f` and a comment `c` (the comment is optional). Both, the LTL formula and the comment, must be enclosed in double quotes.
It is also possible to give several LTL formulas in a single pragma within which the corresponding LTL assertions are separated by semicolon. For example:

{-# assert_ltl "SF(enter.1) & WF(req.1) => GF([enter.1])";
assert_ltl "SF(enter.2) & WF(req.2) => GF([enter.2])";
assert_ltl "GF [enter.1] & GF [enter.2]" "Should fail."#-}

Note that a semicolon must not follow the last assertion in a pragma.

For CSP-M specifications, it is also possible to assert LTL-formulae to particular processes in the model. This is possible by means of ``assert`` declarations, which have been recently included to the CSP-M grammar of the ProB CSP-M parser:

assert P |= LTL: "ltl-formula",
where `P` is an arbitrary process and `ltl-formula` an LTL formula.

==LTL Formulas in a Separate File==

With the command line version of ProB it is possible to check several LTL[e] formulae with one call. The command has the following syntax
probcli -ltlfile FILE ...
The file FILE contains one or more sections where each section has the form
[Name] Formula
The formula itself can spread several lines. Additional comments can be added with a leading #.
If a counter-example is found, the trace of the counter-example is saved into the file ltlce_Name.trace, where "Name" is the name of the formula in the LTL file.

One also can check a single LTL[e] formula ''F'' using the option '-ltlformula' as follows:
probcli -ltlformula "F" ...

==LTL Formulae in a Separate File==

With the command line version of ProB it is possible to check several LTL[e] formulae with one call. The command has the following syntax
probcli -ltlfile FILE ...
The file FILE contains one or more sections where each section has the form
[Name] Formula
The formula itself can spread in several lines. Additional comments can be added with a leading #.
If a counter-example is found, the trace of the counter-example is saved into the file ltlce_Name.trace, where "Name" is the name of the formula in the LTL file.

One also can check a single LTL[e] formula ''F'' using the option '-ltlformula' as follows:
probcli -ltlformula "F" ...

==LTL Model Checker Output==
The output provided by the LTL model checker can sometimes reveal some interesting statistical facts about the model and the property being checked on the model. The LTL model checker of ProB uses the tableau approach for checking an LTL[e] formula on a formal model. To check whether a model ''M'' satisfies a given formula ''f'', the algorithm generates a search graph, called also tableau graph, composed from the tableau of the formula and the state space of the model. If there is a path in the search graph that is a model for ''f'', then the formula is satisfiable. The nodes of the search graph are called ''atoms''.

Basically, using the tableau approach we prove that ''M'' satisfies ''f'' by negating the given formula and searching for a path fulfilling ''¬f''. If such a path is found, then we infer that ''M'' violates ''f''. Otherwise, if no path is found that satisfies ''¬f'', we conclude that ''M |= f''. The LTL model checking algorithm of ProB is based on searching for strongly connected components (SCCs) with certain properties to determine whether ''M'' satisfies ''f''. Finding such an SCC that can be reached from an initial state of ''M'' is a witness for a counter-example for ''f''. Sometimes, we use fairness to ignore such SCCs that do not fulfill the imposed fairness constraints in order to not impede proving a property by returning of non-fair paths as counter-examples.

The LTL model checker algorithm of ProB is implemented in C using a callback mechanism for evaluating the atomic propositions and the outgoing transitions in SICStus Prolog. (For each state of the model a callback will be performed.) Additionally, the search for SCCs is based on the Tarjan's algorithm. In the terminal all messages coming from the LTL model checker are preceded either by "LTL (current statistics): " or "LTL model checking:". The output from the LTL model checker can give helpful insights about the model and the model checking process.

Consider the CSP specifications "dphil_ltl8.csp" representing a model of the dining philosophers problem for eight philosophers which resolves the starvation problem by always forcing the first philosopher to pick up first the right fork instead of the left one. In other words, "dphil_ltl8.csp" has no deadlock states. Checking the LTL formula "GF [eat.0]" from the command line will produce the following output:

<pre>
$ probcli -ltlformula "GF [eat.0]" dphil_ltl8.csp
....
LTL model checking formula
% parsing_ltl_formula
% initialising_ltlc
starting_model_checking

LTL (current statistics): 13280 atoms, 10070 transitions generated, and 2631 callbacks needed.

LTL model checking: found counter-example (lasso-form): intro length = 1126, path in SCC of length = 5
LTL model checking: memory usage approx. 1924 KiB, 14104 atoms and 10724 transitions generated
LTL model checking: total time 22492ms, 2803 callbacks needed 22465ms, netto 26ms.
! An error occurred !
! source(ltl)
! Model Check Counter-Example found for:
! GF [eat.0]

Formula FALSE.

Runtime: 22220 ms
! *** error occurred ***
! ltl
</pre>

As one can clearly see from the output, the LTL model checker fails to prove "GF [eat.0]" on the model since it has found a counter-example for the formula. Note that the ProB LTL model checker explores the search graph and the state space dynamically. The above data is to be understand as follows:
* 14104 atoms - the LTL model checker needed to explore 14104 atoms to find a counter-example for the formula.
* 2803 callbacks needed - to explore the search graph the model checker makes callbacks in order to explore the state space of the model being checked (the exploration runs dynamically) and compute the successor states in the tableau graph. In this case the model checker has needed to explore 2803 states till it finds a counter-example for the formula
* memory usage approx. 1924 KiB - the memory needed to explore the tableau graph
* found counter-example (lasso-form) - means that the counter-example being found is path beginning in an initial state of the model and reaching a state that closes a cycle:
** intro length = 1126: the length of the sub-path from an initial state to the entry point of the cycle
** path in SCC of length = 5: the cycle is comprised of five states
* total time 22492ms - the LTL model checker needed about 23 seconds to find the counter-example. Here a distinction between the time needed to explore the state space of the model (2803 callbacks needed 22465ms) and the time spent for generating the tableau graph + the time for identifying the self-fulfilling SCC (netto 26ms)
* LTL (current statistics) - an intermediate data information is given each 20 seconds spent from the last current data information.

In the example above one can prove the LTL[e] formula "GF [eat.0]" on dphil_ltl6.csp using fairness. One can impose, for example, strong fairness conditions on all transitions of the model and thus verify that "GF [eat.0]" is satisfied under strong fairness. The call looks as follows:
<pre>
$ probcli -ltlformula "SEF => GF [eat.0]" dphil_ltl8.csp
...
LTL model checking formula
% parsing_ltl_formula
% initialising_ltlc
starting_model_checking
LTL (current statistics): 13016 atoms, 9834 transitions generated, and 2578 callbacks needed.
LTL (fairness): 0 strongly connected components were rejected, 0 callbacks needed.

LTL (current statistics): 27540 atoms, 44422 transitions generated, and 5123 callbacks needed.
LTL (fairness): 284 strongly connected components were rejected, 843 callbacks needed.
.....
LTL (current statistics): 85980 atoms, 267821 transitions generated, and 19733 callbacks needed.
LTL (fairness): 454 strongly connected components were rejected, 1924 callbacks needed.

LTL (current statistics): 95648 atoms, 364288 transitions generated, and 22150 callbacks needed.
LTL (fairness): 773 strongly connected components were rejected, 3085 callbacks needed.

LTL model checking: memory usage approx. 13829 KiB, 96500 atoms and 381625 transitions generated
LTL model checking: total time 190887ms, 22363 callbacks needed 186690ms, netto 467ms.
LTL model checking (fairness): 800 strongly connected components were rejected.
LTL model checking (fairness): total fairness checking time 3729ms, 3246 callbacks needed 3452ms, netto 277ms.
LTL Formula TRUE.
No counter example found for SEF => GF [eat.0].
Runtime: 188370 ms
</pre>

In the above check no fair counter-example could be found for the formula "GF [eat.0]". For this check the search graph comprises 96500 atoms and 381625 transitions, far more than the previous formula check (without fairness assumptions). Since no fair counter-example was found we can infer that the whole state space of the model was explored. Further, since we know from above that 22363 callbacks were needed to explore the search graph, we can infer that the state space of the model has in total 22363 states.

In the output above there is also some information about the fairness checking being performed for the model checker run. Form the fairness statistics we can see that the model checker has refuted 800 SCCs in total, i.e. there were 800 SCCs in the search graph that could serve as a counter-example for "GF [eat.0]" in case no fairness constraints were imposed.

== Other Relevant Tutorials about LTL Model Checking ==
A brief tutorial on visualizing LTL counter-examples in the Rodin tool can be found [[Tutorial LTL Counter-example View|here]].

A tutorial of a simple case study, where setting fairness constraints to some of the LTL properties is required, can be found [[Mutual Exclusion (Fairness)|here]

== Summary of CTL Syntax supported by ProB ==

CTL formulas f can be constructed from:

- atomic propositions:
{ Pred } to check if a B predicate Pred holds in the current state, e.g. {card(someset) > 1}
e(op) to check if an operation op is enabled

- propositional logic operators:
not f
f or g
f & g
f => g

- temporal operators:
EX f there is a next state satisfying f
EX[Op] f there is a next state via Op satisfying f, e.g. EX[reset]{db={}}
AX f all next states satisfy f
EF f there exists a path where f holds in the future
EG f there exists a path where f holds globally
AF f for all paths f holds in the future
AG f for all paths f holds globally
E f U g there exists a path where f holds until g

Note: a model satisfies a CTL formula iff the formula holds in all initial states.

== References ==
<references />

Rules-DSL

2025-04-30T17:06:52Z

Jan Gruteser: /* Computations */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code> (note: the <tt>TYPE</tt> section is optional since ProB parser version 2.15.1). A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML/XML validation report as in ProB2-UI for the current animation state.
The provided file extension is used to determine whether the HTML or the XML version of the report is generated.
To validate all rules, use this option in combination with <code>-execute_all</code>.
There is also a dot visualisation command "rule_dependency graph" that can be used to create a graph of the dependencies of rules and computations (including results of the current state); example call:
<pre>probcli myMch.mch -execute_all -rule_report myReport.html -dot "rule_dependency_graph" myGraph.pdf</pre>
All three export options are also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check in the report (of the type <tt>STRING</tt>), e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Generating UML Sequence Charts

2025-04-14T13:51:47Z

Jan Gruteser: /* Installation and Using */

=== Installation and Using ===

ProB has a new experimental feature to generate a UML sequence chart from the current animation trace using [https://plantuml.com PlantUML].
The feature is available in ProB CLI, ProB Tcl/Tk and ProB2-UI.
It currently works for classical B and TLA+ models and you need to copy the [https://plantuml.com/download plantuml.jar] file to ProB's lib folder. The file should be named plantuml.jar (without any version numbers).

You can also use the command-line version of ProB to install it
<pre>
probcli --install plantuml
</pre>
This should generate output similar to this:
<pre>
Installing component plantuml from https://github.com/plantuml/plantuml/releases/download/v1.2024.7/
--> curl -L https://github.com/plantuml/plantuml/releases/download/v1.2024.7/plantuml-epl-1.2024.7.jar -o .../lib/plantuml.jar
Installation complete
</pre>

For ProB2-UI a dialog will pop-up when trying to use the feature giving you instructions on where to put the plantuml.jar file.
With ProB2-UI it is also possible to include a sequence chart in a VisB HTML export.

=== Using the Command ===

It is available in the Visualize menu of Tcl/Tk:

[[file:ProBUMLSeqChartCmd.png|center||300px]]

The UML sequence chart is also available in ProB2-UI in the Graph & Table Visualisation View accessible in the Visualisation menu.

[[file:ProBUMLSeqChartProB2UICmd.png|center||300px]]

[[file:ProBUMLSeqChartProB2UIDialog.png|center||500px]]

=== Specifying the Actors ===

For every B Operation Op that you want to visualise you need to add a definition
SEQUENCE_CHART_Op
in your DEFINITIONS.
The definition can take arguments, in which case the actual arguments in the trace are passed to the definition. The definition can take fewer arguments (but not more) than the B operation.

The definition should either return
* the empty string, meaning this operation should be ignored
* a couple <tt>(ActorFrom,ActorTo)</tt> specifying the name of the actor sending the message (ActorFrom) and the one receiving the message (ActorTo). You can use strings or other values (which will be converted to strings).
* a triple <tt>(ActorFrom,ArrowStyle,ActorTo)</tt>, where the actors are like above and ArrowStyle is a string representing a valid plantUML arrow.
* a triple <tt>(ActorFrom,ArrowStyle,ArrowSuffix,ActorTo)</tt>, where the actors and arrow style are like above and ArrowSuffix is a string representing a valid plantUML arrow suffix.
* a record <tt>rec(from:ActorFrom,to:ActorTo,arrow:ArrowStyle,suffix:ArrowSuffix)</tt>. Note that the arrow fields are optional.

Currently these arrow styles are supported:
* '''-->'''
* '''->'''
* '''->x'''
* '''->>'''
* '''-\\'''
* '''\\\\-'''
* '''//--'''
* '''->o'''
* '''o\\\\--'''
* '''<->'''
* '''<->o'''
* '''-[#green]>'''
* '''-[#green]->'''
* '''-[#blue]->'''
* '''-[#red]->'''
* '''-[#red]>'''
* '''-[#0000FF]->'''
* '''<-'''
* '''<--'''

Optionally you can add these suffixes:
* '''++''' (activate the target)
* '''--''' (deactivate source)
* '''**''' (create an instance of target)
* '''!!''' (destroy an instance of target)

== Example ==

The following diagram can be created using the model below after animating and then using the command above.

[[file:ProBUMLSeqCharScheduler.png|center||300px]]

And here is the well-known scheduler example with example SEQUENCE_CHART definitions:

<pre>
MACHINE scheduler_UML
SETS
PID = {process1,process2,process3}
VARIABLES active, ready, waiting
DEFINITIONS
"CHOOSE.def";
SEQUENCE_CHART_INITIALISATION == ""; // ignore
SEQUENCE_CHART_new(pp) == ("Master", "-->","**",pp);
SEQUENCE_CHART_del(pp) == ("Master", "-->","!!",pp);
SEQUENCE_CHART_ready(pp) == (pp, "-->","Master");
SEQUENCE_CHART_swap == ("Master", "-->","--",CHOOSE(active))
INVARIANT
active <: PID &
ready <: PID &
waiting <: PID &
(ready /\ waiting) = {} &
active /\ (ready \/ waiting) = {} &
/*@label "SAF" */ card(active) <= 1 &
((active = {}) => (ready = {}))
INITIALISATION
active := {} || ready := {} || waiting := {}
OPERATIONS
new(pp) =
SELECT
pp : PID &
pp /: active &
pp /: (ready \/ waiting)
THEN
waiting := (waiting \/ { pp })
END;
del(pp) =
SELECT
pp : waiting
THEN
waiting := waiting - {pp}
END;
ready(rr) =
SELECT
rr : waiting
THEN
waiting := (waiting - {rr}) ||
IF (active = {}) THEN
active := {rr}
ELSE
ready := ready \/ {rr}
END
END;
swap =
SELECT
active /= {}
THEN
waiting := (waiting \/ active) ||
IF (ready = {}) THEN
active := {}
ELSE
ANY pp WHERE pp : ready
THEN
active := {pp} ||
ready := ready - {pp}
END
END
END
END
</pre>

Generating UML Sequence Charts

2025-04-14T13:51:16Z

Jan Gruteser: /* Installation and Using */

=== Installation and Using ===

ProB has a new experimental feature to generate a UML sequence chart from the current animation trace using [https://plantuml.com PlantUML].
The feature is available in ProB CLI, ProB Tcl/Tk and ProB2-UI.
With ProB2-UI it is also possible to include a sequence chart in a VisB HTML export.
It currently works for classical B and TLA+ models and you need to copy the [https://plantuml.com/download plantuml.jar] file to ProB's lib folder. The file should be named plantuml.jar (without any version numbers).

You can also use the command-line version of ProB to install it
<pre>
probcli --install plantuml
</pre>
This should generate output similar to this:
<pre>
Installing component plantuml from https://github.com/plantuml/plantuml/releases/download/v1.2024.7/
--> curl -L https://github.com/plantuml/plantuml/releases/download/v1.2024.7/plantuml-epl-1.2024.7.jar -o .../lib/plantuml.jar
Installation complete
</pre>

For ProB2-UI a dialog will pop-up when trying to use the feature giving you instructions on where to put the plantuml.jar file.

=== Using the Command ===

It is available in the Visualize menu of Tcl/Tk:

[[file:ProBUMLSeqChartCmd.png|center||300px]]

The UML sequence chart is also available in ProB2-UI in the Graph & Table Visualisation View accessible in the Visualisation menu.

[[file:ProBUMLSeqChartProB2UICmd.png|center||300px]]

[[file:ProBUMLSeqChartProB2UIDialog.png|center||500px]]

=== Specifying the Actors ===

For every B Operation Op that you want to visualise you need to add a definition
SEQUENCE_CHART_Op
in your DEFINITIONS.
The definition can take arguments, in which case the actual arguments in the trace are passed to the definition. The definition can take fewer arguments (but not more) than the B operation.

The definition should either return
* the empty string, meaning this operation should be ignored
* a couple <tt>(ActorFrom,ActorTo)</tt> specifying the name of the actor sending the message (ActorFrom) and the one receiving the message (ActorTo). You can use strings or other values (which will be converted to strings).
* a triple <tt>(ActorFrom,ArrowStyle,ActorTo)</tt>, where the actors are like above and ArrowStyle is a string representing a valid plantUML arrow.
* a triple <tt>(ActorFrom,ArrowStyle,ArrowSuffix,ActorTo)</tt>, where the actors and arrow style are like above and ArrowSuffix is a string representing a valid plantUML arrow suffix.
* a record <tt>rec(from:ActorFrom,to:ActorTo,arrow:ArrowStyle,suffix:ArrowSuffix)</tt>. Note that the arrow fields are optional.

Currently these arrow styles are supported:
* '''-->'''
* '''->'''
* '''->x'''
* '''->>'''
* '''-\\'''
* '''\\\\-'''
* '''//--'''
* '''->o'''
* '''o\\\\--'''
* '''<->'''
* '''<->o'''
* '''-[#green]>'''
* '''-[#green]->'''
* '''-[#blue]->'''
* '''-[#red]->'''
* '''-[#red]>'''
* '''-[#0000FF]->'''
* '''<-'''
* '''<--'''

Optionally you can add these suffixes:
* '''++''' (activate the target)
* '''--''' (deactivate source)
* '''**''' (create an instance of target)
* '''!!''' (destroy an instance of target)

== Example ==

The following diagram can be created using the model below after animating and then using the command above.

[[file:ProBUMLSeqCharScheduler.png|center||300px]]

And here is the well-known scheduler example with example SEQUENCE_CHART definitions:

<pre>
MACHINE scheduler_UML
SETS
PID = {process1,process2,process3}
VARIABLES active, ready, waiting
DEFINITIONS
"CHOOSE.def";
SEQUENCE_CHART_INITIALISATION == ""; // ignore
SEQUENCE_CHART_new(pp) == ("Master", "-->","**",pp);
SEQUENCE_CHART_del(pp) == ("Master", "-->","!!",pp);
SEQUENCE_CHART_ready(pp) == (pp, "-->","Master");
SEQUENCE_CHART_swap == ("Master", "-->","--",CHOOSE(active))
INVARIANT
active <: PID &
ready <: PID &
waiting <: PID &
(ready /\ waiting) = {} &
active /\ (ready \/ waiting) = {} &
/*@label "SAF" */ card(active) <= 1 &
((active = {}) => (ready = {}))
INITIALISATION
active := {} || ready := {} || waiting := {}
OPERATIONS
new(pp) =
SELECT
pp : PID &
pp /: active &
pp /: (ready \/ waiting)
THEN
waiting := (waiting \/ { pp })
END;
del(pp) =
SELECT
pp : waiting
THEN
waiting := waiting - {pp}
END;
ready(rr) =
SELECT
rr : waiting
THEN
waiting := (waiting - {rr}) ||
IF (active = {}) THEN
active := {rr}
ELSE
ready := ready \/ {rr}
END
END;
swap =
SELECT
active /= {}
THEN
waiting := (waiting \/ active) ||
IF (ready = {}) THEN
active := {}
ELSE
ANY pp WHERE pp : ready
THEN
active := {pp} ||
ready := ready - {pp}
END
END
END
END
</pre>

Rules-DSL

2025-04-14T13:45:11Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML/XML validation report as in ProB2-UI for the current animation state.
The provided file extension is used to determine whether the HTML or the XML version of the report is generated.
To validate all rules, use this option in combination with <code>-execute_all</code>.
There is also a dot visualisation command "rule_dependency graph" that can be used to create a graph of the dependencies of rules and computations (including results of the current state); example call:
<pre>probcli myMch.mch -execute_all -rule_report myReport.html -dot "rule_dependency_graph" myGraph.pdf</pre>
All three export options are also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check in the report (of the type <tt>STRING</tt>), e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Rules-DSL

2025-04-14T13:08:12Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML/XML validation report as in ProB2-UI for the current animation state.
The provided file extension is used to determine whether the HTML or the XML version of the report is generated.
To validate all rules, use this option in combination with <code>-execute_all</code>.
Both report options are also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check in the report (of the type <tt>STRING</tt>), e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Using the Command-Line Version of ProB

2025-04-14T12:41:53Z

Jan Gruteser: /* -rule_report */

[[Category:Tutorial]]
[[Category:User Manual]]
[[Category:ProB Cli]]

The command-line version of ProB, called probcli, offers many of the features of the standalone Tcl/Tk Version via the command-line. As such, you can run ProB from your shell scripts or in your Makefiles.
These pages refer to version 1.6 of ProB. Some features are only available in the nightly build of ProB. You can run <tt>probcli –help</tt> to find out which commands are supported by your version of ProB. For Bash users we provide [[Bash Completion|command completion]] support.

Note: the order of commands is not relevant for <tt>probcli</tt> (except within groups of commands such as <tt>-p MAXINT 127</tt>). Any argument that is not recognised by <tt>probcli</tt> is treated as a filename to be analysed.

[[file:ProBTerminalizerDemo.gif|center||600px]]

== Conventions used ==

The following conventions are used in this guide:

{| cellpadding="10"
| valign="top" | <replaceme>
| All values that should be replaced with some value are shown withing < >
|-
| valign="top" | line breaks
| Command synopsis for command may be broken up on several lines. When typing commands enter all option on the same line.
|}

== Synopsis ==

<pre>probcli [--help]
<filename> [ <options> ]</pre>

The underscore within all options can as of version 1.5.1-beta7 be replaced with dashes. Also, all commands can either be typed with single leading dashes or double leading dashes.
For example, all of the following commands have the same effect:
probcli M.mch -model_check
probcli M.mch -model-check
probcli M.mch --model_check
probcli M.mch --model-check

== Options ==

=== -mc <nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| model check; checking at most <nr> states
|}

Example

probcli my.mch -mc 100

Note: with a value of nr=1 ProB will only inspect the "virtual" root node (and compute its outgoing transitions).
Also see the related options <tt>-nodead, -noinv, -nogoal, -noass</tt> to influence which kinds of errors are reported by <tt>-mc</tt>.
You can also set a target goal predicate using the <tt>-goal "PRED"</tt> command and limit the scope of the model checking using the <tt>-scope "PRED"</tt> command.

=== -model_check ===

The same as <tt>-mc</tt> but without a limit on the number of nodes checked.
ProB will run until the entire state space is explored.

=== -no<x> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| restrict errors reported by model checking (-mc), TLC model checking (-mc_with_tlc), animation (-animate) and execution (-execute) with <x>=dead,inv,goal,ass
* -nodead : do not report deadlocks
* -noinv : do not report invariant violations
* -nogoal : do not stop if a state satisfying the GOAL predicate has been found
* -noass : do not report assertion violations
|}

Example

probcli my.mch -mc 1000 -nodead -nogoal

=== -disable_timeout ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| turn off ProB's timeout mechanism, e.g., for computing enabled operations and invariant checking; this can sometimes speed up model checking (-mc or -model_check) and animation (-animate). Available as of version 1.5.1-beta7.
|}

Example

probcli my.mch -model-check -disable-timeout

=== -bf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed breadth-first during model checking
|}

Example

probcli my.mch -bf -mc 1000

=== -df ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed depth-first during model checking
|}

Example

probcli my.mch -df -mc 1000

=== -mc_mode <M> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| influence how the model checker proceeds. Available as of version 1.5.1. Supersedes the <tt>-df</tt> and <tt>-bf</tt> switches.
Possible values for the mode <M> are: <ul>
<li><tt>df</tt> (depth-first traversal),</li>
<li><tt>bf</tt> (breadth-first traversal),</li>
<li><tt>mixed</tt> (mixed depth-first / breadth-first traversal with random choice; currently the default),</li>
<li><tt>random</tt> (choosing next node to process completely at random), </li>
<li><tt>hash</tt> (similar to random, but uses the Prolog hash function of a node instead of a random number generator),</li>
<li><tt>heuristic</tt> (try and use <tt>HEURISTIC_FUNCTION</tt> provided by user in <tt>DEFINITIONS</tt> clause). Some explanations can be found [[Blocks_World_(Directed_Model_Checking)|in an example about directed model checking]].</li>
<li><tt>out_degree_hash</tt> (prioritise nodes with fewer outgoing transitions; mainly useful for deadlock checking)
</ul>
|}

Example

probcli my.mch -model_check -mc_mode random

=== --timeout <N> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Global timeout in ms for model checking and refinement checking.
This does not influence the timeout used for computing individual transitions/operations.
This has to be set with the -p TIME_OUT <N>. Note that the <tt>TIME_OUT</tt> preference also influences other computations, such as invariant checking or static assertion checking, where it is multiplied by a factor. See the description of the -p option.
|}

Example

probcli my.mch -timeout 10000

=== -t ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| trace check (associated .trace file must exist)
|}

Example

probcli my.mch -t

=== -init ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| initialise specification
|}

Example

probcli my.mch -init
nr_of_components(1)
% checking_component_properties(1,[])
% enumerating_constants_without_constraints([typedval(fd(_24428,ID),global(ID),iv)])
% grounding_wait_flags
grounding_component(1)
grounding_component(2)
% found_enumeration_of_constants(0,2)
% backtrack(found_enumeration_of_constants(0,2))
% found_enumeration_of_constants(0,1)
% backtrack(found_enumeration_of_constants(0,1))
<- 0: SETUP_CONSTANTS :: root
% Could not set up constants with parameters from trace file.
% Will attempt any possible initialisation of constants.
| 0: SETUP_CONSTANTS success -->0
- <- 1: INITIALISATION :: 0
% Could not initialise with parameters from trace file.
% Will attempt any possible initialisation.
ALL OPERATIONS COVERED
- | 1: INITIALISATION success -->2
- - SUCCESS

=== -cbc <OPNAME> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| constraint-based invariant checking for an operation (also use <OPNAME>=all)
|}

Example

probcli my.mch -cbc all

=== -cbc_deadlock ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Perform constraint-based deadlock checking (also use -cbc_deadlock_pred PRED)
|}

This will try to find a state which satisfies the invariant and properties and where no operation/event is enabled.
Note: if ProB finds a counter example then the machine cannot be proven to be deadlock free. However, the particular state may not be reachable from the initial state(s). If you want to find a reachable deadlock you have to use the model checker.

=== -cbc_deadlock_pred <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based deadlock finding given a predicate
|}

This is like -cbc_deadlock but you provide an additional predicate. ProB will only find deadlocks which also make this predicate true.

Example

probcli my.mch -cbc_deadlock_pred "n=15"

=== -cbc_assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based checking of assertions on constants
|}
This will try and find a solution for the constants which make an assertion (on constants) false.

You can use the extra command <tt>-cbc_output_file FILE</tt> to write the result of this check to a file.
You can also use the extra command <tt>-cbc_option contradiction_check</tt> to ask ProB to check if there is a contradiction in the properties (in case the check did not find a counter-example to the assertions). The extra command <tt>-cbc_option unsat_core</tt> tells ProB to compute the unsatisfiable core in case a proof the assertions was found.
Note that the <tt>TIME_OUT</tt> preference is multiplied by 10 for this command.

There are various variations of this command:
-cbc_assertions_proof
-cbc_assertions_tautology_proof
Both commands do not allow enumeration warnings to occur.
The latter command ignores the PROPERTIES and tries to check whether the ASSERTION(s) are tautologies.
Both commands can be useful to use ProB as a Prover/Disprover (as is done in Atelier-B 4.3).

=== -cbc_sequence <SEQ> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based searching for a sequence of operation names (separated by semicolons)
|}
This will try and find a solution for the constants, initial variable values and parameters which make execution of the given sequence of operations possible.

Example

probcli my.mch -cbc_sequence "op1;op2"

=== -strict ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| raise error and stop probcli if anything unexpected happens, e.g., if model checking finds a counter example or trace checking fails or any unexpected error happens
|}

Example

probcli my.mch -t -strict

=== -expcterr <ERR> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| expect error to occur (<ERR>=cbc,mc,ltl,...)
Tell ProB that you expect a certain error to occur. Mainly useful for regression tests (in conjunction with the -strict option).
|}

Example

probcli examples/B/Benchmarks/CarlaTravelAgencyErr.mch -mc 1000 -expcterr invariant_violation -strict

=== -animate <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| random animation (max Nr steps)
|}

Animates the machine randomly, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-animate_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-animate_all</tt> could run forever.

Example

probcli my.mch -animate 100

=== -execute <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| execution (max Nr steps)
|}

Executes the "first" enabled operation of a machine, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-execute_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-execute_all</tt> could run forever.

In contrast to -animate, -execute will
* always choose the first enabled operation it finds and stop searching for further enabled operations in that state (-animate will compute all enabled operations up to the limit set by the <tt>MAX_OPERATIONS</tt> or <tt>MAX_INITIALISATIONS</tt> preference and then choose randomly); the order of operations in the B machine is thus important for -execute
* not store intermediate states in the state space; as such -execute is faster but after execution one only has access to the first state and the final state of execution

Example

probcli my.mch -execute 100

=== -execute_all===

See <tt>-execute <Nr></tt> above.

=== -det_check ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if every step of the animation is deterministic (i.e., only one operation is possible, and it can only be executed in one possible way as far as parameters and result is concerned).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -animate 100 -det_check

=== -det_constants ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if the SETUP_CONSTANTS step is deterministic (i.e., only one way to set up the constants is possible).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -init -det_constants
=== -his <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save animation history to a file
|}

Save the animation (or model checking) history to a text file. Operations are separated by semicolons.
The output can be adapted using the -his_option command. With -his_option show_states the -his command will also write out all states to the file (in the form of comments before and after operations). With -his_option show_init only the initial state is written out.
The -his command is executed after the -init, -animate, -t or -mc commands.
See also the -sptxt command to only write the current values of variables and constants to a file.

Example

probcli -animate 5 -his history.txt supersimple.mch

Additionally we can have the initialised variables and constants:

probcli -animate 5 -his history.txt -his_option show_init supersimple.mch

And we can have in addition the values of the variables in between (and at the end):

probcli -animate 5 -his history.txt -his_option show_states supersimple.mch

With -his_option trace_file as only option, probcli will write the history in Prolog format, which can later be used by the -t command.

=== -i ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| interactive animation
|}

After performing the other commands, ProB stays in interactive mode and allows the user to manually animate the loaded specification.

Example

probcli my.mch -i

=== -repl ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start interactive read-eval-print-loop
|}

Example

probcli my.mch -p CLPFD TRUE -repl

A list of commands can be obtained by typing <tt>:help</tt> (just help for versions 1.3.x of probcli). The interactive read-eval-print-loop can be exited using <tt>:q</tt> (just typing a return on a blank line for versions 1.3.x of probcli)..
If in addition you want see a graphical representation of the solutions found you can use the following command and open the <tt>out.dot</tt> file using dotty or GraphViz:
probcli -repl -evaldot ~/out.dot

You can also use the <tt>-eval</tt> command to evaluate specific formulas or expressions:
probcli -eval "1+2"
For convenience, these formulas can also be put into a separate file:
probcli -eval_file MyFormula.txt

=== -c ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print coverage statistics
|}

Example

probcli my.mch -mc 1000 -c

You can also use the longer name for the command:

probcli my.mch -mc 1000 --coverage

There is also a version which prints a shorter summary (and which is much faster for large state spaces):

probcli my.mch -mc 1000 --coverage_summary

=== -cc <Nr> <Nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print and check coverage statistics
Print coverage statistics and check that the given number of nodes and transitions have been computed.
|}

Example

probcli my.mch -mc 1000 -cc 10 25

=== -p <PREFERENCE> <VALUE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set <PREFERENCE> to <VALUE>. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

You can also use --pref instead of -p.
Example

probcli my.mch -p TIME_OUT 8000 -p CLPFD TRUE -mc 10000

=== -pref_group <PREFGROUP> <SETTING> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set to the group of preferences <PREFGROUP> to a predefined setting <SETTING>
|}

Example

probcli my.mch -pref_group model_check unlimited

Available groups and settings are:

* PREFERENCE GROUP integer : SETTINGS [int32] : Values for MAXINT and MININT
* PREFERENCE GROUP time_out : SETTINGS [disable_time_out] : To disable TIME_OUT
* PREFERENCE GROUP model_check : SETTINGS [disable_max,unlimited] : Model Checking Limits
* PREFERENCE GROUP dot_colors : SETTINGS [classic,dreams,winter] : Colours for Dot graphs

=== -prefs <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set preferences from preference file <FILE>. The file should be created by the Tcl/Tk version of ProB; this version automatically creates a file called ProB_Preferences.pl. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

Example

probcli my.mch -prefs ProB_Preferences.pl

=== -card <GS> <VAL> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set cardinality (scope in Alloy terminology) of a B deferred set. This overrides the default cardinality (which can be set using <tt>-p DEFAULT_SETSIZE <VAL></tt>).
|}

Example

probcli my.mch -card PID 5

=== -goal <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set GOAL predicate for model checker
|}

Example

probcli my.mch -mc 10000000 -goal "n=18" -strict -expcterr goal_found

=== -scope <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set SCOPE predicate for model checker; states which do not satisfy the SCOPE predicate will be ignored (invariant will not be checked and no outgoing transitions will be computed)
|}

Example

probcli my.mch -mc 10000000 -scope "n<18"

=== -s <PORT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on given port
|}

Example

probcli my.mch ...

=== -ss ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on port 9000
|}

Example

probcli my.mch ...

=== -sf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on some free port
|}

Example

probcli my.mch ...

=== -sptxt <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants and variables to a file
|}

Save the values of constants and variables to a text file in classical B syntax.
The -sptxt command is executed after the -init, -animate, -t or -mc commands.
The values are fully written out (some sets, e.g., infinite sets may be written out symbolically).

See also the -his command.

Example

probcli -animate 5 -sptxt state.txt supersimple.mch

This will write the values of all variables and constants to the file state.txt after animating the machine 5 steps.

=== -cache <DIRECTORY>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants (and in future also variables) to a file to avoid recomputation
|}

This commands saves the values of constants for the current B machine and puts those values into files in the specified directory. The command will also tell ProB to try and reuse constants saved for subsidiary machines (included using SEES for example) whenever possible.
The purpose of the command is to avoid recomputing constants as much as possible, as this can be very time consuming.
This also works for values of variables computed in the initialisation or even using operations.
However, we do not support refinements at the moment.

Note: this command can also be used when starting up the ProB Tcl/Tk version.

=== -logxml <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities and results of probcli in XML format in <LogFile>
|}

A schema declaration file (xsd) can be found at <tt>doc/logxml_xsd.xml</tt> in the ProB [[Download#Sourcecode|Prolog sources]].
The log file contains information about the various commands performed by probcli.
It also contains version information, the parameters provided to probcli and details about the errors that occured.

Example

probcli my.mch -mc 1000 -logxml log.xml

=== -logxml_write_vars <PREFIX> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| after processing other commands (such as -execute) write values of variables having prefix PREFIX in their name into the XML log file (if XML logging has been activated using the -logxml command)
|}

Example

probcli my.mch -execute 1000 -logxml log.xml -logxml_write_vars out

=== -l <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in <LogFile> using Prolog format
|}

Example

probcli my.mch -mc 1000 -l my.log

=== -ll ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in /tmp/prob_cli_debug.log
|}

Example

probcli my.mch -mc 1000 -ll

=== -lg <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| analyse <LogFile> using gnuplot
|}

Example

probcli my.mch ...

=== -pp <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>
|}

Example

probcli my.mch -pp my_pp.mch

=== -ppf <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>, force printing of all type infos
|}

Example

probcli my.mch -ppf my_ppf.mch

=== -v ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set ProB into verbose mode
|}

Example

probcli my.mch -mc 1000 -v

=== -version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print version information
|}

There is also an alternate command called -svers which just prints the version number of ProB.
Example

probcli -version
ProB Command Line Interface
VERSION 1.3.4-rc1 (9556:9570M)
$LastChangedDate: 2011-11-16 18:36:18 +0100 (Wed, 16 Nov 2011) $
Prolog: SICStus 4.2.0 (x86_64-darwin-10.6.0): Mon Mar 7 20:03:36 CET 2011
Application Path: /Users/leuschel/svn_root/NewProB

probcli -svers
VERSION 1.3.4-rc1 (9556:9570M)

You can use <tt>probcli -version -v</tt> to obtain more information about your version of probcli.

=== -check_java_version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check Java and B parser version information
|}

This command is available as of ProB version 1.5.1-beta5 or higher. It can be useful to check that your Java is correctly installed and that the ProB B parser can operate correctly

probcli -check_java_version
Result of checking Java version:
Java is correctly installed and version 1.7.0_55-b13 is compatible with ProB requirements (>= 1.7).
ProB B Java Parser available in version: 2016-02-25 15:27:18.55.

=== -assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check ASSERTIONS of your machine

If you provide the -t switch, the ASSERTIONS will be checked after executing your trace. Otherwise, they will be checked in an initial state.
ProB will automatically initialize the machine if you have not provide the -init or -t switch.

You can also use -main_assertions to check only the ASSERTIONS found in the main file.

If your ASSERTIONS are all static (i.e., make no reference to variables), then ProB will remove all CONSTANTS and PROPERTIES from your machine which are not linked (directly or indirectly) to the ASSERTIONS.
This optimization will only be made if you provide no other switch, such as -mc or -animate which may require the computation of the variables.
|}

Example

probcli my.mch -init -assertions

=== -property ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| virtually add predicate to PROPERTIES
|}

Example

probcli my.mch -property "PRED"

=== -properties ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check PROPERTIES
Note: you should probably first initialise the machine (e.g., with -init).
If the constants have not yet been set up, probcli will debug the properties.
|}

Example

probcli my.mch -init -properties

=== -dot_output <PATH> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| define path for generation of dot files for false properties or assertions
|}

This option is applicable to -properties and -assertions. It will result in individual dot files being generated for every false or unknown property or assertion. Assertions are numbered A0,A1,... and properties P0,P1,... You can also force to generate dot files for all properties (i.e., also the true ones) using the -dot_all command-line flag.

Example

probcli my.mch -init -properties -dot_output somewhere/

This will generate files somewhere/my_P0_false.dot, somewhere/my_P1_false.dot, ...

=== -rc ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| runtime checking of types/pre-/post-conditions
|}

Example

probcli my.mch ...

=== -ltlfile <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL formulas in file <FILE>
|}

Example

probcli my.mch ...

=== -ltlassertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL assertions (in DEFINITIONS)
|}

Example

probcli my.mch ...

=== -ltllimit <LIMIT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| explore at most <LIMIT> states when model-checking LTL
|}

Example

probcli my.mch ...

=== -save <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save state space for later refinement check
|}

Example

probcli my.mch ...

=== -refchk <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| refinement check against previous saved state space
|}

Example

probcli my.mch ...

=== -mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE> ===

Generate test cases for the given specification. Each test case consists of a sequence of operations resp. events (a so-called trace) that
* start in a state after an initialisation
* contain a requested operation/event
* end in a state where the <EndPredicate> is fulfilled

The user can specify what requested operations/events are with the
option [[#-mcm_cover <Operation(s)>|-mcm_cover]].

ProB uses a "breadth-first" approach to search for test cases. When all requested operations/events are covered by test cases within maximum length M, the algorithm will explore the complete state space with that maximum distance M from the initialisation. It outputs all found traces that satisfy the requirements above.

The algorithm stops if either
* it has covered all required operations/events with the current search depth
* or it has reached the maximum search depth or maximum number of explored states.

The required parameters are:
;Depth
: The maximum length of traces that the algorithm searches for test until it stops without covering all required operations/events.
;MaxStates
: The maximum number of explored states until the algorithm stops without covering all required operations/events.
;EndPredicate
: A predicate in B syntax that the last state of a trace must fulfil. If you do not have any restrictions on that state, use a trivially true predicate like '''1=1'''
;FILE
: The found test cases a written to the XML file <FILE>.

Example

probcli my.mch -mcm_tests 10 2000 "EndStateVar=TRUE" testcases.xml -mcm_cover op1,op2

generates test cases for the operations '''op1''' and '''op2''' of the specification '''my.mch'''. The maximum length of traces is 10, at most 2000 states are explored. Each test case ends in a state where the predicate '''EndStateVar=TRUE''' holds. The found test cases are written to a file '''testcases.xml'''.

As of version 1.6.0, the operation arguments are also written to the XML file.
The preference <tt>INTERNAL_ARGUMENT_PREFIX</tt> can be used to provide a prefix for internal operation arguments; any argument/parameter whose name starts with that prefix is considered an internal parameter and not shown in the trace file.
Also, as of version 1.6.0, the non-deterministic initialisations are shown in the XML trace file: all variables and constants where more than one possible initialisation exists are written into the trace file, as argument of an INITIALISATION event.

=== -mcm_cover <Operation(s)> ===

Specify an operation or event that should be covered when generating test cases with the '''-mcm_test''' option. Multiple operations/events can be specified by seperating them by comma or by using '''-mcm_cover''' several times.

See [[#-mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE>|-mcm-tests]] for further details.

=== -spdot <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Write graph of the state space to a dot <FILE>
|}

Example

probcli my.mch -mc 100 -spdot my_statespace.dot

=== -cbc_tests <Depth> <EndPredicate> <File> ===
Generate test cases by constraint solving with maximum
length '''Depth''', the last state satisfies '''EndPredicate'''
and the test cases are written to '''File'''. If the predicate is the empty string we assume truth. If the filename is the empty string no file is generated. See also the page on [[Test_Case_Generation]].

=== -cbc_cover <Operation> ===
When generating CB test cases, '''Operation''' should be covered.
The option can be given multiple times to specify several operations.
Alternatively, multiple operations can be separated by a comma. You can also use the option <pre>-cbc_cover_match PartialName</pre> to match all operations whose name contains PartialName. See also the page about [[Test_Case_Generation]].

=== -test_description <File> ===
Read the options for constraint based test case generation from '''File'''.

=== -bmc <Depth> ===

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Run the [[Bounded_Model_Checking|bounded model checker]] until maximum trace depth <Depth> specified. Looks for invariant violations using the constraint-based test case generation algorithm.
|}

Example

probcli my.mch -bmc 20

=== -csp-guide <File> ===
Use the CSP File '''File''' to guide the B Machine ("CSP||B").
(This feature is included since version 1.3.5-beta7.)

=== -rule_report <File>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Generates rule validation report for rules machines (.rmch) at the specified location <File> for the current animation state. Depending on the file extension an HTML or an XML version of the report is generated (.html/.xml).
|}

Useful in combination with <tt>-execute</tt> or <tt>-execute_all</tt>.

Example

probcli myrules.rmch -execute_all -rule_report my_report.html

== Environment Variables ==

Set NO_COLOR environment variable to disable terminal colors.
See [https://no-color.org https://no-color.org].

== Preferences ==

You can use these preferences within the command:

-p <PREFERENCE> <VALUE>

{| cellpadding="5" cellspacing="1" width="100%" border="1"
!style="background-color:lightgrey;" | <PREFERENCE>
!style="background-color:lightgrey;" | <VALUE>
|-
| MAXINT
| nat ==> MaxInt, used for expressions such as xx::NAT (2147483647 for 4 byte ints)
|-
| MININT
| neg ==> MinInt, used for expressions such as xx::INT (-2147483648 for 4 byte ints)
|-
| DEFAULT_SETSIZE
| nat ==> Size of unspecified deferred sets in SETS section. Will be used if a set s is neither enumerated, has no no card(s)=nr predicate in the PROPERTIES and has no scope_s == Nr DEFINITION.
|-
| MAX_INITIALISATIONS
| nat ==> Max Number of Initialisations and ways to setup constants computed
|-
| MAX_OPERATIONS
| nat ==> Max Number of Enablings per Operation Computed
|-
| ANIMATE_SKIP_OPERATIONS
| bool ==> Animate operations which are skip or PRE C THEN skip
|-
| COMPRESSION
| bool ==> Use more aggressive COMPRESSION when storing states
|-
| EXPAND_CLOSURES_FOR_STATE
| bool ==> Convert lazy form back into explicit form for Variables, Constants, Operation Arguments. ProB will sometimes try to keep certain sets symbolic. If this preference is TRUE then ProB will try to expand those sets for variables and constants after an operation has been executed.
|-
| SYMBOLIC
| bool ==> Lazy expansion of lambdas and set comprehensions. By default ProB will keep certain sets symbolic (e.g., sets it knows are infinite). When this preference is set to TRUE then all set comprehensions and lambda abstractions will at first be kept symbolic and only expanded into explicit form if needed.
|-
| CLPFD
| bool ==> Use CLP(FD) solver for B integers (restricts range to -2^28..2^28-1 on 32 bit computers). Setting this preference to TRUE should substantially improve ProB's ability to solve complicated predicates involving integers. However, it may cause CLP(FD) overflows in certain circumstances.
|-
| SMT
| bool ==> Enable SMT-Mode (aggressive treatment of : and /: inside predicates). With this predicate set to TRUE ProB will be better at solving certain constraint solving tasks. It should be enabled when doing constraint-based invariant or deadlock checking. ProB Tcl/Tk will turn this preference on automatically for those checks.
|-
| STATIC_ORDERING
| bool ==> Use static ordering to enumerate constants which occur in most PROPERTIES first
|-
| SYMMETRY_MODE
| [off,flood,nauty,hash] ==> Symmetry Mode: off,flood,canon,nauty,hash
|-
| TIME_OUT
| nat1 ==> Time out for computing enabled transitions (in ms, is multiplied by a factor for other computations)
|-
| PROOF_INFO
| bool ==> Use Proof Information to restrict invariant checking to affected unproven clauses. Most useful in EventB for models exported from Rodin.
|-
| TRY_FIND_ABORT
| bool ==> Try more aggressively to detect ill-defined expressions (e.g. applying function outside of domain), may slow down animator
|-
| NUMBER_OF_ANIMATED_ABSTRACTIONS
| nat ==> How many levels of refined models are animated by default
|-
| ALLOW_INCOMPLETE_SETUP_CONSTANTS
| bool ==> Allow ProB to proceed even if only part of the CONSTANTS have been found.
|-
| PARTITION_PROPERTIES
| bool ==> Partition predicates (PROPERTIES) into components
|-
| USE_RECORD_CONSTRUCTION
| bool ==> Records: Check if axioms/properties describe a record pattern
|-
| OPERATION_REUSE
| bool ==> Try and reuse previously computed operation effects in B/Event-B
|-
| SHOW_EVENTB_ANY_VALUES
| bool ==> Show top-level ANY variable values of B Operations without parameters as parameters
|-
| RANDOMISE_OPERATION_ORDER
| bool ==> Randomise order of operations when computing successor states
|-
| EXPAND_FORALL_UPTO
| nat ==> When analysing predicates: max. domain size for expansion of forall (use 0 to disable expansion)
|-
| MAX_DISPLAY_SET
| int ==> Max size for pretty-printing sets (-1 means no limit)
|-
| CSP_STRIP_SOURCE_LOC
| bool ==> Strip source location for CSP; will speed up model checking
|-
| WARN_WHEN_EXPANDING_INFINITE_CLOSURES
| int ==> Warn when expanding infinite closures if MAXINT larger than:
|-
| TRACE_INFO
| bool ==> Provide various tracing information on the terminal/console.
|-
| DOUBLE_EVALUATION
| bool ==> Evaluate PREDICATES positively and negatively when analyzing assertions or properties
|-
| RECURSIVE
| bool ==> Lazy expansion of *Recursive* set Comprehensions and lambdas
|-
| IGNORE_HASH_COLLISIONS
| bool ==> Ignore Hash Collisions (if true not all states may be computed, visited states are not memorised !)
|-
| FORGET_STATE_SPACE
| bool ==> Do not remember state space (mainly useful in conjunction with Ignore Hash Collisions)
|-
| NEGATED_INVARIANT_CHECKING
| bool ==> Perform double evaluation (positive and negative) when checking invariants
|-
| CSE
| bool ==> Perform common-sub-expression elimination
|-
| CSE_SUBST
| bool ==> Perform common-sub-expression elimination also for B substitutions
|}

Example

probcli my.mch -p TIME_OUT 5000 -p CLPFD TRUE -p SYMMETRY_MODE hash -mc 1000

== Some probcli examples ==

To load a file My.mch, setup the constants and initialize it do:
<pre>
probcli -init My.mch
</pre>
To load a file M.mch, setup the constants, initialize and then check all assertions with Atelier-B's default values for MININT and MAXINT and an increased timeout of 5 seconds do:
<pre>
probcli -init -assertions -p MAXINT 2147483647 -p MININT -2147483647 -p TIME_OUT 5000 M.mch
</pre>

To fully model check a specification M.mch while tryining to minimize memory consumption do:
<pre>
probcli -model_check -p COMPRESSION TRUE M.mch
</pre>

To model check a specification M.mch while trying to minimize memory consumption further by not storing processed stats and using symmetry reduction (and accepting hash collisions) do:
<pre>
probcli -p COMPRESSION -p IGNORE_HASH_COLLISIONS TRUE -p FORGET_STATE_SPACE TRUE -p SYMMETRY_MODE hash -model_check M.mch
</pre>

== Command-line Arguments for ProB Tcl/Tk ==

Note that the stand-alone Tcl/Tk version also supports a limited form of command-line preferences:
* '''FILE''' (the name/path of the file to be loaded)
* '''-prefs PREF_FILE''' (to use a specific preferences file, rather than the default ProB_Preferences.pl in your home folder)
* '''-batch''' (to instruct ProB not to try to bring up windows, but to print information only to the terminal)
* '''-selfcheck''' (to run the standard unit tests)
* '''-t''' (to perform the Trace Check on the default trace file associated with the specification)
* '''-tcl TCL_Command''' (to run a particular pre-defined Tcl command)
* '''-mc''' (to perform model checking)
* '''-c''' (to compute the coverage)
* '''-ref''' (to perform the default trace refinment check)

However, the comand-line version of ProB, called '''probcli''', provides more features. It also does not depend on Tcl/Tk and can therefore be run on systems without Tcl/Tk.
{{Feedback}}

VisB

2025-04-04T09:10:06Z

Jan Gruteser: /* VisB DEFINITIONS */

'''VisB''' is a visualisation feature of ProB based on SVG graphics and HTML.

Initially VisB was developed for [[ProB2-UI]], the new user interface of ProB based on JavaFX and the ProB2-Java-API.
It is included in ProB2-UI version 1.1.0 and later, which [[Download#ProB2-UI using Java FX|can be downloaded here]].
Users of ProB2-UI version 1.0.0 can [[#Installing the VisB plugin for older ProB2-UI versions|install VisB as a plugin]].
We, however, recommend you use the latest ProB2-UI snapshot.
VisB is constantly being improved and the latest version contains several useful new features.

[[File:ProB2UI_VisB_View.png|center|550px]]

ProB Tcl/Tk and probcli version 1.11.0 and later also support VisB visualisations:

* with <tt>probcli File.mch ... -visb VISBJSONFILE HTMLFILE</tt> you can export the animator's history to a self-contained HTML file including a visualisation of the states in the history
* in ProB Tcl/Tk you can visualise the current state or the history using a VisB visualisation file (it is shown in an external browser) by right clicking in the "State Properties" or the "History" pane.
Hovers work in both cases, but unlike in ProB2-UI, you cannot click to perform events.

An article about VisB has been [https://rdcu.be/b4rqh published in the ABZ'2020 proceedings].

== Using VisB ==

In current versions of [[ProB2-UI]] the VisB view is automatically shown in the center pane below the state view.
To start VisB in older versions of [[ProB2-UI]], choose the "Open VisB" command in the Visualisation menu,
or right-click in the "State Properties" pane of ProB Tcl/Tk and select "View Current State in VisB".

You can now choose a JSON file which builds on top of a SVG graphics file (more recent versions of VisB can also load visualisations from [[VisB#VisB_DEFINITIONS|definitions]].
The JSON file contains a reference to a SVG file, along with entries to modify attributes based on the current state of a B model and entries which specify how VisB should react to clicks on the SVG. The SVG file should contain object ids which are referenced in the JSON file.

Here is a sample file:
<pre>
{
"svg":"Train2.svg",
"items":[
{
"id":"Train1_rect",
"attr":"visibility",
"value":"IF 1:TRAIN THEN \"visible\" ELSE \"hidden\" END"
},
{
"id":"Train1_rect",
"attr":"fill",
"value":"IF train_speed(1)>0 THEN \"blue\" ELSE \"orange\" END"
},
{
"id":"Train1_rect",
"attr":"x",
"value":"train_back_loc(1)*10+20"
},
{
"id":"Train1_rect",
"attr":"width",
"value":"train_length(1)*10"
}
],
"events":[
{
"id":"Train1_rect",
"event":"Train_Move1",
"predicates":[
"1=1"
]
}
]
}
</pre>

== VisB Attributes ==

At the top-level a VisB JSON file contains these attributes:
* svg
* model-name
* include
* svg_objects
* definitions
* items
* events

Below we explain them in more detail.

=== SVG file and inclusion ===

The main VisB Json file should contain an <tt>svg</tt> attribute with a
relative or absolute path to the SVG file to be shown.

The <tt>model-name</tt> attribute is optional; if set ProB will emit
a warning if the B model's name does not match the value of this attribute.

One can also include subsidiary VisB Json files using the <tt>include</tt>
attribute with again a relative or absolut path to another Json file:

<pre>
{
"svg":"my_svg_file.svg",
"include":"subsidiary_visb_file.json",
"items":[
...
}
</pre>

The svg attribute in subsidiary files will be ignored.
You can override the VisB items in the included file (i.e., a VisB item for an id and attribute in the top-level file will override items for the same id and attribute in the included files).

=== Items and Events ===

For VisB <tt>items</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>attr</tt> a valid SVG attribute
* <tt>value</tt> a B formula which will be evaluated in the current state of a model and yields a new value for the above attribute.

Note that the formula can make use of the [[Summary_of_B_Syntax#Reals |REAL datatype]] and also use many of the [[External_Functions|external functions]] e.g. from LibraryStrings or LibraySVG.
Here is an example VisB Item:
<pre>
"items":[
{
"id": "train1_rect",
"attr": "x",
"value":"100.0 + train_left(train1)"
} ]
</pre>
As of version 1.12.2, ProB allows you to use a single attribute whose name is the SVG attribute being set, rather than two attributes (attr, value).
With this you can set multiple SVG attributes in one VisB item.
For example, you can now write:
<pre>
"items":[
{
"id": "train1_rect",
"x":"100.0 + train_left(train1)",
"y":"20.0 + train_bottom(train1)"
} ]
</pre>

For VisB <tt>events</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>event</tt> a valid B operation or event of the loaded formal model
* <tt>predicates</tt> an optional list of B predicates, which can be used to set parameters of the B operation that is executed upon a click

Additionally VisB now recognises for both items and events:

* <tt>ignore</tt>, if this attribute is present the item will be ignored
* <tt>repeat</tt>, if this attribute is present the item will be replicated (see below). This construct requires a list of strings.
* <tt>for</tt>, if this attribute is present the item will be replicated (see below). The for construct requires <tt>from</tt> and <tt>to</tt> with integer values as sub arguments. As of version 1.11.1 you can also use constant B integer expressions accessing just the sets.
* <tt>optional</tt>, if this boolean attribute is <tt>true</tt> an event will be ignored if the event name is not a valid top-level event/operation in the model. An item will be ignored if the identifiers in the formula do not exists (i.e., errors during type checking will be ignored)
* <tt>override</tt>, if this boolean attribute is <tt>true</tt> no warnings will be generated if another VisB item for the same attribute and id is overriden (as of version 1.11.1)

Other attributes will be ignored. E.g, one can use a <tt>comment</tt> attribute to add comments to the VisB items.

When executing an event, VisB now performs the following replacements within the predicates of the event:
* <tt>%shiftKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%metaKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%pageX</tt> is replaced by the x coordinate of the click relative to the top-left of the entire VisB SVG
* <tt>%pageY</tt> is replaced by the y coordinate of the click relative to the top-left of the entire VisB SVG

Finally, VisB events can be associated with mouse hover actions.
For this you just need to add an attribute <tt>hovers</tt> which contains a list of JSON objects with the following attributes:
* <tt>id</tt>, this is the identifier of an object in the associated SVG file; this attribute is optional; if it is not present the id specified in the VisB event will be used.
* <tt>attr</tt> a valid SVG attribute
* <tt>enter</tt> a value which will be used when the mouse enters the area of the object
* <tt>leave</tt> a value which will be used to restore the attribute when the mouse leaves the area
Note that the enter and leave values have to be static at the moment; in future we plan to allow B formulas here and also apply the repetition/replacement mechanism specified above.
If you just wish to attach a hover to an SVG object (and no B operation/event) you can set the event field of the VisB event to the empty string (<tt>"event":""</tt>).
You should not use attributes for the hover which are set by VisB items.

Here is an example VisB event with hovers:
<pre>
{
"id": "button",
"event": "toggle_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"},
{ "attr":"opacity", "enter":"0.8", "leave":"1.0"}]
}
</pre>

A VisB event can now also contain an list of items with the attributes <tt>id</tt>, <tt>attr</tt>, <tt>enabled</tt> and <tt>disabled</tt>.
When the associated event is enabled, the attribute of the SVG object with the given id is set to the value provided in the enabled attribute, otherwise the disabled attribute value is used.
As above the item id is optional and defaults to the id of the VisB event.
Here is an example VisB event with hovers and an items list:
<pre>
{
"id": "button",
"event": "press_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"}],
"items": [{"attr":"fill", "disabled":"\"green\"", "enabled":"\"red\""}]
},
</pre>

== Replication / Loops ==

You can use the <tt>repeat</tt> and <tt>for</tt> attributes to replicate a VisB
item or event.
Replication consists in duplicating the item or event, and replacing <tt>%0</tt> within the identifier and value attributes of the time with the repeated string or integer.

For example, the repeat instruction below will result in the creation of three VisB items, one for id <tt>txt_ttd1</tt>, for <tt>txt_ttd2</tt>, and one for <tt>txt_ttd3</tt>.
The value formula for <tt>txt_ttd1</tt> is <tt>"IF 1: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"</tt>.
<pre>
{
"repeat": ["1","2","3"],
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>

A for loop can be used instead for the above example as follows:
<pre>
{
"for": {"from":1, "to":3},
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>
The for loop also allows an optional <tt>step</tt> attribute.

It is possible to apply both <tt>repeat</tt> and <tt>for</tt> attributes at the same time, as this example shows.
(The exact details of multiple iterations for a VisB item might change in future.)

<pre>
{
"repeat": [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20],
"for": {"from":1, "to":20},
"id": "tile%1x%0",
"event": "TryQueen",
"hovers": [{ "attr":"opacity", "enter":"0.5", "leave":"1"}],
"predicates" : ["i=%1","j=%0"]
}
</pre>

As of version 1.11.0 you can also use nested for loops.
As of version 1.11.1 of ProB you can also use B expressions for the <tt>from</tt>, <tt>to</tt> and <tt>step</tt> attributes of a for loop.
However, these expressions must be evaluable without having access to any constants or variables. Indeed, the for and repeat loops are processed once when loading a VisB file, independently of any given state.
So, you can only access identifiers of <tt>SETS</tt> section of a B machine.
It may still be useful, e.g., to iterate over an enumerated or deferred set (TRAINS below):

<pre>
{
"for": {"from":1, "to":"card(TRAINS)"},
...
}
</pre>

The <tt>INT_TO_ENUM</tt> external function available as of ProB 1.11.1 can be useful in expressions here to convert the iteration variable back to an enumerated or deferred set element.
For example, <tt>INT_TO_ENUM(TRAINS,1)</tt> refers to the first element of the set <tt>TRAINS</tt>.

== VisB Definitions (in JSON file) ==

As of ProB Tcl/Tk 1.11.0 it is possible to include local definitions in the VisB JSON file.
Each definition has a name and a value formula.
Definitions are evaluated in order of appearance (a later definition can thus refer to an ealier one) and are evaluated in a state before evaluating VisB items.

<pre>
"definitions":[
{ "name":"xscale",
"value" : "(100.0 / real(NrOfTrackElements))"
},
{ "name":"visb_train_rear",
"value" : "%x.(x:dom(train_rear)|xscale * real(train_rear(x)))"
}]
</pre>

The VisB definitions are particularly useful for Event-B models (as you can use [[Summary_of_B_Syntax#Reals |REAL numbers]] and also have access to [[External_Functions|external functions]] such as LibraryStrings or LibraySVG).
But they are not yet available for events in ProB2-UI.

== VisB Additional SVG Objects ==

As of version 1.12.0 of ProB Tcl/Tk you can add new SVG objects to your SVG file.
You can use for and repeat loops (see above) to create an arbitrary number of objects.
This is useful for making flexible visualisations which work with an arbitrary number
of objects.
The same rules and limitations for for/repeat loops apply as for items above.

Every entry in the svg_objects list
* an <tt>svg_class</tt> attribute, which can be, e.g., line, circle, rect, ...
* an object <tt>id</tt> attribute
* an optional <tt>comment</tt> attribute
* any other attribute will be used to create the SVG object and should be valid for the specified svg_class

Here is an example (taken from [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/blob/master/Physics/n_bodies_visb.json here]) where NOBJS is a DEFINITION inside a B machine:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"NOBJS"},
"svg_class":"circle",
"id":"body%0",
"cx":"45",
"cy":"15",
"r":"10",
"stroke":"black",
"stroke-width":"0.5",
"fill":"green"
} ]
</pre>

Here is another example where TRAINS is a deferred or enumerated set of the B model being visualised:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"card(TRAINS)"},
"svg_class":"rect",
"id":"fresh_train_rect%0",
"x":"0",
"y":"0",
"height":"10",
"width":"20",
"comment":"train current position rectangle"
}
]
</pre>

== VisB DEFINITIONS ==
As of version 1.12 you can also provide many of the VisB annotations via B DEFINITIONS.
This can be done in addition to a VisB JSON file or completely replacing the JSON file.

By adding this definition to your B machine you specify that you wish to use an empty
SVG file as base:
<pre>
VISB_JSON_FILE == "";
</pre>

With a VISB_SVG_BOX definition you can set the size of the generated empty SVG file:
<pre>
VISB_SVG_BOX == rec(height:floor(vscale)*25+20, width:1800);
</pre>
Note: you can also provide an optional <tt>viewBox</tt> attribute as a B string.

Via VISB_SVG_CONTENTS definitions you can add new textual content to the base SVG file:
<pre>
VISB_SVG_CONTENTS == '''
<defs>
...
```;
</pre>

With definitions starting with with VISB_SVG_OBJECTS you can add new SVG objects:
<pre>
VISB_SVG_OBJECTS1 == rec(`svg_class`:"rect",`id`:"i1",x:20,y:20,height:20,width:20,fill:"blue");
VISB_SVG_OBJECTS2 == rec(`svg_class`:"circle",`id`:"i2",cx:30,cy:30,r:20,fill:"red");
</pre>
Each definition can either add a single record or add a set of records in one go.
The definition should only depend on base sets or constants of the model (see, however, notes for ProB 1.13.0 or later below).
In addition the constants used in the above definitions should only have one possible value.
For example, suppose that the constant P has 5 elements then this will create 5 SVG lines.
Observe that we use the new Event-B-style set comprehension for convenience and that tuples can be used for the <tt>id</tt> field..
<pre>
VISB_SVG_OBJECTS3 == {i•i:P|rec(`svg_class`:"line",`id`:("line",i),x1:0,y1:i,x2:i,y2:i)};
</pre>

Similarly, you can use VISB_SVG_UPDATES definitions to specify attributes that depend on the
value of constants and variables of the animated B model:
<pre>
VISB_SVG_UPDATES1== rec(`id`:"i2",fill: IF x>0 THEN "red" ELSE "green" END);
</pre>

Hovers can be defined using VISB_SVG_HOVER definitions (only for objects that have been created with VISB_SVG_OBJECTS) and click events can be defined using
VISB_SVG_EVENTS definitions with attributes <tt>id</tt>, <tt>event</tt> and optionally <tt>predicate</tt>.
Here is a minimal example that just uses the VisB DEFINITIONS without any external JSON or SVG file:
<pre>
MACHINE button_def
// An example that uses VisB DEFINITIONS instead of a JSON and SVG file
DEFINITIONS
VISB_JSON_FILE == "";
VISB_SVG_BOX == rec(height:200, width:240);
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:"100",cy:"100", r:"80", stroke:"black", `stroke-width`:"3");
VISB_SVG_UPDATES == rec(`id`:"button",
fill: IF button=TRUE THEN "green" ELSE "red" END);
VISB_SVG_HOVERS == rec(`id`:"button",
stroke:"gray", `stroke-width`:"5");
VISB_SVG_EVENTS == rec(`id`:"button", event:"toggle_button", predicate:"btrue")
VARIABLES button
INVARIANT button:BOOL
INITIALISATION button := FALSE
OPERATIONS
toggle_button = BEGIN
button:= bool(button=FALSE)
END
END
</pre>

As of version 1.13.0 of ProB you can also use dynamic expressions in object definitions; the above definitions can thus be written more compactly:
<pre>
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:100,cy:100, r:80, stroke:"black", `stroke-width`:3,
fill: IF button=TRUE THEN "green" ELSE "red" END,
event:"toggle_button",
hovers: rec(stroke:"gray", `stroke-width`:"5"));
</pre>

In 1.13.0 you can also use a "children" attribute to specify groups.
The children attribute should evaluate to a set of strings pointing to ids of SVG objects.
The following example shows this for for defining the children of "mygroup".
Also observe the use of the new [[Summary_of_B_Syntax#Strings:|template string syntax]] for the transform attribute.
<pre>
VISB_SVG_FILE == "";
VISB_SVG_BOX == rec(height:400, width:450);
VISB_SVG_OBJECTS1 == {i•i:0..9|rec(`id`:("r",i), svg_class:"rect",
fill:IF i=x THEN "red" ELSE "green" END,
x:10+10*i, y:100, height:20, width:4)};
VISB_SVG_OBJECTS2 == rec(`id`:"mygroup", svg_class:"g",
children: {i•i:0..9|("r",i)},
transform:```rotate(${x*40},50,100)```
)
</pre>

Version 1.13.1 also adds a new virtual <tt>title</tt> attribute that can be set in such SVG_OBJECTS.
This will create a tooltip box displaying the value of the attribute. (Internally this gets transformed into children SVG title objects.) These tooltips are independent of the other VisB hovers (and in contrast to these hovers the value of the title attribute can be dynamic, i.e., depend on the model's variables).

In VisB event predicates, the local identifier <tt>VISB_CLICK_META_INFOS</tt> can be used to access information like shift or command key presses and mouse positions during a click. It represents a record of the following type:
<pre>
struct(altKey: BOOL,
ctrlKey: BOOL,
jsVars: STRING <-> STRING,
metaKey: BOOL,
pageX: INTEGER,
pageY: INTEGER,
shiftKey: BOOL
)
</pre>

It also enables usage of JavaScript values: <tt>VISB_CLICK_META_INFOS'jsVars("MYID")</tt>. The value must first be assigned in a <tt>script</tt> tag in the SVG using <tt>visb_vars["MYID"]</tt>.

== Examples ==

Some examples can be found in the [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples visb-visualisation-examples] repository.
We have a small [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel/-/blob/master/notebooks/manual/VisB_Features.ipynb Jupyter notebook manual] on the DEFINITION features of VisB.
More details and examples will be added later.

== Caveats ==

* Beware that you need to escape quotation marks and slashes in the JSON file for fields containing B expressions. Also, you cannot use newline.
* Hovers are currently evaluated once statically and cannot make use of B expressions. To make hover information dependent on the state, use the visibility attribute to make hidden SVG objects (which can be adapted depending on the state using VisB items) visible. The [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] illustrates this idea.

== Tips and Tricks ==

It is sometimes useful to use simple coordinates for your VisB items and B expressions, e.g. x coordinates of 0..100.
You can quite often do this and use the SVG transform attribute to scale and move the SVG object to the right place.
The simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
In essence your SVG file can contain this:
<pre>
<polygon id = "ttd_polyline"
points="0,0 100,0"
stroke="gray" fill="none"
transform="translate(10,22.5)" />
</pre>
and the VisB JSON file contains this, making use of LibrarySVG.def (automatically available) external function svg_axis:
<pre>
{
"id":"ttd_polyline",
"attr":"points",
"value":"svg_axis({0} \\/ ran(%tt.(tt:TTDS|1+max(TTD_TrackElements(tt)))),100.0/real(TrackElementNumber+1),100.0,2.0)",
"comment":"show ticks for TTD Limits"
},
</pre>

Observe that we had to escape the slash of the union operator.
Also observe, that we are able to use [[Summary_of_B_Syntax#Reals:|floating numbers]] in the new version of ProB, which is very useful for VisB visualisations.

It can be useful to use style and class to make it easier to change your color scheme or other styling attributes within your visualisation consistently.
Again, the simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
E.g., your SVG file could contain towards the top this definition:
<pre>
<style id="style_ttd_ts_mp">
.ttd {
stroke : none;
stroke-width: 0.2;
opacity: 0.7
}
.red-occupied-ttd {
fill : red
}
</style>
</pre>
Later you can then use it to style your objects:
<pre>
<polygon id = "occupied_ttd_polygon"
points="0,0 0,2 10,2 10,0 70,0 70,1 90,1 90,0"
class = "ttd red-occupied-ttd"
transform="translate(10,23)" />
</pre>

You can then modify the class using VisB items. Classes can also be useful for hovers, by simply exchanging one style for another when the mouse is over an objects (again, see [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train the train example]).
Recent versions of ProB also support adding and removing a class, which is useful for hovers when the class is modified by VisB items:
<pre>
{
"id":"train_polygon_tr1",
"event":"TrainMoveForward",
"hovers": [{ "attr":"class", "enter":"+train-hover", "leave":"-train-hover"}]
}
</pre>

== Debugging and HTML Export ==

In classical B models you can store your default VisB visualisation in the DEFINITIONS section:
<pre>
DEFINITIONS
VISB_JSON_FILE == "TwoTrains.json"
</pre>

For debugging it can be useful to use VisB within ProB Tcl/Tk: if you choose to visualise the current state with VisB, ProB will generate a stand-alone HTML file which is opened in a browser.
In the browser you can open the (Javascript) developer console and you will be alerted to warnings and errors (which unfortunately, are currently not shown in ProB2-UI).
Upon changing the state in the animator, the HTML file will be regenerated and the VisB file re-loaded if necessary.
The HTML export also displays hovers, but cannot react to clicks.
The HTML export is also available in ProB2-UI (in the export menu in the top-right corner).

ProB can also export the entire animation history to a standalone HTML file that can be passed to other persons (without requiring access to the B model or to ProB).
In ProB Tcl/Tk you can right-click on the history pane and choose "View History in VisB".
In probcli you can use the command <tt>-visb JSONFILE HTMLFILE</tt> to export the history.
In ProB2-UI you can click on the export icon in the upper right hand corner:

[[File:ProB2UI_VisB_View_Export.png|center|550px]]

The ProB2-UI table visualisation view (Visualisation menu) also contains tables to help debug VisB items and events:

[[File:ProB2UI_VisB_Debug_Table_View.png|center|550px]]

This view is also available in ProB Tcl/Tk in the Visualize menu (States submenu).
ProB2-UI also has another inspection view that can be obtained by clicking on the "i" (info) icon in the the VisB toolbar.

=== Using the VisB exported HTML file ===

You should be able to open the exported HTML using a regular browser.
Within the web page (see the image below) you can then do the following:
* single step through the trace by clicking the "Forward" and "Backward" buttons, or clicking on individual steps of the trace
* execute the entire trace nd see changes to the visualisation by clicking one of the "Run Trace" buttons
* you can inspect the value of the sets, constants and variables at every step by expanding the corresponding tabs
Some meta information can be found at the bottom of the trace.

[[File:ProB2UI_VisB_View_ExportedHTML.png|center|550px]]

== Citing VisB ==
This is the Bibtex entry for an article about VisB [https://rdcu.be/b4rqh in the ABZ'2020 proceedings]:
<pre>
@inproceedings{WerthLeuschel:abz2020,
author = {Michelle Werth and Michael Leuschel},
title = {{VisB}: A Lightweight Tool to Visualize Formal Models with {SVG} Graphics},
booktitle = {Proceedings ABZ 2020},
editor="Raschke, Alexander and M{\'e}ry, Dominique and Houdek, Frank",
year = {2020},
series = {LNCS 12071},
pages = "260--265",
isbn="978-3-030-48077-6"
}
</pre>

== Installing the VisB plugin for older ProB2-UI versions ==

'''Note:''' The following instructions are for ProB2-UI version 1.0.0 '''only'''. On current versions of ProB2-UI (1.1.0 and later), VisB is included by default and '''does not need to be installed separately'''.

To install the VisB plugin in ProB2-UI 1.0.0 you need to:

# [https://www3.hhu.de/stups/downloads/prob2/plugins/VisB-1.0.0.jar Download the VisB plugin jar file].
# In the "Advanced" menu of ProB2-UI, choose "Plugin Menu".
# Click on the "Add Plugin..." button.
# Select the VisB jar file that you have downloaded.
# Choose the "Open VisB" command in the Advanced menu to start VisB.

VisB

2025-04-04T07:35:03Z

Jan Gruteser: /* VisB DEFINITIONS */

'''VisB''' is a visualisation feature of ProB based on SVG graphics and HTML.

Initially VisB was developed for [[ProB2-UI]], the new user interface of ProB based on JavaFX and the ProB2-Java-API.
It is included in ProB2-UI version 1.1.0 and later, which [[Download#ProB2-UI using Java FX|can be downloaded here]].
Users of ProB2-UI version 1.0.0 can [[#Installing the VisB plugin for older ProB2-UI versions|install VisB as a plugin]].
We, however, recommend you use the latest ProB2-UI snapshot.
VisB is constantly being improved and the latest version contains several useful new features.

[[File:ProB2UI_VisB_View.png|center|550px]]

ProB Tcl/Tk and probcli version 1.11.0 and later also support VisB visualisations:

* with <tt>probcli File.mch ... -visb VISBJSONFILE HTMLFILE</tt> you can export the animator's history to a self-contained HTML file including a visualisation of the states in the history
* in ProB Tcl/Tk you can visualise the current state or the history using a VisB visualisation file (it is shown in an external browser) by right clicking in the "State Properties" or the "History" pane.
Hovers work in both cases, but unlike in ProB2-UI, you cannot click to perform events.

An article about VisB has been [https://rdcu.be/b4rqh published in the ABZ'2020 proceedings].

== Using VisB ==

In current versions of [[ProB2-UI]] the VisB view is automatically shown in the center pane below the state view.
To start VisB in older versions of [[ProB2-UI]], choose the "Open VisB" command in the Visualisation menu,
or right-click in the "State Properties" pane of ProB Tcl/Tk and select "View Current State in VisB".

You can now choose a JSON file which builds on top of a SVG graphics file (more recent versions of VisB can also load visualisations from [[VisB#VisB_DEFINITIONS|definitions]].
The JSON file contains a reference to a SVG file, along with entries to modify attributes based on the current state of a B model and entries which specify how VisB should react to clicks on the SVG. The SVG file should contain object ids which are referenced in the JSON file.

Here is a sample file:
<pre>
{
"svg":"Train2.svg",
"items":[
{
"id":"Train1_rect",
"attr":"visibility",
"value":"IF 1:TRAIN THEN \"visible\" ELSE \"hidden\" END"
},
{
"id":"Train1_rect",
"attr":"fill",
"value":"IF train_speed(1)>0 THEN \"blue\" ELSE \"orange\" END"
},
{
"id":"Train1_rect",
"attr":"x",
"value":"train_back_loc(1)*10+20"
},
{
"id":"Train1_rect",
"attr":"width",
"value":"train_length(1)*10"
}
],
"events":[
{
"id":"Train1_rect",
"event":"Train_Move1",
"predicates":[
"1=1"
]
}
]
}
</pre>

== VisB Attributes ==

At the top-level a VisB JSON file contains these attributes:
* svg
* model-name
* include
* svg_objects
* definitions
* items
* events

Below we explain them in more detail.

=== SVG file and inclusion ===

The main VisB Json file should contain an <tt>svg</tt> attribute with a
relative or absolute path to the SVG file to be shown.

The <tt>model-name</tt> attribute is optional; if set ProB will emit
a warning if the B model's name does not match the value of this attribute.

One can also include subsidiary VisB Json files using the <tt>include</tt>
attribute with again a relative or absolut path to another Json file:

<pre>
{
"svg":"my_svg_file.svg",
"include":"subsidiary_visb_file.json",
"items":[
...
}
</pre>

The svg attribute in subsidiary files will be ignored.
You can override the VisB items in the included file (i.e., a VisB item for an id and attribute in the top-level file will override items for the same id and attribute in the included files).

=== Items and Events ===

For VisB <tt>items</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>attr</tt> a valid SVG attribute
* <tt>value</tt> a B formula which will be evaluated in the current state of a model and yields a new value for the above attribute.

Note that the formula can make use of the [[Summary_of_B_Syntax#Reals |REAL datatype]] and also use many of the [[External_Functions|external functions]] e.g. from LibraryStrings or LibraySVG.
Here is an example VisB Item:
<pre>
"items":[
{
"id": "train1_rect",
"attr": "x",
"value":"100.0 + train_left(train1)"
} ]
</pre>
As of version 1.12.2, ProB allows you to use a single attribute whose name is the SVG attribute being set, rather than two attributes (attr, value).
With this you can set multiple SVG attributes in one VisB item.
For example, you can now write:
<pre>
"items":[
{
"id": "train1_rect",
"x":"100.0 + train_left(train1)",
"y":"20.0 + train_bottom(train1)"
} ]
</pre>

For VisB <tt>events</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>event</tt> a valid B operation or event of the loaded formal model
* <tt>predicates</tt> an optional list of B predicates, which can be used to set parameters of the B operation that is executed upon a click

Additionally VisB now recognises for both items and events:

* <tt>ignore</tt>, if this attribute is present the item will be ignored
* <tt>repeat</tt>, if this attribute is present the item will be replicated (see below). This construct requires a list of strings.
* <tt>for</tt>, if this attribute is present the item will be replicated (see below). The for construct requires <tt>from</tt> and <tt>to</tt> with integer values as sub arguments. As of version 1.11.1 you can also use constant B integer expressions accessing just the sets.
* <tt>optional</tt>, if this boolean attribute is <tt>true</tt> an event will be ignored if the event name is not a valid top-level event/operation in the model. An item will be ignored if the identifiers in the formula do not exists (i.e., errors during type checking will be ignored)
* <tt>override</tt>, if this boolean attribute is <tt>true</tt> no warnings will be generated if another VisB item for the same attribute and id is overriden (as of version 1.11.1)

Other attributes will be ignored. E.g, one can use a <tt>comment</tt> attribute to add comments to the VisB items.

When executing an event, VisB now performs the following replacements within the predicates of the event:
* <tt>%shiftKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%metaKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%pageX</tt> is replaced by the x coordinate of the click relative to the top-left of the entire VisB SVG
* <tt>%pageY</tt> is replaced by the y coordinate of the click relative to the top-left of the entire VisB SVG

Finally, VisB events can be associated with mouse hover actions.
For this you just need to add an attribute <tt>hovers</tt> which contains a list of JSON objects with the following attributes:
* <tt>id</tt>, this is the identifier of an object in the associated SVG file; this attribute is optional; if it is not present the id specified in the VisB event will be used.
* <tt>attr</tt> a valid SVG attribute
* <tt>enter</tt> a value which will be used when the mouse enters the area of the object
* <tt>leave</tt> a value which will be used to restore the attribute when the mouse leaves the area
Note that the enter and leave values have to be static at the moment; in future we plan to allow B formulas here and also apply the repetition/replacement mechanism specified above.
If you just wish to attach a hover to an SVG object (and no B operation/event) you can set the event field of the VisB event to the empty string (<tt>"event":""</tt>).
You should not use attributes for the hover which are set by VisB items.

Here is an example VisB event with hovers:
<pre>
{
"id": "button",
"event": "toggle_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"},
{ "attr":"opacity", "enter":"0.8", "leave":"1.0"}]
}
</pre>

A VisB event can now also contain an list of items with the attributes <tt>id</tt>, <tt>attr</tt>, <tt>enabled</tt> and <tt>disabled</tt>.
When the associated event is enabled, the attribute of the SVG object with the given id is set to the value provided in the enabled attribute, otherwise the disabled attribute value is used.
As above the item id is optional and defaults to the id of the VisB event.
Here is an example VisB event with hovers and an items list:
<pre>
{
"id": "button",
"event": "press_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"}],
"items": [{"attr":"fill", "disabled":"\"green\"", "enabled":"\"red\""}]
},
</pre>

== Replication / Loops ==

You can use the <tt>repeat</tt> and <tt>for</tt> attributes to replicate a VisB
item or event.
Replication consists in duplicating the item or event, and replacing <tt>%0</tt> within the identifier and value attributes of the time with the repeated string or integer.

For example, the repeat instruction below will result in the creation of three VisB items, one for id <tt>txt_ttd1</tt>, for <tt>txt_ttd2</tt>, and one for <tt>txt_ttd3</tt>.
The value formula for <tt>txt_ttd1</tt> is <tt>"IF 1: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"</tt>.
<pre>
{
"repeat": ["1","2","3"],
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>

A for loop can be used instead for the above example as follows:
<pre>
{
"for": {"from":1, "to":3},
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>
The for loop also allows an optional <tt>step</tt> attribute.

It is possible to apply both <tt>repeat</tt> and <tt>for</tt> attributes at the same time, as this example shows.
(The exact details of multiple iterations for a VisB item might change in future.)

<pre>
{
"repeat": [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20],
"for": {"from":1, "to":20},
"id": "tile%1x%0",
"event": "TryQueen",
"hovers": [{ "attr":"opacity", "enter":"0.5", "leave":"1"}],
"predicates" : ["i=%1","j=%0"]
}
</pre>

As of version 1.11.0 you can also use nested for loops.
As of version 1.11.1 of ProB you can also use B expressions for the <tt>from</tt>, <tt>to</tt> and <tt>step</tt> attributes of a for loop.
However, these expressions must be evaluable without having access to any constants or variables. Indeed, the for and repeat loops are processed once when loading a VisB file, independently of any given state.
So, you can only access identifiers of <tt>SETS</tt> section of a B machine.
It may still be useful, e.g., to iterate over an enumerated or deferred set (TRAINS below):

<pre>
{
"for": {"from":1, "to":"card(TRAINS)"},
...
}
</pre>

The <tt>INT_TO_ENUM</tt> external function available as of ProB 1.11.1 can be useful in expressions here to convert the iteration variable back to an enumerated or deferred set element.
For example, <tt>INT_TO_ENUM(TRAINS,1)</tt> refers to the first element of the set <tt>TRAINS</tt>.

== VisB Definitions (in JSON file) ==

As of ProB Tcl/Tk 1.11.0 it is possible to include local definitions in the VisB JSON file.
Each definition has a name and a value formula.
Definitions are evaluated in order of appearance (a later definition can thus refer to an ealier one) and are evaluated in a state before evaluating VisB items.

<pre>
"definitions":[
{ "name":"xscale",
"value" : "(100.0 / real(NrOfTrackElements))"
},
{ "name":"visb_train_rear",
"value" : "%x.(x:dom(train_rear)|xscale * real(train_rear(x)))"
}]
</pre>

The VisB definitions are particularly useful for Event-B models (as you can use [[Summary_of_B_Syntax#Reals |REAL numbers]] and also have access to [[External_Functions|external functions]] such as LibraryStrings or LibraySVG).
But they are not yet available for events in ProB2-UI.

== VisB Additional SVG Objects ==

As of version 1.12.0 of ProB Tcl/Tk you can add new SVG objects to your SVG file.
You can use for and repeat loops (see above) to create an arbitrary number of objects.
This is useful for making flexible visualisations which work with an arbitrary number
of objects.
The same rules and limitations for for/repeat loops apply as for items above.

Every entry in the svg_objects list
* an <tt>svg_class</tt> attribute, which can be, e.g., line, circle, rect, ...
* an object <tt>id</tt> attribute
* an optional <tt>comment</tt> attribute
* any other attribute will be used to create the SVG object and should be valid for the specified svg_class

Here is an example (taken from [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/blob/master/Physics/n_bodies_visb.json here]) where NOBJS is a DEFINITION inside a B machine:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"NOBJS"},
"svg_class":"circle",
"id":"body%0",
"cx":"45",
"cy":"15",
"r":"10",
"stroke":"black",
"stroke-width":"0.5",
"fill":"green"
} ]
</pre>

Here is another example where TRAINS is a deferred or enumerated set of the B model being visualised:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"card(TRAINS)"},
"svg_class":"rect",
"id":"fresh_train_rect%0",
"x":"0",
"y":"0",
"height":"10",
"width":"20",
"comment":"train current position rectangle"
}
]
</pre>

== VisB DEFINITIONS ==
As of version 1.12 you can also provide many of the VisB annotations via B DEFINITIONS.
This can be done in addition to a VisB JSON file or completely replacing the JSON file.

By adding this definition to your B machine you specify that you wish to use an empty
SVG file as base:
<pre>
VISB_JSON_FILE == "";
</pre>

With a VISB_SVG_BOX definition you can set the size of the generated empty SVG file:
<pre>
VISB_SVG_BOX == rec(height:floor(vscale)*25+20, width:1800);
</pre>
Note: you can also provide an optional <tt>viewBox</tt> attribute as a B string.

Via VISB_SVG_CONTENTS definitions you can add new textual content to the base SVG file:
<pre>
VISB_SVG_CONTENTS == '''
<defs>
...
```;
</pre>

With definitions starting with with VISB_SVG_OBJECTS you can add new SVG objects:
<pre>
VISB_SVG_OBJECTS1 == rec(`svg_class`:"rect",`id`:"i1",x:20,y:20,height:20,width:20,fill:"blue");
VISB_SVG_OBJECTS2 == rec(`svg_class`:"circle",`id`:"i2",cx:30,cy:30,r:20,fill:"red");
</pre>
Each definition can either add a single record or add a set of records in one go.
The definition should only depend on base sets or constants of the model (see, however, notes for ProB 1.13.0 or later below).
In addition the constants used in the above definitions should only have one possible value.
For example, suppose that the constant P has 5 elements then this will create 5 SVG lines.
Observe that we use the new Event-B-style set comprehension for convenience and that tuples can be used for the <tt>id</tt> field..
<pre>
VISB_SVG_OBJECTS3 == {i•i:P|rec(`svg_class`:"line",`id`:("line",i),x1:0,y1:i,x2:i,y2:i)};
</pre>

Similarly, you can use VISB_SVG_UPDATES definitions to specify attributes that depend on the
value of constants and variables of the animated B model:
<pre>
VISB_SVG_UPDATES1== rec(`id`:"i2",fill: IF x>0 THEN "red" ELSE "green" END);
</pre>

Hovers can be defined using VISB_SVG_HOVER definitions (only for objects that have been created with VISB_SVG_OBJECTS) and click events can be defined using
VISB_SVG_EVENTS definitions with attributes <tt>id</tt>, <tt>event</tt> and optionally <tt>predicate</tt>.
Here is a minimal example that just uses the VisB DEFINITIONS without any external JSON or SVG file:
<pre>
MACHINE button_def
// An example that uses VisB DEFINITIONS instead of a JSON and SVG file
DEFINITIONS
VISB_JSON_FILE == "";
VISB_SVG_BOX == rec(height:200, width:240);
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:"100",cy:"100", r:"80", stroke:"black", `stroke-width`:"3");
VISB_SVG_UPDATES == rec(`id`:"button",
fill: IF button=TRUE THEN "green" ELSE "red" END);
VISB_SVG_HOVERS == rec(`id`:"button",
stroke:"gray", `stroke-width`:"5");
VISB_SVG_EVENTS == rec(`id`:"button", event:"toggle_button", predicate:"btrue")
VARIABLES button
INVARIANT button:BOOL
INITIALISATION button := FALSE
OPERATIONS
toggle_button = BEGIN
button:= bool(button=FALSE)
END
END
</pre>

As of version 1.13.0 of ProB you can also use dynamic expressions in object definitions; the above definitions can thus be written more compactly:
<pre>
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:100,cy:100, r:80, stroke:"black", `stroke-width`:3,
fill: IF button=TRUE THEN "green" ELSE "red" END,
event:"toggle_button",
hovers: rec(stroke:"gray", `stroke-width`:"5"));
</pre>

In 1.13.0 you can also use a "children" attribute to specify groups.
The children attribute should evaluate to a set of strings pointing to ids of SVG objects.
The following example shows this for for defining the children of "mygroup".
Also observe the use of the new [[Summary_of_B_Syntax#Strings:|template string syntax]] for the transform attribute.
<pre>
VISB_SVG_FILE == "";
VISB_SVG_BOX == rec(height:400, width:450);
VISB_SVG_OBJECTS1 == {i•i:0..9|rec(`id`:("r",i), svg_class:"rect",
fill:IF i=x THEN "red" ELSE "green" END,
x:10+10*i, y:100, height:20, width:4)};
VISB_SVG_OBJECTS2 == rec(`id`:"mygroup", svg_class:"g",
children: {i•i:0..9|("r",i)},
transform:```rotate(${x*40},50,100)```
)
</pre>

Version 1.13.1 also adds a new virtual <tt>title</tt> attribute that can be set in such SVG_OBJECTS.
This will create a tooltip box displaying the value of the attribute. (Internally this gets transformed into children SVG title objects.) These tooltips are independent of the other VisB hovers (and in contrast to these hovers the value of the title attribute can be dynamic, i.e., depend on the model's variables).

In VisB event predicates, the local identifier <tt>VISB_CLICK_META_INFOS</tt> can be used to access information like shift or command key presses and mouse positions during a click. It represents a record of the following type:
<pre>
rec(altKey: BOOL,
ctrlKey: BOOL,
jsVars: STRING <-> STRING,
metaKey: BOOL,
pageX: INTEGER,
pageY: INTEGER,
shiftKey: BOOL
)
</pre>

It also enables usage of JavaScript values: <tt>VISB_CLICK_META_INFOS'jsVars("MYID")</tt>. The value must first be assigned in a <tt>script</tt> tag in the SVG using <tt>visb_vars["MYID"]</tt>.

== Examples ==

Some examples can be found in the [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples visb-visualisation-examples] repository.
We have a small [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel/-/blob/master/notebooks/manual/VisB_Features.ipynb Jupyter notebook manual] on the DEFINITION features of VisB.
More details and examples will be added later.

== Caveats ==

* Beware that you need to escape quotation marks and slashes in the JSON file for fields containing B expressions. Also, you cannot use newline.
* Hovers are currently evaluated once statically and cannot make use of B expressions. To make hover information dependent on the state, use the visibility attribute to make hidden SVG objects (which can be adapted depending on the state using VisB items) visible. The [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] illustrates this idea.

== Tips and Tricks ==

It is sometimes useful to use simple coordinates for your VisB items and B expressions, e.g. x coordinates of 0..100.
You can quite often do this and use the SVG transform attribute to scale and move the SVG object to the right place.
The simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
In essence your SVG file can contain this:
<pre>
<polygon id = "ttd_polyline"
points="0,0 100,0"
stroke="gray" fill="none"
transform="translate(10,22.5)" />
</pre>
and the VisB JSON file contains this, making use of LibrarySVG.def (automatically available) external function svg_axis:
<pre>
{
"id":"ttd_polyline",
"attr":"points",
"value":"svg_axis({0} \\/ ran(%tt.(tt:TTDS|1+max(TTD_TrackElements(tt)))),100.0/real(TrackElementNumber+1),100.0,2.0)",
"comment":"show ticks for TTD Limits"
},
</pre>

Observe that we had to escape the slash of the union operator.
Also observe, that we are able to use [[Summary_of_B_Syntax#Reals:|floating numbers]] in the new version of ProB, which is very useful for VisB visualisations.

It can be useful to use style and class to make it easier to change your color scheme or other styling attributes within your visualisation consistently.
Again, the simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
E.g., your SVG file could contain towards the top this definition:
<pre>
<style id="style_ttd_ts_mp">
.ttd {
stroke : none;
stroke-width: 0.2;
opacity: 0.7
}
.red-occupied-ttd {
fill : red
}
</style>
</pre>
Later you can then use it to style your objects:
<pre>
<polygon id = "occupied_ttd_polygon"
points="0,0 0,2 10,2 10,0 70,0 70,1 90,1 90,0"
class = "ttd red-occupied-ttd"
transform="translate(10,23)" />
</pre>

You can then modify the class using VisB items. Classes can also be useful for hovers, by simply exchanging one style for another when the mouse is over an objects (again, see [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train the train example]).
Recent versions of ProB also support adding and removing a class, which is useful for hovers when the class is modified by VisB items:
<pre>
{
"id":"train_polygon_tr1",
"event":"TrainMoveForward",
"hovers": [{ "attr":"class", "enter":"+train-hover", "leave":"-train-hover"}]
}
</pre>

== Debugging and HTML Export ==

In classical B models you can store your default VisB visualisation in the DEFINITIONS section:
<pre>
DEFINITIONS
VISB_JSON_FILE == "TwoTrains.json"
</pre>

For debugging it can be useful to use VisB within ProB Tcl/Tk: if you choose to visualise the current state with VisB, ProB will generate a stand-alone HTML file which is opened in a browser.
In the browser you can open the (Javascript) developer console and you will be alerted to warnings and errors (which unfortunately, are currently not shown in ProB2-UI).
Upon changing the state in the animator, the HTML file will be regenerated and the VisB file re-loaded if necessary.
The HTML export also displays hovers, but cannot react to clicks.
The HTML export is also available in ProB2-UI (in the export menu in the top-right corner).

ProB can also export the entire animation history to a standalone HTML file that can be passed to other persons (without requiring access to the B model or to ProB).
In ProB Tcl/Tk you can right-click on the history pane and choose "View History in VisB".
In probcli you can use the command <tt>-visb JSONFILE HTMLFILE</tt> to export the history.
In ProB2-UI you can click on the export icon in the upper right hand corner:

[[File:ProB2UI_VisB_View_Export.png|center|550px]]

The ProB2-UI table visualisation view (Visualisation menu) also contains tables to help debug VisB items and events:

[[File:ProB2UI_VisB_Debug_Table_View.png|center|550px]]

This view is also available in ProB Tcl/Tk in the Visualize menu (States submenu).
ProB2-UI also has another inspection view that can be obtained by clicking on the "i" (info) icon in the the VisB toolbar.

=== Using the VisB exported HTML file ===

You should be able to open the exported HTML using a regular browser.
Within the web page (see the image below) you can then do the following:
* single step through the trace by clicking the "Forward" and "Backward" buttons, or clicking on individual steps of the trace
* execute the entire trace nd see changes to the visualisation by clicking one of the "Run Trace" buttons
* you can inspect the value of the sets, constants and variables at every step by expanding the corresponding tabs
Some meta information can be found at the bottom of the trace.

[[File:ProB2UI_VisB_View_ExportedHTML.png|center|550px]]

== Citing VisB ==
This is the Bibtex entry for an article about VisB [https://rdcu.be/b4rqh in the ABZ'2020 proceedings]:
<pre>
@inproceedings{WerthLeuschel:abz2020,
author = {Michelle Werth and Michael Leuschel},
title = {{VisB}: A Lightweight Tool to Visualize Formal Models with {SVG} Graphics},
booktitle = {Proceedings ABZ 2020},
editor="Raschke, Alexander and M{\'e}ry, Dominique and Houdek, Frank",
year = {2020},
series = {LNCS 12071},
pages = "260--265",
isbn="978-3-030-48077-6"
}
</pre>

== Installing the VisB plugin for older ProB2-UI versions ==

'''Note:''' The following instructions are for ProB2-UI version 1.0.0 '''only'''. On current versions of ProB2-UI (1.1.0 and later), VisB is included by default and '''does not need to be installed separately'''.

To install the VisB plugin in ProB2-UI 1.0.0 you need to:

# [https://www3.hhu.de/stups/downloads/prob2/plugins/VisB-1.0.0.jar Download the VisB plugin jar file].
# In the "Advanced" menu of ProB2-UI, choose "Plugin Menu".
# Click on the "Add Plugin..." button.
# Select the VisB jar file that you have downloaded.
# Choose the "Open VisB" command in the Advanced menu to start VisB.

VisB

2025-04-04T07:29:37Z

Jan Gruteser: /* VisB DEFINITIONS */

'''VisB''' is a visualisation feature of ProB based on SVG graphics and HTML.

Initially VisB was developed for [[ProB2-UI]], the new user interface of ProB based on JavaFX and the ProB2-Java-API.
It is included in ProB2-UI version 1.1.0 and later, which [[Download#ProB2-UI using Java FX|can be downloaded here]].
Users of ProB2-UI version 1.0.0 can [[#Installing the VisB plugin for older ProB2-UI versions|install VisB as a plugin]].
We, however, recommend you use the latest ProB2-UI snapshot.
VisB is constantly being improved and the latest version contains several useful new features.

[[File:ProB2UI_VisB_View.png|center|550px]]

ProB Tcl/Tk and probcli version 1.11.0 and later also support VisB visualisations:

* with <tt>probcli File.mch ... -visb VISBJSONFILE HTMLFILE</tt> you can export the animator's history to a self-contained HTML file including a visualisation of the states in the history
* in ProB Tcl/Tk you can visualise the current state or the history using a VisB visualisation file (it is shown in an external browser) by right clicking in the "State Properties" or the "History" pane.
Hovers work in both cases, but unlike in ProB2-UI, you cannot click to perform events.

An article about VisB has been [https://rdcu.be/b4rqh published in the ABZ'2020 proceedings].

== Using VisB ==

In current versions of [[ProB2-UI]] the VisB view is automatically shown in the center pane below the state view.
To start VisB in older versions of [[ProB2-UI]], choose the "Open VisB" command in the Visualisation menu,
or right-click in the "State Properties" pane of ProB Tcl/Tk and select "View Current State in VisB".

You can now choose a JSON file which builds on top of a SVG graphics file (more recent versions of VisB can also load visualisations from [[VisB#VisB_DEFINITIONS|definitions]].
The JSON file contains a reference to a SVG file, along with entries to modify attributes based on the current state of a B model and entries which specify how VisB should react to clicks on the SVG. The SVG file should contain object ids which are referenced in the JSON file.

Here is a sample file:
<pre>
{
"svg":"Train2.svg",
"items":[
{
"id":"Train1_rect",
"attr":"visibility",
"value":"IF 1:TRAIN THEN \"visible\" ELSE \"hidden\" END"
},
{
"id":"Train1_rect",
"attr":"fill",
"value":"IF train_speed(1)>0 THEN \"blue\" ELSE \"orange\" END"
},
{
"id":"Train1_rect",
"attr":"x",
"value":"train_back_loc(1)*10+20"
},
{
"id":"Train1_rect",
"attr":"width",
"value":"train_length(1)*10"
}
],
"events":[
{
"id":"Train1_rect",
"event":"Train_Move1",
"predicates":[
"1=1"
]
}
]
}
</pre>

== VisB Attributes ==

At the top-level a VisB JSON file contains these attributes:
* svg
* model-name
* include
* svg_objects
* definitions
* items
* events

Below we explain them in more detail.

=== SVG file and inclusion ===

The main VisB Json file should contain an <tt>svg</tt> attribute with a
relative or absolute path to the SVG file to be shown.

The <tt>model-name</tt> attribute is optional; if set ProB will emit
a warning if the B model's name does not match the value of this attribute.

One can also include subsidiary VisB Json files using the <tt>include</tt>
attribute with again a relative or absolut path to another Json file:

<pre>
{
"svg":"my_svg_file.svg",
"include":"subsidiary_visb_file.json",
"items":[
...
}
</pre>

The svg attribute in subsidiary files will be ignored.
You can override the VisB items in the included file (i.e., a VisB item for an id and attribute in the top-level file will override items for the same id and attribute in the included files).

=== Items and Events ===

For VisB <tt>items</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>attr</tt> a valid SVG attribute
* <tt>value</tt> a B formula which will be evaluated in the current state of a model and yields a new value for the above attribute.

Note that the formula can make use of the [[Summary_of_B_Syntax#Reals |REAL datatype]] and also use many of the [[External_Functions|external functions]] e.g. from LibraryStrings or LibraySVG.
Here is an example VisB Item:
<pre>
"items":[
{
"id": "train1_rect",
"attr": "x",
"value":"100.0 + train_left(train1)"
} ]
</pre>
As of version 1.12.2, ProB allows you to use a single attribute whose name is the SVG attribute being set, rather than two attributes (attr, value).
With this you can set multiple SVG attributes in one VisB item.
For example, you can now write:
<pre>
"items":[
{
"id": "train1_rect",
"x":"100.0 + train_left(train1)",
"y":"20.0 + train_bottom(train1)"
} ]
</pre>

For VisB <tt>events</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>event</tt> a valid B operation or event of the loaded formal model
* <tt>predicates</tt> an optional list of B predicates, which can be used to set parameters of the B operation that is executed upon a click

Additionally VisB now recognises for both items and events:

* <tt>ignore</tt>, if this attribute is present the item will be ignored
* <tt>repeat</tt>, if this attribute is present the item will be replicated (see below). This construct requires a list of strings.
* <tt>for</tt>, if this attribute is present the item will be replicated (see below). The for construct requires <tt>from</tt> and <tt>to</tt> with integer values as sub arguments. As of version 1.11.1 you can also use constant B integer expressions accessing just the sets.
* <tt>optional</tt>, if this boolean attribute is <tt>true</tt> an event will be ignored if the event name is not a valid top-level event/operation in the model. An item will be ignored if the identifiers in the formula do not exists (i.e., errors during type checking will be ignored)
* <tt>override</tt>, if this boolean attribute is <tt>true</tt> no warnings will be generated if another VisB item for the same attribute and id is overriden (as of version 1.11.1)

Other attributes will be ignored. E.g, one can use a <tt>comment</tt> attribute to add comments to the VisB items.

When executing an event, VisB now performs the following replacements within the predicates of the event:
* <tt>%shiftKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%metaKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%pageX</tt> is replaced by the x coordinate of the click relative to the top-left of the entire VisB SVG
* <tt>%pageY</tt> is replaced by the y coordinate of the click relative to the top-left of the entire VisB SVG

Finally, VisB events can be associated with mouse hover actions.
For this you just need to add an attribute <tt>hovers</tt> which contains a list of JSON objects with the following attributes:
* <tt>id</tt>, this is the identifier of an object in the associated SVG file; this attribute is optional; if it is not present the id specified in the VisB event will be used.
* <tt>attr</tt> a valid SVG attribute
* <tt>enter</tt> a value which will be used when the mouse enters the area of the object
* <tt>leave</tt> a value which will be used to restore the attribute when the mouse leaves the area
Note that the enter and leave values have to be static at the moment; in future we plan to allow B formulas here and also apply the repetition/replacement mechanism specified above.
If you just wish to attach a hover to an SVG object (and no B operation/event) you can set the event field of the VisB event to the empty string (<tt>"event":""</tt>).
You should not use attributes for the hover which are set by VisB items.

Here is an example VisB event with hovers:
<pre>
{
"id": "button",
"event": "toggle_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"},
{ "attr":"opacity", "enter":"0.8", "leave":"1.0"}]
}
</pre>

A VisB event can now also contain an list of items with the attributes <tt>id</tt>, <tt>attr</tt>, <tt>enabled</tt> and <tt>disabled</tt>.
When the associated event is enabled, the attribute of the SVG object with the given id is set to the value provided in the enabled attribute, otherwise the disabled attribute value is used.
As above the item id is optional and defaults to the id of the VisB event.
Here is an example VisB event with hovers and an items list:
<pre>
{
"id": "button",
"event": "press_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"}],
"items": [{"attr":"fill", "disabled":"\"green\"", "enabled":"\"red\""}]
},
</pre>

== Replication / Loops ==

You can use the <tt>repeat</tt> and <tt>for</tt> attributes to replicate a VisB
item or event.
Replication consists in duplicating the item or event, and replacing <tt>%0</tt> within the identifier and value attributes of the time with the repeated string or integer.

For example, the repeat instruction below will result in the creation of three VisB items, one for id <tt>txt_ttd1</tt>, for <tt>txt_ttd2</tt>, and one for <tt>txt_ttd3</tt>.
The value formula for <tt>txt_ttd1</tt> is <tt>"IF 1: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"</tt>.
<pre>
{
"repeat": ["1","2","3"],
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>

A for loop can be used instead for the above example as follows:
<pre>
{
"for": {"from":1, "to":3},
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>
The for loop also allows an optional <tt>step</tt> attribute.

It is possible to apply both <tt>repeat</tt> and <tt>for</tt> attributes at the same time, as this example shows.
(The exact details of multiple iterations for a VisB item might change in future.)

<pre>
{
"repeat": [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20],
"for": {"from":1, "to":20},
"id": "tile%1x%0",
"event": "TryQueen",
"hovers": [{ "attr":"opacity", "enter":"0.5", "leave":"1"}],
"predicates" : ["i=%1","j=%0"]
}
</pre>

As of version 1.11.0 you can also use nested for loops.
As of version 1.11.1 of ProB you can also use B expressions for the <tt>from</tt>, <tt>to</tt> and <tt>step</tt> attributes of a for loop.
However, these expressions must be evaluable without having access to any constants or variables. Indeed, the for and repeat loops are processed once when loading a VisB file, independently of any given state.
So, you can only access identifiers of <tt>SETS</tt> section of a B machine.
It may still be useful, e.g., to iterate over an enumerated or deferred set (TRAINS below):

<pre>
{
"for": {"from":1, "to":"card(TRAINS)"},
...
}
</pre>

The <tt>INT_TO_ENUM</tt> external function available as of ProB 1.11.1 can be useful in expressions here to convert the iteration variable back to an enumerated or deferred set element.
For example, <tt>INT_TO_ENUM(TRAINS,1)</tt> refers to the first element of the set <tt>TRAINS</tt>.

== VisB Definitions (in JSON file) ==

As of ProB Tcl/Tk 1.11.0 it is possible to include local definitions in the VisB JSON file.
Each definition has a name and a value formula.
Definitions are evaluated in order of appearance (a later definition can thus refer to an ealier one) and are evaluated in a state before evaluating VisB items.

<pre>
"definitions":[
{ "name":"xscale",
"value" : "(100.0 / real(NrOfTrackElements))"
},
{ "name":"visb_train_rear",
"value" : "%x.(x:dom(train_rear)|xscale * real(train_rear(x)))"
}]
</pre>

The VisB definitions are particularly useful for Event-B models (as you can use [[Summary_of_B_Syntax#Reals |REAL numbers]] and also have access to [[External_Functions|external functions]] such as LibraryStrings or LibraySVG).
But they are not yet available for events in ProB2-UI.

== VisB Additional SVG Objects ==

As of version 1.12.0 of ProB Tcl/Tk you can add new SVG objects to your SVG file.
You can use for and repeat loops (see above) to create an arbitrary number of objects.
This is useful for making flexible visualisations which work with an arbitrary number
of objects.
The same rules and limitations for for/repeat loops apply as for items above.

Every entry in the svg_objects list
* an <tt>svg_class</tt> attribute, which can be, e.g., line, circle, rect, ...
* an object <tt>id</tt> attribute
* an optional <tt>comment</tt> attribute
* any other attribute will be used to create the SVG object and should be valid for the specified svg_class

Here is an example (taken from [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/blob/master/Physics/n_bodies_visb.json here]) where NOBJS is a DEFINITION inside a B machine:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"NOBJS"},
"svg_class":"circle",
"id":"body%0",
"cx":"45",
"cy":"15",
"r":"10",
"stroke":"black",
"stroke-width":"0.5",
"fill":"green"
} ]
</pre>

Here is another example where TRAINS is a deferred or enumerated set of the B model being visualised:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"card(TRAINS)"},
"svg_class":"rect",
"id":"fresh_train_rect%0",
"x":"0",
"y":"0",
"height":"10",
"width":"20",
"comment":"train current position rectangle"
}
]
</pre>

== VisB DEFINITIONS ==
As of version 1.12 you can also provide many of the VisB annotations via B DEFINITIONS.
This can be done in addition to a VisB JSON file or completely replacing the JSON file.

By adding this definition to your B machine you specify that you wish to use an empty
SVG file as base:
<pre>
VISB_JSON_FILE == "";
</pre>

With a VISB_SVG_BOX definition you can set the size of the generated empty SVG file:
<pre>
VISB_SVG_BOX == rec(height:floor(vscale)*25+20, width:1800);
</pre>
Note: you can also provide an optional <tt>viewBox</tt> attribute as a B string.

Via VISB_SVG_CONTENTS definitions you can add new textual content to the base SVG file:
<pre>
VISB_SVG_CONTENTS == '''
<defs>
...
```;
</pre>

With definitions starting with with VISB_SVG_OBJECTS you can add new SVG objects:
<pre>
VISB_SVG_OBJECTS1 == rec(`svg_class`:"rect",`id`:"i1",x:20,y:20,height:20,width:20,fill:"blue");
VISB_SVG_OBJECTS2 == rec(`svg_class`:"circle",`id`:"i2",cx:30,cy:30,r:20,fill:"red");
</pre>
Each definition can either add a single record or add a set of records in one go.
The definition should only depend on base sets or constants of the model (see, however, notes for ProB 1.13.0 or later below).
In addition the constants used in the above definitions should only have one possible value.
For example, suppose that the constant P has 5 elements then this will create 5 SVG lines.
Observe that we use the new Event-B-style set comprehension for convenience and that tuples can be used for the <tt>id</tt> field..
<pre>
VISB_SVG_OBJECTS3 == {i•i:P|rec(`svg_class`:"line",`id`:("line",i),x1:0,y1:i,x2:i,y2:i)};
</pre>

Similarly, you can use VISB_SVG_UPDATES definitions to specify attributes that depend on the
value of constants and variables of the animated B model:
<pre>
VISB_SVG_UPDATES1== rec(`id`:"i2",fill: IF x>0 THEN "red" ELSE "green" END);
</pre>

Hovers can be defined using VISB_SVG_HOVER definitions (only for objects that have been created with VISB_SVG_OBJECTS) and click events can be defined using
VISB_SVG_EVENTS definitions with attributes <tt>id</tt>, <tt>event</tt> and optionally <tt>predicate</tt>.
Here is a minimal example that just uses the VisB DEFINITIONS without any external JSON or SVG file:
<pre>
MACHINE button_def
// An example that uses VisB DEFINITIONS instead of a JSON and SVG file
DEFINITIONS
VISB_JSON_FILE == "";
VISB_SVG_BOX == rec(height:200, width:240);
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:"100",cy:"100", r:"80", stroke:"black", `stroke-width`:"3");
VISB_SVG_UPDATES == rec(`id`:"button",
fill: IF button=TRUE THEN "green" ELSE "red" END);
VISB_SVG_HOVERS == rec(`id`:"button",
stroke:"gray", `stroke-width`:"5");
VISB_SVG_EVENTS == rec(`id`:"button", event:"toggle_button", predicate:"btrue")
VARIABLES button
INVARIANT button:BOOL
INITIALISATION button := FALSE
OPERATIONS
toggle_button = BEGIN
button:= bool(button=FALSE)
END
END
</pre>

As of version 1.13.0 of ProB you can also use dynamic expressions in object definitions; the above definitions can thus be written more compactly:
<pre>
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:100,cy:100, r:80, stroke:"black", `stroke-width`:3,
fill: IF button=TRUE THEN "green" ELSE "red" END,
event:"toggle_button",
hovers: rec(stroke:"gray", `stroke-width`:"5"));
</pre>

In 1.13.0 you can also use a "children" attribute to specify groups.
The children attribute should evaluate to a set of strings pointing to ids of SVG objects.
The following example shows this for for defining the children of "mygroup".
Also observe the use of the new [[Summary_of_B_Syntax#Strings:|template string syntax]] for the transform attribute.
<pre>
VISB_SVG_FILE == "";
VISB_SVG_BOX == rec(height:400, width:450);
VISB_SVG_OBJECTS1 == {i•i:0..9|rec(`id`:("r",i), svg_class:"rect",
fill:IF i=x THEN "red" ELSE "green" END,
x:10+10*i, y:100, height:20, width:4)};
VISB_SVG_OBJECTS2 == rec(`id`:"mygroup", svg_class:"g",
children: {i•i:0..9|("r",i)},
transform:```rotate(${x*40},50,100)```
)
</pre>

Version 1.13.1 also adds a new virtual <tt>title</tt> attribute that can be set in such SVG_OBJECTS.
This will create a tooltip box displaying the value of the attribute. (Internally this gets transformed into children SVG title objects.) These tooltips are independent of the other VisB hovers (and in contrast to these hovers the value of the title attribute can be dynamic, i.e., depend on the model's variables).

In VisB event predicates, the local identifier <tt>VISB_CLICK_META_INFOS</tt> can be used to access information like shift or command key presses and mouse positions during a click. It represents a record of the following type:
<pre>
rec(altKey: BOOL,
ctrlKey: BOOL,
jsVars: STRING <-> STRING,
metaKey: BOOL,
pageX: INTEGER,
pageY: INTEGER,
shiftKey: BOOL
)
</pre>

It also enables usage of JavaScript values: <tt>VISB_CLICK_META_INFOS'jsVars("MYID")</tt>. The value must first be assigned in a <tt>script</tt> tag in the SVG using <tt>visb_vars["${MYID}"]</tt>.

== Examples ==

Some examples can be found in the [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples visb-visualisation-examples] repository.
We have a small [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel/-/blob/master/notebooks/manual/VisB_Features.ipynb Jupyter notebook manual] on the DEFINITION features of VisB.
More details and examples will be added later.

== Caveats ==

* Beware that you need to escape quotation marks and slashes in the JSON file for fields containing B expressions. Also, you cannot use newline.
* Hovers are currently evaluated once statically and cannot make use of B expressions. To make hover information dependent on the state, use the visibility attribute to make hidden SVG objects (which can be adapted depending on the state using VisB items) visible. The [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] illustrates this idea.

== Tips and Tricks ==

It is sometimes useful to use simple coordinates for your VisB items and B expressions, e.g. x coordinates of 0..100.
You can quite often do this and use the SVG transform attribute to scale and move the SVG object to the right place.
The simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
In essence your SVG file can contain this:
<pre>
<polygon id = "ttd_polyline"
points="0,0 100,0"
stroke="gray" fill="none"
transform="translate(10,22.5)" />
</pre>
and the VisB JSON file contains this, making use of LibrarySVG.def (automatically available) external function svg_axis:
<pre>
{
"id":"ttd_polyline",
"attr":"points",
"value":"svg_axis({0} \\/ ran(%tt.(tt:TTDS|1+max(TTD_TrackElements(tt)))),100.0/real(TrackElementNumber+1),100.0,2.0)",
"comment":"show ticks for TTD Limits"
},
</pre>

Observe that we had to escape the slash of the union operator.
Also observe, that we are able to use [[Summary_of_B_Syntax#Reals:|floating numbers]] in the new version of ProB, which is very useful for VisB visualisations.

It can be useful to use style and class to make it easier to change your color scheme or other styling attributes within your visualisation consistently.
Again, the simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
E.g., your SVG file could contain towards the top this definition:
<pre>
<style id="style_ttd_ts_mp">
.ttd {
stroke : none;
stroke-width: 0.2;
opacity: 0.7
}
.red-occupied-ttd {
fill : red
}
</style>
</pre>
Later you can then use it to style your objects:
<pre>
<polygon id = "occupied_ttd_polygon"
points="0,0 0,2 10,2 10,0 70,0 70,1 90,1 90,0"
class = "ttd red-occupied-ttd"
transform="translate(10,23)" />
</pre>

You can then modify the class using VisB items. Classes can also be useful for hovers, by simply exchanging one style for another when the mouse is over an objects (again, see [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train the train example]).
Recent versions of ProB also support adding and removing a class, which is useful for hovers when the class is modified by VisB items:
<pre>
{
"id":"train_polygon_tr1",
"event":"TrainMoveForward",
"hovers": [{ "attr":"class", "enter":"+train-hover", "leave":"-train-hover"}]
}
</pre>

== Debugging and HTML Export ==

In classical B models you can store your default VisB visualisation in the DEFINITIONS section:
<pre>
DEFINITIONS
VISB_JSON_FILE == "TwoTrains.json"
</pre>

For debugging it can be useful to use VisB within ProB Tcl/Tk: if you choose to visualise the current state with VisB, ProB will generate a stand-alone HTML file which is opened in a browser.
In the browser you can open the (Javascript) developer console and you will be alerted to warnings and errors (which unfortunately, are currently not shown in ProB2-UI).
Upon changing the state in the animator, the HTML file will be regenerated and the VisB file re-loaded if necessary.
The HTML export also displays hovers, but cannot react to clicks.
The HTML export is also available in ProB2-UI (in the export menu in the top-right corner).

ProB can also export the entire animation history to a standalone HTML file that can be passed to other persons (without requiring access to the B model or to ProB).
In ProB Tcl/Tk you can right-click on the history pane and choose "View History in VisB".
In probcli you can use the command <tt>-visb JSONFILE HTMLFILE</tt> to export the history.
In ProB2-UI you can click on the export icon in the upper right hand corner:

[[File:ProB2UI_VisB_View_Export.png|center|550px]]

The ProB2-UI table visualisation view (Visualisation menu) also contains tables to help debug VisB items and events:

[[File:ProB2UI_VisB_Debug_Table_View.png|center|550px]]

This view is also available in ProB Tcl/Tk in the Visualize menu (States submenu).
ProB2-UI also has another inspection view that can be obtained by clicking on the "i" (info) icon in the the VisB toolbar.

=== Using the VisB exported HTML file ===

You should be able to open the exported HTML using a regular browser.
Within the web page (see the image below) you can then do the following:
* single step through the trace by clicking the "Forward" and "Backward" buttons, or clicking on individual steps of the trace
* execute the entire trace nd see changes to the visualisation by clicking one of the "Run Trace" buttons
* you can inspect the value of the sets, constants and variables at every step by expanding the corresponding tabs
Some meta information can be found at the bottom of the trace.

[[File:ProB2UI_VisB_View_ExportedHTML.png|center|550px]]

== Citing VisB ==
This is the Bibtex entry for an article about VisB [https://rdcu.be/b4rqh in the ABZ'2020 proceedings]:
<pre>
@inproceedings{WerthLeuschel:abz2020,
author = {Michelle Werth and Michael Leuschel},
title = {{VisB}: A Lightweight Tool to Visualize Formal Models with {SVG} Graphics},
booktitle = {Proceedings ABZ 2020},
editor="Raschke, Alexander and M{\'e}ry, Dominique and Houdek, Frank",
year = {2020},
series = {LNCS 12071},
pages = "260--265",
isbn="978-3-030-48077-6"
}
</pre>

== Installing the VisB plugin for older ProB2-UI versions ==

'''Note:''' The following instructions are for ProB2-UI version 1.0.0 '''only'''. On current versions of ProB2-UI (1.1.0 and later), VisB is included by default and '''does not need to be installed separately'''.

To install the VisB plugin in ProB2-UI 1.0.0 you need to:

# [https://www3.hhu.de/stups/downloads/prob2/plugins/VisB-1.0.0.jar Download the VisB plugin jar file].
# In the "Advanced" menu of ProB2-UI, choose "Plugin Menu".
# Click on the "Add Plugin..." button.
# Select the VisB jar file that you have downloaded.
# Choose the "Open VisB" command in the Advanced menu to start VisB.

VisB

2025-04-04T07:28:30Z

Jan Gruteser: /* VisB DEFINITIONS */

'''VisB''' is a visualisation feature of ProB based on SVG graphics and HTML.

Initially VisB was developed for [[ProB2-UI]], the new user interface of ProB based on JavaFX and the ProB2-Java-API.
It is included in ProB2-UI version 1.1.0 and later, which [[Download#ProB2-UI using Java FX|can be downloaded here]].
Users of ProB2-UI version 1.0.0 can [[#Installing the VisB plugin for older ProB2-UI versions|install VisB as a plugin]].
We, however, recommend you use the latest ProB2-UI snapshot.
VisB is constantly being improved and the latest version contains several useful new features.

[[File:ProB2UI_VisB_View.png|center|550px]]

ProB Tcl/Tk and probcli version 1.11.0 and later also support VisB visualisations:

* with <tt>probcli File.mch ... -visb VISBJSONFILE HTMLFILE</tt> you can export the animator's history to a self-contained HTML file including a visualisation of the states in the history
* in ProB Tcl/Tk you can visualise the current state or the history using a VisB visualisation file (it is shown in an external browser) by right clicking in the "State Properties" or the "History" pane.
Hovers work in both cases, but unlike in ProB2-UI, you cannot click to perform events.

An article about VisB has been [https://rdcu.be/b4rqh published in the ABZ'2020 proceedings].

== Using VisB ==

In current versions of [[ProB2-UI]] the VisB view is automatically shown in the center pane below the state view.
To start VisB in older versions of [[ProB2-UI]], choose the "Open VisB" command in the Visualisation menu,
or right-click in the "State Properties" pane of ProB Tcl/Tk and select "View Current State in VisB".

You can now choose a JSON file which builds on top of a SVG graphics file (more recent versions of VisB can also load visualisations from [[VisB#VisB_DEFINITIONS|definitions]].
The JSON file contains a reference to a SVG file, along with entries to modify attributes based on the current state of a B model and entries which specify how VisB should react to clicks on the SVG. The SVG file should contain object ids which are referenced in the JSON file.

Here is a sample file:
<pre>
{
"svg":"Train2.svg",
"items":[
{
"id":"Train1_rect",
"attr":"visibility",
"value":"IF 1:TRAIN THEN \"visible\" ELSE \"hidden\" END"
},
{
"id":"Train1_rect",
"attr":"fill",
"value":"IF train_speed(1)>0 THEN \"blue\" ELSE \"orange\" END"
},
{
"id":"Train1_rect",
"attr":"x",
"value":"train_back_loc(1)*10+20"
},
{
"id":"Train1_rect",
"attr":"width",
"value":"train_length(1)*10"
}
],
"events":[
{
"id":"Train1_rect",
"event":"Train_Move1",
"predicates":[
"1=1"
]
}
]
}
</pre>

== VisB Attributes ==

At the top-level a VisB JSON file contains these attributes:
* svg
* model-name
* include
* svg_objects
* definitions
* items
* events

Below we explain them in more detail.

=== SVG file and inclusion ===

The main VisB Json file should contain an <tt>svg</tt> attribute with a
relative or absolute path to the SVG file to be shown.

The <tt>model-name</tt> attribute is optional; if set ProB will emit
a warning if the B model's name does not match the value of this attribute.

One can also include subsidiary VisB Json files using the <tt>include</tt>
attribute with again a relative or absolut path to another Json file:

<pre>
{
"svg":"my_svg_file.svg",
"include":"subsidiary_visb_file.json",
"items":[
...
}
</pre>

The svg attribute in subsidiary files will be ignored.
You can override the VisB items in the included file (i.e., a VisB item for an id and attribute in the top-level file will override items for the same id and attribute in the included files).

=== Items and Events ===

For VisB <tt>items</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>attr</tt> a valid SVG attribute
* <tt>value</tt> a B formula which will be evaluated in the current state of a model and yields a new value for the above attribute.

Note that the formula can make use of the [[Summary_of_B_Syntax#Reals |REAL datatype]] and also use many of the [[External_Functions|external functions]] e.g. from LibraryStrings or LibraySVG.
Here is an example VisB Item:
<pre>
"items":[
{
"id": "train1_rect",
"attr": "x",
"value":"100.0 + train_left(train1)"
} ]
</pre>
As of version 1.12.2, ProB allows you to use a single attribute whose name is the SVG attribute being set, rather than two attributes (attr, value).
With this you can set multiple SVG attributes in one VisB item.
For example, you can now write:
<pre>
"items":[
{
"id": "train1_rect",
"x":"100.0 + train_left(train1)",
"y":"20.0 + train_bottom(train1)"
} ]
</pre>

For VisB <tt>events</tt> every entry needs
* <tt>id</tt>, this is the identifier of an object in the associated SVG file
* <tt>event</tt> a valid B operation or event of the loaded formal model
* <tt>predicates</tt> an optional list of B predicates, which can be used to set parameters of the B operation that is executed upon a click

Additionally VisB now recognises for both items and events:

* <tt>ignore</tt>, if this attribute is present the item will be ignored
* <tt>repeat</tt>, if this attribute is present the item will be replicated (see below). This construct requires a list of strings.
* <tt>for</tt>, if this attribute is present the item will be replicated (see below). The for construct requires <tt>from</tt> and <tt>to</tt> with integer values as sub arguments. As of version 1.11.1 you can also use constant B integer expressions accessing just the sets.
* <tt>optional</tt>, if this boolean attribute is <tt>true</tt> an event will be ignored if the event name is not a valid top-level event/operation in the model. An item will be ignored if the identifiers in the formula do not exists (i.e., errors during type checking will be ignored)
* <tt>override</tt>, if this boolean attribute is <tt>true</tt> no warnings will be generated if another VisB item for the same attribute and id is overriden (as of version 1.11.1)

Other attributes will be ignored. E.g, one can use a <tt>comment</tt> attribute to add comments to the VisB items.

When executing an event, VisB now performs the following replacements within the predicates of the event:
* <tt>%shiftKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%metaKey</tt> is replaced by TRUE if the shift key was pressed during the click, FALSE otherwise
* <tt>%pageX</tt> is replaced by the x coordinate of the click relative to the top-left of the entire VisB SVG
* <tt>%pageY</tt> is replaced by the y coordinate of the click relative to the top-left of the entire VisB SVG

Finally, VisB events can be associated with mouse hover actions.
For this you just need to add an attribute <tt>hovers</tt> which contains a list of JSON objects with the following attributes:
* <tt>id</tt>, this is the identifier of an object in the associated SVG file; this attribute is optional; if it is not present the id specified in the VisB event will be used.
* <tt>attr</tt> a valid SVG attribute
* <tt>enter</tt> a value which will be used when the mouse enters the area of the object
* <tt>leave</tt> a value which will be used to restore the attribute when the mouse leaves the area
Note that the enter and leave values have to be static at the moment; in future we plan to allow B formulas here and also apply the repetition/replacement mechanism specified above.
If you just wish to attach a hover to an SVG object (and no B operation/event) you can set the event field of the VisB event to the empty string (<tt>"event":""</tt>).
You should not use attributes for the hover which are set by VisB items.

Here is an example VisB event with hovers:
<pre>
{
"id": "button",
"event": "toggle_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"},
{ "attr":"opacity", "enter":"0.8", "leave":"1.0"}]
}
</pre>

A VisB event can now also contain an list of items with the attributes <tt>id</tt>, <tt>attr</tt>, <tt>enabled</tt> and <tt>disabled</tt>.
When the associated event is enabled, the attribute of the SVG object with the given id is set to the value provided in the enabled attribute, otherwise the disabled attribute value is used.
As above the item id is optional and defaults to the id of the VisB event.
Here is an example VisB event with hovers and an items list:
<pre>
{
"id": "button",
"event": "press_button",
"hovers": [{ "attr":"stroke-width", "enter":"6", "leave":"1"}],
"items": [{"attr":"fill", "disabled":"\"green\"", "enabled":"\"red\""}]
},
</pre>

== Replication / Loops ==

You can use the <tt>repeat</tt> and <tt>for</tt> attributes to replicate a VisB
item or event.
Replication consists in duplicating the item or event, and replacing <tt>%0</tt> within the identifier and value attributes of the time with the repeated string or integer.

For example, the repeat instruction below will result in the creation of three VisB items, one for id <tt>txt_ttd1</tt>, for <tt>txt_ttd2</tt>, and one for <tt>txt_ttd3</tt>.
The value formula for <tt>txt_ttd1</tt> is <tt>"IF 1: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"</tt>.
<pre>
{
"repeat": ["1","2","3"],
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>

A for loop can be used instead for the above example as follows:
<pre>
{
"for": {"from":1, "to":3},
"id":"txt_ttd%0",
"attr":"x",
"value":"IF %0: dom(TTD) THEN visb_ttd_back(%0) ELSE -1000 END"
},
</pre>
The for loop also allows an optional <tt>step</tt> attribute.

It is possible to apply both <tt>repeat</tt> and <tt>for</tt> attributes at the same time, as this example shows.
(The exact details of multiple iterations for a VisB item might change in future.)

<pre>
{
"repeat": [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20],
"for": {"from":1, "to":20},
"id": "tile%1x%0",
"event": "TryQueen",
"hovers": [{ "attr":"opacity", "enter":"0.5", "leave":"1"}],
"predicates" : ["i=%1","j=%0"]
}
</pre>

As of version 1.11.0 you can also use nested for loops.
As of version 1.11.1 of ProB you can also use B expressions for the <tt>from</tt>, <tt>to</tt> and <tt>step</tt> attributes of a for loop.
However, these expressions must be evaluable without having access to any constants or variables. Indeed, the for and repeat loops are processed once when loading a VisB file, independently of any given state.
So, you can only access identifiers of <tt>SETS</tt> section of a B machine.
It may still be useful, e.g., to iterate over an enumerated or deferred set (TRAINS below):

<pre>
{
"for": {"from":1, "to":"card(TRAINS)"},
...
}
</pre>

The <tt>INT_TO_ENUM</tt> external function available as of ProB 1.11.1 can be useful in expressions here to convert the iteration variable back to an enumerated or deferred set element.
For example, <tt>INT_TO_ENUM(TRAINS,1)</tt> refers to the first element of the set <tt>TRAINS</tt>.

== VisB Definitions (in JSON file) ==

As of ProB Tcl/Tk 1.11.0 it is possible to include local definitions in the VisB JSON file.
Each definition has a name and a value formula.
Definitions are evaluated in order of appearance (a later definition can thus refer to an ealier one) and are evaluated in a state before evaluating VisB items.

<pre>
"definitions":[
{ "name":"xscale",
"value" : "(100.0 / real(NrOfTrackElements))"
},
{ "name":"visb_train_rear",
"value" : "%x.(x:dom(train_rear)|xscale * real(train_rear(x)))"
}]
</pre>

The VisB definitions are particularly useful for Event-B models (as you can use [[Summary_of_B_Syntax#Reals |REAL numbers]] and also have access to [[External_Functions|external functions]] such as LibraryStrings or LibraySVG).
But they are not yet available for events in ProB2-UI.

== VisB Additional SVG Objects ==

As of version 1.12.0 of ProB Tcl/Tk you can add new SVG objects to your SVG file.
You can use for and repeat loops (see above) to create an arbitrary number of objects.
This is useful for making flexible visualisations which work with an arbitrary number
of objects.
The same rules and limitations for for/repeat loops apply as for items above.

Every entry in the svg_objects list
* an <tt>svg_class</tt> attribute, which can be, e.g., line, circle, rect, ...
* an object <tt>id</tt> attribute
* an optional <tt>comment</tt> attribute
* any other attribute will be used to create the SVG object and should be valid for the specified svg_class

Here is an example (taken from [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/blob/master/Physics/n_bodies_visb.json here]) where NOBJS is a DEFINITION inside a B machine:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"NOBJS"},
"svg_class":"circle",
"id":"body%0",
"cx":"45",
"cy":"15",
"r":"10",
"stroke":"black",
"stroke-width":"0.5",
"fill":"green"
} ]
</pre>

Here is another example where TRAINS is a deferred or enumerated set of the B model being visualised:

<pre>
"svg_objects":[
{
"for":{"from":1,"to":"card(TRAINS)"},
"svg_class":"rect",
"id":"fresh_train_rect%0",
"x":"0",
"y":"0",
"height":"10",
"width":"20",
"comment":"train current position rectangle"
}
]
</pre>

== VisB DEFINITIONS ==
As of version 1.12 you can also provide many of the VisB annotations via B DEFINITIONS.
This can be done in addition to a VisB JSON file or completely replacing the JSON file.

By adding this definition to your B machine you specify that you wish to use an empty
SVG file as base:
<pre>
VISB_JSON_FILE == "";
</pre>

With a VISB_SVG_BOX definition you can set the size of the generated empty SVG file:
<pre>
VISB_SVG_BOX == rec(height:floor(vscale)*25+20, width:1800);
</pre>
Note: you can also provide an optional <tt>viewBox</tt> attribute as a B string.

Via VISB_SVG_CONTENTS definitions you can add new textual content to the base SVG file:
<pre>
VISB_SVG_CONTENTS == '''
<defs>
...
```;
</pre>

With definitions starting with with VISB_SVG_OBJECTS you can add new SVG objects:
<pre>
VISB_SVG_OBJECTS1 == rec(`svg_class`:"rect",`id`:"i1",x:20,y:20,height:20,width:20,fill:"blue");
VISB_SVG_OBJECTS2 == rec(`svg_class`:"circle",`id`:"i2",cx:30,cy:30,r:20,fill:"red");
</pre>
Each definition can either add a single record or add a set of records in one go.
The definition should only depend on base sets or constants of the model (see, however, notes for ProB 1.13.0 or later below).
In addition the constants used in the above definitions should only have one possible value.
For example, suppose that the constant P has 5 elements then this will create 5 SVG lines.
Observe that we use the new Event-B-style set comprehension for convenience and that tuples can be used for the <tt>id</tt> field..
<pre>
VISB_SVG_OBJECTS3 == {i•i:P|rec(`svg_class`:"line",`id`:("line",i),x1:0,y1:i,x2:i,y2:i)};
</pre>

Similarly, you can use VISB_SVG_UPDATES definitions to specify attributes that depend on the
value of constants and variables of the animated B model:
<pre>
VISB_SVG_UPDATES1== rec(`id`:"i2",fill: IF x>0 THEN "red" ELSE "green" END);
</pre>

Hovers can be defined using VISB_SVG_HOVER definitions (only for objects that have been created with VISB_SVG_OBJECTS) and click events can be defined using
VISB_SVG_EVENTS definitions with attributes <tt>id</tt>, <tt>event</tt> and optionally <tt>predicate</tt>.
Here is a minimal example that just uses the VisB DEFINITIONS without any external JSON or SVG file:
<pre>
MACHINE button_def
// An example that uses VisB DEFINITIONS instead of a JSON and SVG file
DEFINITIONS
VISB_JSON_FILE == "";
VISB_SVG_BOX == rec(height:200, width:240);
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:"100",cy:"100", r:"80", stroke:"black", `stroke-width`:"3");
VISB_SVG_UPDATES == rec(`id`:"button",
fill: IF button=TRUE THEN "green" ELSE "red" END);
VISB_SVG_HOVERS == rec(`id`:"button",
stroke:"gray", `stroke-width`:"5");
VISB_SVG_EVENTS == rec(`id`:"button", event:"toggle_button", predicate:"btrue")
VARIABLES button
INVARIANT button:BOOL
INITIALISATION button := FALSE
OPERATIONS
toggle_button = BEGIN
button:= bool(button=FALSE)
END
END
</pre>

As of version 1.13.0 of ProB you can also use dynamic expressions in object definitions; the above definitions can thus be written more compactly:
<pre>
VISB_SVG_OBJECTS == rec(`id`:"button", svg_class:"circle",
cx:100,cy:100, r:80, stroke:"black", `stroke-width`:3,
fill: IF button=TRUE THEN "green" ELSE "red" END,
event:"toggle_button",
hovers: rec(stroke:"gray", `stroke-width`:"5"));
</pre>

In 1.13.0 you can also use a "children" attribute to specify groups.
The children attribute should evaluate to a set of strings pointing to ids of SVG objects.
The following example shows this for for defining the children of "mygroup".
Also observe the use of the new [[Summary_of_B_Syntax#Strings:|template string syntax]] for the transform attribute.
<pre>
VISB_SVG_FILE == "";
VISB_SVG_BOX == rec(height:400, width:450);
VISB_SVG_OBJECTS1 == {i•i:0..9|rec(`id`:("r",i), svg_class:"rect",
fill:IF i=x THEN "red" ELSE "green" END,
x:10+10*i, y:100, height:20, width:4)};
VISB_SVG_OBJECTS2 == rec(`id`:"mygroup", svg_class:"g",
children: {i•i:0..9|("r",i)},
transform:```rotate(${x*40},50,100)```
)
</pre>

Version 1.13.1 also adds a new virtual <tt>title</tt> attribute that can be set in such SVG_OBJECTS.
This will create a tooltip box displaying the value of the attribute. (Internally this gets transformed into children SVG title objects.) These tooltips are independent of the other VisB hovers (and in contrast to these hovers the value of the title attribute can be dynamic, i.e., depend on the model's variables).

In VisB event predicates, the local identifier VISB_CLICK_META_INFOS can be used to access information like shift or command key presses and mouse positions during a click. It represents a record of the following type:
<pre>
rec(altKey: BOOL,
ctrlKey: BOOL,
jsVars: STRING <-> STRING,
metaKey: BOOL,
pageX: INTEGER,
pageY: INTEGER,
shiftKey: BOOL
)
</pre>

It also enables usage of JavaScript values: <tt>VISB_CLICK_META_INFOS'jsVars("MYID")</tt>. The value must first be assigned in a <tt>script</tt> tag in the SVG using <tt>visb_vars["${MYID}"]</tt>.

== Examples ==

Some examples can be found in the [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples visb-visualisation-examples] repository.
We have a small [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel/-/blob/master/notebooks/manual/VisB_Features.ipynb Jupyter notebook manual] on the DEFINITION features of VisB.
More details and examples will be added later.

== Caveats ==

* Beware that you need to escape quotation marks and slashes in the JSON file for fields containing B expressions. Also, you cannot use newline.
* Hovers are currently evaluated once statically and cannot make use of B expressions. To make hover information dependent on the state, use the visibility attribute to make hidden SVG objects (which can be adapted depending on the state using VisB items) visible. The [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] illustrates this idea.

== Tips and Tricks ==

It is sometimes useful to use simple coordinates for your VisB items and B expressions, e.g. x coordinates of 0..100.
You can quite often do this and use the SVG transform attribute to scale and move the SVG object to the right place.
The simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
In essence your SVG file can contain this:
<pre>
<polygon id = "ttd_polyline"
points="0,0 100,0"
stroke="gray" fill="none"
transform="translate(10,22.5)" />
</pre>
and the VisB JSON file contains this, making use of LibrarySVG.def (automatically available) external function svg_axis:
<pre>
{
"id":"ttd_polyline",
"attr":"points",
"value":"svg_axis({0} \\/ ran(%tt.(tt:TTDS|1+max(TTD_TrackElements(tt)))),100.0/real(TrackElementNumber+1),100.0,2.0)",
"comment":"show ticks for TTD Limits"
},
</pre>

Observe that we had to escape the slash of the union operator.
Also observe, that we are able to use [[Summary_of_B_Syntax#Reals:|floating numbers]] in the new version of ProB, which is very useful for VisB visualisations.

It can be useful to use style and class to make it easier to change your color scheme or other styling attributes within your visualisation consistently.
Again, the simple [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train train VisB example] shows how to do this.
E.g., your SVG file could contain towards the top this definition:
<pre>
<style id="style_ttd_ts_mp">
.ttd {
stroke : none;
stroke-width: 0.2;
opacity: 0.7
}
.red-occupied-ttd {
fill : red
}
</style>
</pre>
Later you can then use it to style your objects:
<pre>
<polygon id = "occupied_ttd_polygon"
points="0,0 0,2 10,2 10,0 70,0 70,1 90,1 90,0"
class = "ttd red-occupied-ttd"
transform="translate(10,23)" />
</pre>

You can then modify the class using VisB items. Classes can also be useful for hovers, by simply exchanging one style for another when the mouse is over an objects (again, see [https://gitlab.cs.uni-duesseldorf.de/general/stups/visb-visualisation-examples/-/tree/master/Train the train example]).
Recent versions of ProB also support adding and removing a class, which is useful for hovers when the class is modified by VisB items:
<pre>
{
"id":"train_polygon_tr1",
"event":"TrainMoveForward",
"hovers": [{ "attr":"class", "enter":"+train-hover", "leave":"-train-hover"}]
}
</pre>

== Debugging and HTML Export ==

In classical B models you can store your default VisB visualisation in the DEFINITIONS section:
<pre>
DEFINITIONS
VISB_JSON_FILE == "TwoTrains.json"
</pre>

For debugging it can be useful to use VisB within ProB Tcl/Tk: if you choose to visualise the current state with VisB, ProB will generate a stand-alone HTML file which is opened in a browser.
In the browser you can open the (Javascript) developer console and you will be alerted to warnings and errors (which unfortunately, are currently not shown in ProB2-UI).
Upon changing the state in the animator, the HTML file will be regenerated and the VisB file re-loaded if necessary.
The HTML export also displays hovers, but cannot react to clicks.
The HTML export is also available in ProB2-UI (in the export menu in the top-right corner).

ProB can also export the entire animation history to a standalone HTML file that can be passed to other persons (without requiring access to the B model or to ProB).
In ProB Tcl/Tk you can right-click on the history pane and choose "View History in VisB".
In probcli you can use the command <tt>-visb JSONFILE HTMLFILE</tt> to export the history.
In ProB2-UI you can click on the export icon in the upper right hand corner:

[[File:ProB2UI_VisB_View_Export.png|center|550px]]

The ProB2-UI table visualisation view (Visualisation menu) also contains tables to help debug VisB items and events:

[[File:ProB2UI_VisB_Debug_Table_View.png|center|550px]]

This view is also available in ProB Tcl/Tk in the Visualize menu (States submenu).
ProB2-UI also has another inspection view that can be obtained by clicking on the "i" (info) icon in the the VisB toolbar.

=== Using the VisB exported HTML file ===

You should be able to open the exported HTML using a regular browser.
Within the web page (see the image below) you can then do the following:
* single step through the trace by clicking the "Forward" and "Backward" buttons, or clicking on individual steps of the trace
* execute the entire trace nd see changes to the visualisation by clicking one of the "Run Trace" buttons
* you can inspect the value of the sets, constants and variables at every step by expanding the corresponding tabs
Some meta information can be found at the bottom of the trace.

[[File:ProB2UI_VisB_View_ExportedHTML.png|center|550px]]

== Citing VisB ==
This is the Bibtex entry for an article about VisB [https://rdcu.be/b4rqh in the ABZ'2020 proceedings]:
<pre>
@inproceedings{WerthLeuschel:abz2020,
author = {Michelle Werth and Michael Leuschel},
title = {{VisB}: A Lightweight Tool to Visualize Formal Models with {SVG} Graphics},
booktitle = {Proceedings ABZ 2020},
editor="Raschke, Alexander and M{\'e}ry, Dominique and Houdek, Frank",
year = {2020},
series = {LNCS 12071},
pages = "260--265",
isbn="978-3-030-48077-6"
}
</pre>

== Installing the VisB plugin for older ProB2-UI versions ==

'''Note:''' The following instructions are for ProB2-UI version 1.0.0 '''only'''. On current versions of ProB2-UI (1.1.0 and later), VisB is included by default and '''does not need to be installed separately'''.

To install the VisB plugin in ProB2-UI 1.0.0 you need to:

# [https://www3.hhu.de/stups/downloads/prob2/plugins/VisB-1.0.0.jar Download the VisB plugin jar file].
# In the "Advanced" menu of ProB2-UI, choose "Plugin Menu".
# Click on the "Add Plugin..." button.
# Select the VisB jar file that you have downloaded.
# Choose the "Open VisB" command in the Advanced menu to start VisB.

External Functions

2025-04-02T05:36:28Z

Jan Gruteser: /* Standard Libraries provided by ProB */

[[Category:User Manual]]
[[Category: Advanced Feature]]

As of version 1.3.5-beta7 ProB can make use of externally defined functions.
These functions must currently be written in Prolog (in principle C, Java, Tcl or even other languages can be used via the SICStus Prolog external function interfaces).
These functions can be used to write expression, predicates, or substitutions.
The general mechanism that is used is to mark certain DEFINITIONS as external, in which case ProB will make use of external Prolog code rather than using the right-hand-side of the DEFINITION whenever it is used. However, these DEFINITIONS can often (unless they are polymorphic) be wrapped into B (constant) functions. If you just want to use the standard external functions already defined by ProB, then you don't have to understand this mechanism in detail (or at all).

We have a PDF describing the external functions generated from a [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-kernel ProB-Jupyter] notebook:
[[File:ExternalFunctions.pdf]]
The Notebook [https://gitlab.cs.uni-duesseldorf.de/general/stups/prob2-jupyter-notebooks is available] and can now be [https://mybinder.org/v2/git/https%3A%2F%2Fgitlab.cs.uni-duesseldorf.de%2Fgeneral%2Fstups%2Fprob2-jupyter-notebooks/master?filepath=manual%2FExternalFunctions.ipynb launched via binder].

== Standard Libraries provided by ProB ==
In a first instance we have predefined a series of external functions and grouped them in various library machines and definition files:
* <tt>LibraryMath.mch</tt>: defining sin, cos, tan, sinx, cosx, tanx, logx, gcd, msb, random as well as access to all other Prolog built-in arithmetic functions.
* <tt>LibraryStrings.mch</tt>: functions manipulating B STRING objects by providing <tt>length</tt>, <tt>append</tt>, <tt>split</tt> and conversion functions <tt>chars</tt>, <tt>codes</tt>.
* <tt>LibraryStrings.def</tt> used by <tt>LibraryStrings.mch</tt>: providing direct access to various operators on strings (<tt>STRING_LENGTH</tt>, <tt>STRING_APPEND</tt>, <tt>STRING_SPLIT</tt> <tt>INT_TO_STRING</tt>,...)
* <tt>LibraryFiles.mch</tt>: various functions to obtain information about files and directories in the underlying file system
* <tt>LibraryIO.def</tt>: providing functions to write information to screen or file. Note: these external functions are polymorphic and as such cannot be defined as B constants: you have to use the DEFINITIONS provided in <tt>LibraryIO.def</tt>.
* <tt>CHOOSE.def</tt>: providing the [http://planetmath.org/encyclopedia/HilbertsEpsilonOperator.html Hilbert choice operator] for choosing a designated element from each set. Again, this function is polymorphic and thus cannot be defined as a B function. This function is useful for defining [[Recursively_Defined_Functions|recursive functions]] over sets (see also [[TLA]]). Note that it in ProB it is undefined for the empty set.
* <tt>LibraryMeta.def</tt>: providing access to meta-information about the loaded model (<tt>PROJECT_INFO</tt>), about the state space (<tt>HISTORY</tt>, <tt>STATE_TRANS</tt>, ...) and about ProB itself (<tt>GET_PREF</tt>, <tt>PROB_INFO_STR</tt>, <tt>PROB_INFO_INT</tt>,..).
* <tt>LibraryReals.def</tt>: providing access to operators on [[Reals and Floats]] (<tt>RSIN</tt>, <tt>RCOS</tt>, <tt>RTAN</tt>, <tt>REXP</tt>, <tt>ROUND</tt>, <tt>RLOG</tt>,<tt>RSQRT</tt>,...).
* <tt>LibraryRegex.def</tt>: providing access to regular expression operators on strings (<tt>REGEX_MATCH</tt>, <tt>REGEX_REPLACE</tt>, <tt>REGEX_SEARCH</tt>,...)
* <tt>LibraryCSV.def</tt>: contains a <tt>READ_CSV</tt> external function to read in CSV files or strings and convert them to a B data structure
* <tt>LibrarySVG.def</tt>: providing utility functions for VisB (<tt>svg_points</tt>, <tt>svg_axis</tt>,...)
* <tt>LibraryXML.def</tt>: contains a <tt>READ_XML</tt> external function to read in XML files or strings and convert them to a B data structure with strings and records. Also contains <tt>READ_JSON_AS_XML</tt>/<tt>READ_JSON_FROM_STRING_AS_XML</tt> to read JSON files and converting them to the same B format.
* <tt>LibraryBits.def</tt>: contains bit-manipulation functions on integers (<tt>BNOT</tt>, <tt>BAND</tt>, <tt>BXOR</tt>,...).
* <tt>SORT.def</tt>: providing sorting related functions (<tt>SORT</tt>, <tt>SQUASH</tt>, <tt>REPLACE</tt>).
* <tt>SCCS.def</tt>: providing access to <tt>SCCS</tt> to compute the strongly connected components of a relation and <tt>CLOSURE1</tt> an alternative algorithm for compting the transitive closure of a relation.
* <tt>LibraryJSON.def</tt> and <tt>LibraryJSON.mch</tt> providing the functions <tt>READ_JSON</tt>, <tt>READ_JSON_FROM_STRING</tt>, <tt>WRITE_JSON</tt>, <tt>WRITE_JSON_TO_STRING</tt> and the freetype <tt>JsonValue</tt> to read and write JSON data.
* <tt>LibraryZMQ_RPC.def</tt> and <tt>LibraryZMQ_RPC.mch</tt>: providing access to a JSON RPC (Remote Procedure Call) library either over regular sockets or ZMQ sockets. More information is available on [[JSON and Sockets]].

Since version 1.5 the standard library is shipped with ProB and references to machines and DEFINITION-files in the standard library are resolved automatically when referenced (see [[PROBPATH]] for information about how to customize the lookup path).

To use a library machine you can use the <tt>SEES</tt> mechanism:
SEES LibraryMath
Note that for rules machines (.rmch) you have to use <tt>REFERENCES</tt> instead.

In general you can do the following with an external function, such as <tt>sin</tt>, wrapped into a constant:
* apply the function: <tt>sin(x)</tt>
* compute the image of the function: <tt>sin[1..100]</tt>
* compose the function with a finite relation on the left: <tt>([1..100] ; sin)</tt>
* compute the domain of the function: <tt>dom(sin)</tt>
To use a library definition file, you need to include the file in the DEFINITIONS clause:
DEFINITIONS
"LibraryIO.def"

== Overview of the External Function DEFINITION Mechanism ==

Currently, external functions are linked to classical B machines using B DEFINITIONS as follows:
* one definition, which defines the function as it is seen by tools other than ProB (e.g., Atelier-B). Suppose we want to declare an external cosinus function named <tt>COS</tt>, then this definition could be <tt>COS(x) == cos(x)</tt>.
* one definition declaring the type of the function. For <tt>COS</tt> this would be <tt>EXTERNAL_FUNCTION_COS == INTEGER --> INTEGER</tt>.
* Prolog code which gets called by ProB in place of the right-hand-side of the first definition
Usually, it is also a good idea to encapsulate the external function inside a CONSTANT which is defined as a lambda abstraction with as body simply the call to the first DEFINITION. For <tt>COS</tt> this would be <tt>cos = %x.(x:NATURAL|COS(x))</tt>. Observe that for Atelier-B this is a tautology.
For ProB, the use of such a constant allows one to have a real B function representing the external function, for which we can compute the domain, range, etc.

For the typing of an external function <tt>NAME</tt> with type <tt>TYPE</tt> there are three possibilities, depending on whether the function is a function, a predicate or a substitution:
* <tt>EXTERNAL_FUNCTION_NAME == TYPE</tt>
* <tt>EXTERNAL_PREDICATE_NAME == TYPE</tt>
* <tt>EXTERNAL_SUBSTITUTION_NAME == TYPE</tt>

In case the external function is polymorphic, the <tt>DEFINITION</tt> can take extra arguments: each argument is treated like a type variable.
For example, the following is used in <tt>CHOOSE.def</tt> to declare the [http://planetmath.org/encyclopedia/HilbertsEpsilonOperator.html Hilbert choice operator]:
* <tt>EXTERNAL_FUNCTION_CHOOSE(T) == (POW(T)-->T) </tt>

Rules-DSL

2025-03-31T10:29:44Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML validation report as in ProB2-UI for the current animation state.
To validate all rules, use this option in combination with <code>-execute_all</code>.
The HTML report option is also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check in the report (of the type <tt>STRING</tt>), e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Rules-DSL

2025-03-31T10:29:18Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML validation report as in ProB2-UI for the current animation state.
To validate all rules, use this option in combination with <code>-execute_all</code>.
The HTML report option is also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check in the report, e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Rules-DSL

2025-03-31T10:29:04Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML validation report as in ProB2-UI for the current animation state.
To validate all rules, use this option in combination with <code>-execute_all</code>.
The HTML report option is also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <code>RULE_REPORT_CONTEXT</code> you can include context information about the check run in the report, e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Rules-DSL

2025-03-31T10:28:52Z

Jan Gruteser: /* Rule Validation with probcli */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML validation report as in ProB2-UI for the current animation state.
To validate all rules, use this option in combination with <code>-execute_all</code>.
The HTML report option is also available in ProB Tcl/Tk via the visualization menu.
Using the special definition <tt>RULE_REPORT_CONTEXT</tt> you can include context information about the check run in the report, e.g. the file name of a validated XML file.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Using the Command-Line Version of ProB

2025-03-31T07:56:57Z

Jan Gruteser:

[[Category:Tutorial]]
[[Category:User Manual]]
[[Category:ProB Cli]]

The command-line version of ProB, called probcli, offers many of the features of the standalone Tcl/Tk Version via the command-line. As such, you can run ProB from your shell scripts or in your Makefiles.
These pages refer to version 1.6 of ProB. Some features are only available in the nightly build of ProB. You can run <tt>probcli –help</tt> to find out which commands are supported by your version of ProB. For Bash users we provide [[Bash Completion|command completion]] support.

Note: the order of commands is not relevant for <tt>probcli</tt> (except within groups of commands such as <tt>-p MAXINT 127</tt>). Any argument that is not recognised by <tt>probcli</tt> is treated as a filename to be analysed.

[[file:ProBTerminalizerDemo.gif|center||600px]]

== Conventions used ==

The following conventions are used in this guide:

{| cellpadding="10"
| valign="top" | <replaceme>
| All values that should be replaced with some value are shown withing < >
|-
| valign="top" | line breaks
| Command synopsis for command may be broken up on several lines. When typing commands enter all option on the same line.
|}

== Synopsis ==

<pre>probcli [--help]
<filename> [ <options> ]</pre>

The underscore within all options can as of version 1.5.1-beta7 be replaced with dashes. Also, all commands can either be typed with single leading dashes or double leading dashes.
For example, all of the following commands have the same effect:
probcli M.mch -model_check
probcli M.mch -model-check
probcli M.mch --model_check
probcli M.mch --model-check

== Options ==

=== -mc <nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| model check; checking at most <nr> states
|}

Example

probcli my.mch -mc 100

Note: with a value of nr=1 ProB will only inspect the "virtual" root node (and compute its outgoing transitions).
Also see the related options <tt>-nodead, -noinv, -nogoal, -noass</tt> to influence which kinds of errors are reported by <tt>-mc</tt>.
You can also set a target goal predicate using the <tt>-goal "PRED"</tt> command and limit the scope of the model checking using the <tt>-scope "PRED"</tt> command.

=== -model_check ===

The same as <tt>-mc</tt> but without a limit on the number of nodes checked.
ProB will run until the entire state space is explored.

=== -no<x> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| restrict errors reported by model checking (-mc), TLC model checking (-mc_with_tlc), animation (-animate) and execution (-execute) with <x>=dead,inv,goal,ass
* -nodead : do not report deadlocks
* -noinv : do not report invariant violations
* -nogoal : do not stop if a state satisfying the GOAL predicate has been found
* -noass : do not report assertion violations
|}

Example

probcli my.mch -mc 1000 -nodead -nogoal

=== -disable_timeout ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| turn off ProB's timeout mechanism, e.g., for computing enabled operations and invariant checking; this can sometimes speed up model checking (-mc or -model_check) and animation (-animate). Available as of version 1.5.1-beta7.
|}

Example

probcli my.mch -model-check -disable-timeout

=== -bf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed breadth-first during model checking
|}

Example

probcli my.mch -bf -mc 1000

=== -df ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed depth-first during model checking
|}

Example

probcli my.mch -df -mc 1000

=== -mc_mode <M> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| influence how the model checker proceeds. Available as of version 1.5.1. Supersedes the <tt>-df</tt> and <tt>-bf</tt> switches.
Possible values for the mode <M> are: <ul>
<li><tt>df</tt> (depth-first traversal),</li>
<li><tt>bf</tt> (breadth-first traversal),</li>
<li><tt>mixed</tt> (mixed depth-first / breadth-first traversal with random choice; currently the default),</li>
<li><tt>random</tt> (choosing next node to process completely at random), </li>
<li><tt>hash</tt> (similar to random, but uses the Prolog hash function of a node instead of a random number generator),</li>
<li><tt>heuristic</tt> (try and use <tt>HEURISTIC_FUNCTION</tt> provided by user in <tt>DEFINITIONS</tt> clause). Some explanations can be found [[Blocks_World_(Directed_Model_Checking)|in an example about directed model checking]].</li>
<li><tt>out_degree_hash</tt> (prioritise nodes with fewer outgoing transitions; mainly useful for deadlock checking)
</ul>
|}

Example

probcli my.mch -model_check -mc_mode random

=== --timeout <N> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Global timeout in ms for model checking and refinement checking.
This does not influence the timeout used for computing individual transitions/operations.
This has to be set with the -p TIME_OUT <N>. Note that the <tt>TIME_OUT</tt> preference also influences other computations, such as invariant checking or static assertion checking, where it is multiplied by a factor. See the description of the -p option.
|}

Example

probcli my.mch -timeout 10000

=== -t ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| trace check (associated .trace file must exist)
|}

Example

probcli my.mch -t

=== -init ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| initialise specification
|}

Example

probcli my.mch -init
nr_of_components(1)
% checking_component_properties(1,[])
% enumerating_constants_without_constraints([typedval(fd(_24428,ID),global(ID),iv)])
% grounding_wait_flags
grounding_component(1)
grounding_component(2)
% found_enumeration_of_constants(0,2)
% backtrack(found_enumeration_of_constants(0,2))
% found_enumeration_of_constants(0,1)
% backtrack(found_enumeration_of_constants(0,1))
<- 0: SETUP_CONSTANTS :: root
% Could not set up constants with parameters from trace file.
% Will attempt any possible initialisation of constants.
| 0: SETUP_CONSTANTS success -->0
- <- 1: INITIALISATION :: 0
% Could not initialise with parameters from trace file.
% Will attempt any possible initialisation.
ALL OPERATIONS COVERED
- | 1: INITIALISATION success -->2
- - SUCCESS

=== -cbc <OPNAME> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| constraint-based invariant checking for an operation (also use <OPNAME>=all)
|}

Example

probcli my.mch -cbc all

=== -cbc_deadlock ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Perform constraint-based deadlock checking (also use -cbc_deadlock_pred PRED)
|}

This will try to find a state which satisfies the invariant and properties and where no operation/event is enabled.
Note: if ProB finds a counter example then the machine cannot be proven to be deadlock free. However, the particular state may not be reachable from the initial state(s). If you want to find a reachable deadlock you have to use the model checker.

=== -cbc_deadlock_pred <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based deadlock finding given a predicate
|}

This is like -cbc_deadlock but you provide an additional predicate. ProB will only find deadlocks which also make this predicate true.

Example

probcli my.mch -cbc_deadlock_pred "n=15"

=== -cbc_assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based checking of assertions on constants
|}
This will try and find a solution for the constants which make an assertion (on constants) false.

You can use the extra command <tt>-cbc_output_file FILE</tt> to write the result of this check to a file.
You can also use the extra command <tt>-cbc_option contradiction_check</tt> to ask ProB to check if there is a contradiction in the properties (in case the check did not find a counter-example to the assertions). The extra command <tt>-cbc_option unsat_core</tt> tells ProB to compute the unsatisfiable core in case a proof the assertions was found.
Note that the <tt>TIME_OUT</tt> preference is multiplied by 10 for this command.

There are various variations of this command:
-cbc_assertions_proof
-cbc_assertions_tautology_proof
Both commands do not allow enumeration warnings to occur.
The latter command ignores the PROPERTIES and tries to check whether the ASSERTION(s) are tautologies.
Both commands can be useful to use ProB as a Prover/Disprover (as is done in Atelier-B 4.3).

=== -cbc_sequence <SEQ> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based searching for a sequence of operation names (separated by semicolons)
|}
This will try and find a solution for the constants, initial variable values and parameters which make execution of the given sequence of operations possible.

Example

probcli my.mch -cbc_sequence "op1;op2"

=== -strict ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| raise error and stop probcli if anything unexpected happens, e.g., if model checking finds a counter example or trace checking fails or any unexpected error happens
|}

Example

probcli my.mch -t -strict

=== -expcterr <ERR> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| expect error to occur (<ERR>=cbc,mc,ltl,...)
Tell ProB that you expect a certain error to occur. Mainly useful for regression tests (in conjunction with the -strict option).
|}

Example

probcli examples/B/Benchmarks/CarlaTravelAgencyErr.mch -mc 1000 -expcterr invariant_violation -strict

=== -animate <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| random animation (max Nr steps)
|}

Animates the machine randomly, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-animate_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-animate_all</tt> could run forever.

Example

probcli my.mch -animate 100

=== -execute <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| execution (max Nr steps)
|}

Executes the "first" enabled operation of a machine, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-execute_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-execute_all</tt> could run forever.

In contrast to -animate, -execute will
* always choose the first enabled operation it finds and stop searching for further enabled operations in that state (-animate will compute all enabled operations up to the limit set by the <tt>MAX_OPERATIONS</tt> or <tt>MAX_INITIALISATIONS</tt> preference and then choose randomly); the order of operations in the B machine is thus important for -execute
* not store intermediate states in the state space; as such -execute is faster but after execution one only has access to the first state and the final state of execution

Example

probcli my.mch -execute 100

=== -execute_all===

See <tt>-execute <Nr></tt> above.

=== -det_check ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if every step of the animation is deterministic (i.e., only one operation is possible, and it can only be executed in one possible way as far as parameters and result is concerned).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -animate 100 -det_check

=== -det_constants ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if the SETUP_CONSTANTS step is deterministic (i.e., only one way to set up the constants is possible).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -init -det_constants
=== -his <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save animation history to a file
|}

Save the animation (or model checking) history to a text file. Operations are separated by semicolons.
The output can be adapted using the -his_option command. With -his_option show_states the -his command will also write out all states to the file (in the form of comments before and after operations). With -his_option show_init only the initial state is written out.
The -his command is executed after the -init, -animate, -t or -mc commands.
See also the -sptxt command to only write the current values of variables and constants to a file.

Example

probcli -animate 5 -his history.txt supersimple.mch

Additionally we can have the initialised variables and constants:

probcli -animate 5 -his history.txt -his_option show_init supersimple.mch

And we can have in addition the values of the variables in between (and at the end):

probcli -animate 5 -his history.txt -his_option show_states supersimple.mch

With -his_option trace_file as only option, probcli will write the history in Prolog format, which can later be used by the -t command.

=== -i ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| interactive animation
|}

After performing the other commands, ProB stays in interactive mode and allows the user to manually animate the loaded specification.

Example

probcli my.mch -i

=== -repl ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start interactive read-eval-print-loop
|}

Example

probcli my.mch -p CLPFD TRUE -repl

A list of commands can be obtained by typing <tt>:help</tt> (just help for versions 1.3.x of probcli). The interactive read-eval-print-loop can be exited using <tt>:q</tt> (just typing a return on a blank line for versions 1.3.x of probcli)..
If in addition you want see a graphical representation of the solutions found you can use the following command and open the <tt>out.dot</tt> file using dotty or GraphViz:
probcli -repl -evaldot ~/out.dot

You can also use the <tt>-eval</tt> command to evaluate specific formulas or expressions:
probcli -eval "1+2"
For convenience, these formulas can also be put into a separate file:
probcli -eval_file MyFormula.txt

=== -c ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print coverage statistics
|}

Example

probcli my.mch -mc 1000 -c

You can also use the longer name for the command:

probcli my.mch -mc 1000 --coverage

There is also a version which prints a shorter summary (and which is much faster for large state spaces):

probcli my.mch -mc 1000 --coverage_summary

=== -cc <Nr> <Nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print and check coverage statistics
Print coverage statistics and check that the given number of nodes and transitions have been computed.
|}

Example

probcli my.mch -mc 1000 -cc 10 25

=== -p <PREFERENCE> <VALUE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set <PREFERENCE> to <VALUE>. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

You can also use --pref instead of -p.
Example

probcli my.mch -p TIME_OUT 8000 -p CLPFD TRUE -mc 10000

=== -pref_group <PREFGROUP> <SETTING> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set to the group of preferences <PREFGROUP> to a predefined setting <SETTING>
|}

Example

probcli my.mch -pref_group model_check unlimited

Available groups and settings are:

* PREFERENCE GROUP integer : SETTINGS [int32] : Values for MAXINT and MININT
* PREFERENCE GROUP time_out : SETTINGS [disable_time_out] : To disable TIME_OUT
* PREFERENCE GROUP model_check : SETTINGS [disable_max,unlimited] : Model Checking Limits
* PREFERENCE GROUP dot_colors : SETTINGS [classic,dreams,winter] : Colours for Dot graphs

=== -prefs <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set preferences from preference file <FILE>. The file should be created by the Tcl/Tk version of ProB; this version automatically creates a file called ProB_Preferences.pl. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

Example

probcli my.mch -prefs ProB_Preferences.pl

=== -card <GS> <VAL> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set cardinality (scope in Alloy terminology) of a B deferred set. This overrides the default cardinality (which can be set using <tt>-p DEFAULT_SETSIZE <VAL></tt>).
|}

Example

probcli my.mch -card PID 5

=== -goal <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set GOAL predicate for model checker
|}

Example

probcli my.mch -mc 10000000 -goal "n=18" -strict -expcterr goal_found

=== -scope <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set SCOPE predicate for model checker; states which do not satisfy the SCOPE predicate will be ignored (invariant will not be checked and no outgoing transitions will be computed)
|}

Example

probcli my.mch -mc 10000000 -scope "n<18"

=== -s <PORT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on given port
|}

Example

probcli my.mch ...

=== -ss ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on port 9000
|}

Example

probcli my.mch ...

=== -sf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on some free port
|}

Example

probcli my.mch ...

=== -sptxt <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants and variables to a file
|}

Save the values of constants and variables to a text file in classical B syntax.
The -sptxt command is executed after the -init, -animate, -t or -mc commands.
The values are fully written out (some sets, e.g., infinite sets may be written out symbolically).

See also the -his command.

Example

probcli -animate 5 -sptxt state.txt supersimple.mch

This will write the values of all variables and constants to the file state.txt after animating the machine 5 steps.

=== -cache <DIRECTORY>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants (and in future also variables) to a file to avoid recomputation
|}

This commands saves the values of constants for the current B machine and puts those values into files in the specified directory. The command will also tell ProB to try and reuse constants saved for subsidiary machines (included using SEES for example) whenever possible.
The purpose of the command is to avoid recomputing constants as much as possible, as this can be very time consuming.
This also works for values of variables computed in the initialisation or even using operations.
However, we do not support refinements at the moment.

Note: this command can also be used when starting up the ProB Tcl/Tk version.

=== -logxml <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities and results of probcli in XML format in <LogFile>
|}

A schema declaration file (xsd) can be found at <tt>doc/logxml_xsd.xml</tt> in the ProB [[Download#Sourcecode|Prolog sources]].
The log file contains information about the various commands performed by probcli.
It also contains version information, the parameters provided to probcli and details about the errors that occured.

Example

probcli my.mch -mc 1000 -logxml log.xml

=== -logxml_write_vars <PREFIX> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| after processing other commands (such as -execute) write values of variables having prefix PREFIX in their name into the XML log file (if XML logging has been activated using the -logxml command)
|}

Example

probcli my.mch -execute 1000 -logxml log.xml -logxml_write_vars out

=== -l <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in <LogFile> using Prolog format
|}

Example

probcli my.mch -mc 1000 -l my.log

=== -ll ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in /tmp/prob_cli_debug.log
|}

Example

probcli my.mch -mc 1000 -ll

=== -lg <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| analyse <LogFile> using gnuplot
|}

Example

probcli my.mch ...

=== -pp <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>
|}

Example

probcli my.mch -pp my_pp.mch

=== -ppf <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>, force printing of all type infos
|}

Example

probcli my.mch -ppf my_ppf.mch

=== -v ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set ProB into verbose mode
|}

Example

probcli my.mch -mc 1000 -v

=== -version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print version information
|}

There is also an alternate command called -svers which just prints the version number of ProB.
Example

probcli -version
ProB Command Line Interface
VERSION 1.3.4-rc1 (9556:9570M)
$LastChangedDate: 2011-11-16 18:36:18 +0100 (Wed, 16 Nov 2011) $
Prolog: SICStus 4.2.0 (x86_64-darwin-10.6.0): Mon Mar 7 20:03:36 CET 2011
Application Path: /Users/leuschel/svn_root/NewProB

probcli -svers
VERSION 1.3.4-rc1 (9556:9570M)

You can use <tt>probcli -version -v</tt> to obtain more information about your version of probcli.

=== -check_java_version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check Java and B parser version information
|}

This command is available as of ProB version 1.5.1-beta5 or higher. It can be useful to check that your Java is correctly installed and that the ProB B parser can operate correctly

probcli -check_java_version
Result of checking Java version:
Java is correctly installed and version 1.7.0_55-b13 is compatible with ProB requirements (>= 1.7).
ProB B Java Parser available in version: 2016-02-25 15:27:18.55.

=== -assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check ASSERTIONS of your machine

If you provide the -t switch, the ASSERTIONS will be checked after executing your trace. Otherwise, they will be checked in an initial state.
ProB will automatically initialize the machine if you have not provide the -init or -t switch.

You can also use -main_assertions to check only the ASSERTIONS found in the main file.

If your ASSERTIONS are all static (i.e., make no reference to variables), then ProB will remove all CONSTANTS and PROPERTIES from your machine which are not linked (directly or indirectly) to the ASSERTIONS.
This optimization will only be made if you provide no other switch, such as -mc or -animate which may require the computation of the variables.
|}

Example

probcli my.mch -init -assertions

=== -property ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| virtually add predicate to PROPERTIES
|}

Example

probcli my.mch -property "PRED"

=== -properties ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check PROPERTIES
Note: you should probably first initialise the machine (e.g., with -init).
If the constants have not yet been set up, probcli will debug the properties.
|}

Example

probcli my.mch -init -properties

=== -dot_output <PATH> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| define path for generation of dot files for false properties or assertions
|}

This option is applicable to -properties and -assertions. It will result in individual dot files being generated for every false or unknown property or assertion. Assertions are numbered A0,A1,... and properties P0,P1,... You can also force to generate dot files for all properties (i.e., also the true ones) using the -dot_all command-line flag.

Example

probcli my.mch -init -properties -dot_output somewhere/

This will generate files somewhere/my_P0_false.dot, somewhere/my_P1_false.dot, ...

=== -rc ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| runtime checking of types/pre-/post-conditions
|}

Example

probcli my.mch ...

=== -ltlfile <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL formulas in file <FILE>
|}

Example

probcli my.mch ...

=== -ltlassertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL assertions (in DEFINITIONS)
|}

Example

probcli my.mch ...

=== -ltllimit <LIMIT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| explore at most <LIMIT> states when model-checking LTL
|}

Example

probcli my.mch ...

=== -save <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save state space for later refinement check
|}

Example

probcli my.mch ...

=== -refchk <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| refinement check against previous saved state space
|}

Example

probcli my.mch ...

=== -mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE> ===

Generate test cases for the given specification. Each test case consists of a sequence of operations resp. events (a so-called trace) that
* start in a state after an initialisation
* contain a requested operation/event
* end in a state where the <EndPredicate> is fulfilled

The user can specify what requested operations/events are with the
option [[#-mcm_cover <Operation(s)>|-mcm_cover]].

ProB uses a "breadth-first" approach to search for test cases. When all requested operations/events are covered by test cases within maximum length M, the algorithm will explore the complete state space with that maximum distance M from the initialisation. It outputs all found traces that satisfy the requirements above.

The algorithm stops if either
* it has covered all required operations/events with the current search depth
* or it has reached the maximum search depth or maximum number of explored states.

The required parameters are:
;Depth
: The maximum length of traces that the algorithm searches for test until it stops without covering all required operations/events.
;MaxStates
: The maximum number of explored states until the algorithm stops without covering all required operations/events.
;EndPredicate
: A predicate in B syntax that the last state of a trace must fulfil. If you do not have any restrictions on that state, use a trivially true predicate like '''1=1'''
;FILE
: The found test cases a written to the XML file <FILE>.

Example

probcli my.mch -mcm_tests 10 2000 "EndStateVar=TRUE" testcases.xml -mcm_cover op1,op2

generates test cases for the operations '''op1''' and '''op2''' of the specification '''my.mch'''. The maximum length of traces is 10, at most 2000 states are explored. Each test case ends in a state where the predicate '''EndStateVar=TRUE''' holds. The found test cases are written to a file '''testcases.xml'''.

As of version 1.6.0, the operation arguments are also written to the XML file.
The preference <tt>INTERNAL_ARGUMENT_PREFIX</tt> can be used to provide a prefix for internal operation arguments; any argument/parameter whose name starts with that prefix is considered an internal parameter and not shown in the trace file.
Also, as of version 1.6.0, the non-deterministic initialisations are shown in the XML trace file: all variables and constants where more than one possible initialisation exists are written into the trace file, as argument of an INITIALISATION event.

=== -mcm_cover <Operation(s)> ===

Specify an operation or event that should be covered when generating test cases with the '''-mcm_test''' option. Multiple operations/events can be specified by seperating them by comma or by using '''-mcm_cover''' several times.

See [[#-mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE>|-mcm-tests]] for further details.

=== -spdot <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Write graph of the state space to a dot <FILE>
|}

Example

probcli my.mch -mc 100 -spdot my_statespace.dot

=== -cbc_tests <Depth> <EndPredicate> <File> ===
Generate test cases by constraint solving with maximum
length '''Depth''', the last state satisfies '''EndPredicate'''
and the test cases are written to '''File'''. If the predicate is the empty string we assume truth. If the filename is the empty string no file is generated. See also the page on [[Test_Case_Generation]].

=== -cbc_cover <Operation> ===
When generating CB test cases, '''Operation''' should be covered.
The option can be given multiple times to specify several operations.
Alternatively, multiple operations can be separated by a comma. You can also use the option <pre>-cbc_cover_match PartialName</pre> to match all operations whose name contains PartialName. See also the page about [[Test_Case_Generation]].

=== -test_description <File> ===
Read the options for constraint based test case generation from '''File'''.

=== -bmc <Depth> ===

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Run the [[Bounded_Model_Checking|bounded model checker]] until maximum trace depth <Depth> specified. Looks for invariant violations using the constraint-based test case generation algorithm.
|}

Example

probcli my.mch -bmc 20

=== -csp-guide <File> ===
Use the CSP File '''File''' to guide the B Machine ("CSP||B").
(This feature is included since version 1.3.5-beta7.)

=== -rule_report <File>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Generates HTML rule validation report for rules machines (.rmch) at the specified location <File> for the current animation state.
|}

Useful in combination with <tt>-execute</tt> or <tt>-execute_all</tt>.

Example

probcli myrules.rmch -execute_all -rule_report my_report.html

== Environment Variables ==

Set NO_COLOR environment variable to disable terminal colors.
See [https://no-color.org https://no-color.org].

== Preferences ==

You can use these preferences within the command:

-p <PREFERENCE> <VALUE>

{| cellpadding="5" cellspacing="1" width="100%" border="1"
!style="background-color:lightgrey;" | <PREFERENCE>
!style="background-color:lightgrey;" | <VALUE>
|-
| MAXINT
| nat ==> MaxInt, used for expressions such as xx::NAT (2147483647 for 4 byte ints)
|-
| MININT
| neg ==> MinInt, used for expressions such as xx::INT (-2147483648 for 4 byte ints)
|-
| DEFAULT_SETSIZE
| nat ==> Size of unspecified deferred sets in SETS section. Will be used if a set s is neither enumerated, has no no card(s)=nr predicate in the PROPERTIES and has no scope_s == Nr DEFINITION.
|-
| MAX_INITIALISATIONS
| nat ==> Max Number of Initialisations and ways to setup constants computed
|-
| MAX_OPERATIONS
| nat ==> Max Number of Enablings per Operation Computed
|-
| ANIMATE_SKIP_OPERATIONS
| bool ==> Animate operations which are skip or PRE C THEN skip
|-
| COMPRESSION
| bool ==> Use more aggressive COMPRESSION when storing states
|-
| EXPAND_CLOSURES_FOR_STATE
| bool ==> Convert lazy form back into explicit form for Variables, Constants, Operation Arguments. ProB will sometimes try to keep certain sets symbolic. If this preference is TRUE then ProB will try to expand those sets for variables and constants after an operation has been executed.
|-
| SYMBOLIC
| bool ==> Lazy expansion of lambdas and set comprehensions. By default ProB will keep certain sets symbolic (e.g., sets it knows are infinite). When this preference is set to TRUE then all set comprehensions and lambda abstractions will at first be kept symbolic and only expanded into explicit form if needed.
|-
| CLPFD
| bool ==> Use CLP(FD) solver for B integers (restricts range to -2^28..2^28-1 on 32 bit computers). Setting this preference to TRUE should substantially improve ProB's ability to solve complicated predicates involving integers. However, it may cause CLP(FD) overflows in certain circumstances.
|-
| SMT
| bool ==> Enable SMT-Mode (aggressive treatment of : and /: inside predicates). With this predicate set to TRUE ProB will be better at solving certain constraint solving tasks. It should be enabled when doing constraint-based invariant or deadlock checking. ProB Tcl/Tk will turn this preference on automatically for those checks.
|-
| STATIC_ORDERING
| bool ==> Use static ordering to enumerate constants which occur in most PROPERTIES first
|-
| SYMMETRY_MODE
| [off,flood,nauty,hash] ==> Symmetry Mode: off,flood,canon,nauty,hash
|-
| TIME_OUT
| nat1 ==> Time out for computing enabled transitions (in ms, is multiplied by a factor for other computations)
|-
| PROOF_INFO
| bool ==> Use Proof Information to restrict invariant checking to affected unproven clauses. Most useful in EventB for models exported from Rodin.
|-
| TRY_FIND_ABORT
| bool ==> Try more aggressively to detect ill-defined expressions (e.g. applying function outside of domain), may slow down animator
|-
| NUMBER_OF_ANIMATED_ABSTRACTIONS
| nat ==> How many levels of refined models are animated by default
|-
| ALLOW_INCOMPLETE_SETUP_CONSTANTS
| bool ==> Allow ProB to proceed even if only part of the CONSTANTS have been found.
|-
| PARTITION_PROPERTIES
| bool ==> Partition predicates (PROPERTIES) into components
|-
| USE_RECORD_CONSTRUCTION
| bool ==> Records: Check if axioms/properties describe a record pattern
|-
| OPERATION_REUSE
| bool ==> Try and reuse previously computed operation effects in B/Event-B
|-
| SHOW_EVENTB_ANY_VALUES
| bool ==> Show top-level ANY variable values of B Operations without parameters as parameters
|-
| RANDOMISE_OPERATION_ORDER
| bool ==> Randomise order of operations when computing successor states
|-
| EXPAND_FORALL_UPTO
| nat ==> When analysing predicates: max. domain size for expansion of forall (use 0 to disable expansion)
|-
| MAX_DISPLAY_SET
| int ==> Max size for pretty-printing sets (-1 means no limit)
|-
| CSP_STRIP_SOURCE_LOC
| bool ==> Strip source location for CSP; will speed up model checking
|-
| WARN_WHEN_EXPANDING_INFINITE_CLOSURES
| int ==> Warn when expanding infinite closures if MAXINT larger than:
|-
| TRACE_INFO
| bool ==> Provide various tracing information on the terminal/console.
|-
| DOUBLE_EVALUATION
| bool ==> Evaluate PREDICATES positively and negatively when analyzing assertions or properties
|-
| RECURSIVE
| bool ==> Lazy expansion of *Recursive* set Comprehensions and lambdas
|-
| IGNORE_HASH_COLLISIONS
| bool ==> Ignore Hash Collisions (if true not all states may be computed, visited states are not memorised !)
|-
| FORGET_STATE_SPACE
| bool ==> Do not remember state space (mainly useful in conjunction with Ignore Hash Collisions)
|-
| NEGATED_INVARIANT_CHECKING
| bool ==> Perform double evaluation (positive and negative) when checking invariants
|-
| CSE
| bool ==> Perform common-sub-expression elimination
|-
| CSE_SUBST
| bool ==> Perform common-sub-expression elimination also for B substitutions
|}

Example

probcli my.mch -p TIME_OUT 5000 -p CLPFD TRUE -p SYMMETRY_MODE hash -mc 1000

== Some probcli examples ==

To load a file My.mch, setup the constants and initialize it do:
<pre>
probcli -init My.mch
</pre>
To load a file M.mch, setup the constants, initialize and then check all assertions with Atelier-B's default values for MININT and MAXINT and an increased timeout of 5 seconds do:
<pre>
probcli -init -assertions -p MAXINT 2147483647 -p MININT -2147483647 -p TIME_OUT 5000 M.mch
</pre>

To fully model check a specification M.mch while tryining to minimize memory consumption do:
<pre>
probcli -model_check -p COMPRESSION TRUE M.mch
</pre>

To model check a specification M.mch while trying to minimize memory consumption further by not storing processed stats and using symmetry reduction (and accepting hash collisions) do:
<pre>
probcli -p COMPRESSION -p IGNORE_HASH_COLLISIONS TRUE -p FORGET_STATE_SPACE TRUE -p SYMMETRY_MODE hash -model_check M.mch
</pre>

== Command-line Arguments for ProB Tcl/Tk ==

Note that the stand-alone Tcl/Tk version also supports a limited form of command-line preferences:
* '''FILE''' (the name/path of the file to be loaded)
* '''-prefs PREF_FILE''' (to use a specific preferences file, rather than the default ProB_Preferences.pl in your home folder)
* '''-batch''' (to instruct ProB not to try to bring up windows, but to print information only to the terminal)
* '''-selfcheck''' (to run the standard unit tests)
* '''-t''' (to perform the Trace Check on the default trace file associated with the specification)
* '''-tcl TCL_Command''' (to run a particular pre-defined Tcl command)
* '''-mc''' (to perform model checking)
* '''-c''' (to compute the coverage)
* '''-ref''' (to perform the default trace refinment check)

However, the comand-line version of ProB, called '''probcli''', provides more features. It also does not depend on Tcl/Tk and can therefore be run on systems without Tcl/Tk.
{{Feedback}}

Using the Command-Line Version of ProB

2025-03-31T07:37:08Z

Jan Gruteser:

[[Category:Tutorial]]
[[Category:User Manual]]
[[Category:ProB Cli]]

The command-line version of ProB, called probcli, offers many of the features of the standalone Tcl/Tk Version via the command-line. As such, you can run ProB from your shell scripts or in your Makefiles.
These pages refer to version 1.6 of ProB. Some features are only available in the nightly build of ProB. You can run <tt>probcli –help</tt> to find out which commands are supported by your version of ProB. For Bash users we provide [[Bash Completion|command completion]] support.

Note: the order of commands is not relevant for <tt>probcli</tt> (except within groups of commands such as <tt>-p MAXINT 127</tt>). Any argument that is not recognised by <tt>probcli</tt> is treated as a filename to be analysed.

[[file:ProBTerminalizerDemo.gif|center||600px]]

== Conventions used ==

The following conventions are used in this guide:

{| cellpadding="10"
| valign="top" | <replaceme>
| All values that should be replaced with some value are shown withing < >
|-
| valign="top" | line breaks
| Command synopsis for command may be broken up on several lines. When typing commands enter all option on the same line.
|}

== Synopsis ==

<pre>probcli [--help]
<filename> [ <options> ]</pre>

The underscore within all options can as of version 1.5.1-beta7 be replaced with dashes. Also, all commands can either be typed with single leading dashes or double leading dashes.
For example, all of the following commands have the same effect:
probcli M.mch -model_check
probcli M.mch -model-check
probcli M.mch --model_check
probcli M.mch --model-check

== Options ==

=== -mc <nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| model check; checking at most <nr> states
|}

Example

probcli my.mch -mc 100

Note: with a value of nr=1 ProB will only inspect the "virtual" root node (and compute its outgoing transitions).
Also see the related options <tt>-nodead, -noinv, -nogoal, -noass</tt> to influence which kinds of errors are reported by <tt>-mc</tt>.
You can also set a target goal predicate using the <tt>-goal "PRED"</tt> command and limit the scope of the model checking using the <tt>-scope "PRED"</tt> command.

=== -model_check ===

The same as <tt>-mc</tt> but without a limit on the number of nodes checked.
ProB will run until the entire state space is explored.

=== -no<x> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| restrict errors reported by model checking (-mc), TLC model checking (-mc_with_tlc), animation (-animate) and execution (-execute) with <x>=dead,inv,goal,ass
* -nodead : do not report deadlocks
* -noinv : do not report invariant violations
* -nogoal : do not stop if a state satisfying the GOAL predicate has been found
* -noass : do not report assertion violations
|}

Example

probcli my.mch -mc 1000 -nodead -nogoal

=== -disable_timeout ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| turn off ProB's timeout mechanism, e.g., for computing enabled operations and invariant checking; this can sometimes speed up model checking (-mc or -model_check) and animation (-animate). Available as of version 1.5.1-beta7.
|}

Example

probcli my.mch -model-check -disable-timeout

=== -bf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed breadth-first during model checking
|}

Example

probcli my.mch -bf -mc 1000

=== -df ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| proceed depth-first during model checking
|}

Example

probcli my.mch -df -mc 1000

=== -mc_mode <M> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| influence how the model checker proceeds. Available as of version 1.5.1. Supersedes the <tt>-df</tt> and <tt>-bf</tt> switches.
Possible values for the mode <M> are: <ul>
<li><tt>df</tt> (depth-first traversal),</li>
<li><tt>bf</tt> (breadth-first traversal),</li>
<li><tt>mixed</tt> (mixed depth-first / breadth-first traversal with random choice; currently the default),</li>
<li><tt>random</tt> (choosing next node to process completely at random), </li>
<li><tt>hash</tt> (similar to random, but uses the Prolog hash function of a node instead of a random number generator),</li>
<li><tt>heuristic</tt> (try and use <tt>HEURISTIC_FUNCTION</tt> provided by user in <tt>DEFINITIONS</tt> clause). Some explanations can be found [[Blocks_World_(Directed_Model_Checking)|in an example about directed model checking]].</li>
<li><tt>out_degree_hash</tt> (prioritise nodes with fewer outgoing transitions; mainly useful for deadlock checking)
</ul>
|}

Example

probcli my.mch -model_check -mc_mode random

=== --timeout <N> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Global timeout in ms for model checking and refinement checking.
This does not influence the timeout used for computing individual transitions/operations.
This has to be set with the -p TIME_OUT <N>. Note that the <tt>TIME_OUT</tt> preference also influences other computations, such as invariant checking or static assertion checking, where it is multiplied by a factor. See the description of the -p option.
|}

Example

probcli my.mch -timeout 10000

=== -t ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| trace check (associated .trace file must exist)
|}

Example

probcli my.mch -t

=== -init ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| initialise specification
|}

Example

probcli my.mch -init
nr_of_components(1)
% checking_component_properties(1,[])
% enumerating_constants_without_constraints([typedval(fd(_24428,ID),global(ID),iv)])
% grounding_wait_flags
grounding_component(1)
grounding_component(2)
% found_enumeration_of_constants(0,2)
% backtrack(found_enumeration_of_constants(0,2))
% found_enumeration_of_constants(0,1)
% backtrack(found_enumeration_of_constants(0,1))
<- 0: SETUP_CONSTANTS :: root
% Could not set up constants with parameters from trace file.
% Will attempt any possible initialisation of constants.
| 0: SETUP_CONSTANTS success -->0
- <- 1: INITIALISATION :: 0
% Could not initialise with parameters from trace file.
% Will attempt any possible initialisation.
ALL OPERATIONS COVERED
- | 1: INITIALISATION success -->2
- - SUCCESS

=== -cbc <OPNAME> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| constraint-based invariant checking for an operation (also use <OPNAME>=all)
|}

Example

probcli my.mch -cbc all

=== -cbc_deadlock ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Perform constraint-based deadlock checking (also use -cbc_deadlock_pred PRED)
|}

This will try to find a state which satisfies the invariant and properties and where no operation/event is enabled.
Note: if ProB finds a counter example then the machine cannot be proven to be deadlock free. However, the particular state may not be reachable from the initial state(s). If you want to find a reachable deadlock you have to use the model checker.

=== -cbc_deadlock_pred <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based deadlock finding given a predicate
|}

This is like -cbc_deadlock but you provide an additional predicate. ProB will only find deadlocks which also make this predicate true.

Example

probcli my.mch -cbc_deadlock_pred "n=15"

=== -cbc_assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based checking of assertions on constants
|}
This will try and find a solution for the constants which make an assertion (on constants) false.

You can use the extra command <tt>-cbc_output_file FILE</tt> to write the result of this check to a file.
You can also use the extra command <tt>-cbc_option contradiction_check</tt> to ask ProB to check if there is a contradiction in the properties (in case the check did not find a counter-example to the assertions). The extra command <tt>-cbc_option unsat_core</tt> tells ProB to compute the unsatisfiable core in case a proof the assertions was found.
Note that the <tt>TIME_OUT</tt> preference is multiplied by 10 for this command.

There are various variations of this command:
-cbc_assertions_proof
-cbc_assertions_tautology_proof
Both commands do not allow enumeration warnings to occur.
The latter command ignores the PROPERTIES and tries to check whether the ASSERTION(s) are tautologies.
Both commands can be useful to use ProB as a Prover/Disprover (as is done in Atelier-B 4.3).

=== -cbc_sequence <SEQ> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Constraint-based searching for a sequence of operation names (separated by semicolons)
|}
This will try and find a solution for the constants, initial variable values and parameters which make execution of the given sequence of operations possible.

Example

probcli my.mch -cbc_sequence "op1;op2"

=== -strict ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| raise error and stop probcli if anything unexpected happens, e.g., if model checking finds a counter example or trace checking fails or any unexpected error happens
|}

Example

probcli my.mch -t -strict

=== -expcterr <ERR> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| expect error to occur (<ERR>=cbc,mc,ltl,...)
Tell ProB that you expect a certain error to occur. Mainly useful for regression tests (in conjunction with the -strict option).
|}

Example

probcli examples/B/Benchmarks/CarlaTravelAgencyErr.mch -mc 1000 -expcterr invariant_violation -strict

=== -animate <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| random animation (max Nr steps)
|}

Animates the machine randomly, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-animate_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-animate_all</tt> could run forever.

Example

probcli my.mch -animate 100

=== -execute <Nr>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| execution (max Nr steps)
|}

Executes the "first" enabled operation of a machine, maximally Nr of steps. It will stop if a deadlock is reached and report an error. You can also use the command <tt>-execute_all</tt>, which will only stop at a deadlock (and not report an error). Be careful: <tt>-execute_all</tt> could run forever.

In contrast to -animate, -execute will
* always choose the first enabled operation it finds and stop searching for further enabled operations in that state (-animate will compute all enabled operations up to the limit set by the <tt>MAX_OPERATIONS</tt> or <tt>MAX_INITIALISATIONS</tt> preference and then choose randomly); the order of operations in the B machine is thus important for -execute
* not store intermediate states in the state space; as such -execute is faster but after execution one only has access to the first state and the final state of execution

Example

probcli my.mch -execute 100

=== -execute_all===

See <tt>-execute <Nr></tt> above.

=== -det_check ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if every step of the animation is deterministic (i.e., only one operation is possible, and it can only be executed in one possible way as far as parameters and result is concerned).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -animate 100 -det_check

=== -det_constants ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check if animation steps are deterministic
|}

Checks if the SETUP_CONSTANTS step is deterministic (i.e., only one way to set up the constants is possible).
Currently this option has only an effect for the -animate <Nr> and the -init commands.

Example

probcli my.mch -init -det_constants
=== -his <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save animation history to a file
|}

Save the animation (or model checking) history to a text file. Operations are separated by semicolons.
The output can be adapted using the -his_option command. With -his_option show_states the -his command will also write out all states to the file (in the form of comments before and after operations). With -his_option show_init only the initial state is written out.
The -his command is executed after the -init, -animate, -t or -mc commands.
See also the -sptxt command to only write the current values of variables and constants to a file.

Example

probcli -animate 5 -his history.txt supersimple.mch

Additionally we can have the initialised variables and constants:

probcli -animate 5 -his history.txt -his_option show_init supersimple.mch

And we can have in addition the values of the variables in between (and at the end):

probcli -animate 5 -his history.txt -his_option show_states supersimple.mch

With -his_option trace_file as only option, probcli will write the history in Prolog format, which can later be used by the -t command.

=== -i ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| interactive animation
|}

After performing the other commands, ProB stays in interactive mode and allows the user to manually animate the loaded specification.

Example

probcli my.mch -i

=== -repl ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start interactive read-eval-print-loop
|}

Example

probcli my.mch -p CLPFD TRUE -repl

A list of commands can be obtained by typing <tt>:help</tt> (just help for versions 1.3.x of probcli). The interactive read-eval-print-loop can be exited using <tt>:q</tt> (just typing a return on a blank line for versions 1.3.x of probcli)..
If in addition you want see a graphical representation of the solutions found you can use the following command and open the <tt>out.dot</tt> file using dotty or GraphViz:
probcli -repl -evaldot ~/out.dot

You can also use the <tt>-eval</tt> command to evaluate specific formulas or expressions:
probcli -eval "1+2"
For convenience, these formulas can also be put into a separate file:
probcli -eval_file MyFormula.txt

=== -c ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print coverage statistics
|}

Example

probcli my.mch -mc 1000 -c

You can also use the longer name for the command:

probcli my.mch -mc 1000 --coverage

There is also a version which prints a shorter summary (and which is much faster for large state spaces):

probcli my.mch -mc 1000 --coverage_summary

=== -cc <Nr> <Nr> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print and check coverage statistics
Print coverage statistics and check that the given number of nodes and transitions have been computed.
|}

Example

probcli my.mch -mc 1000 -cc 10 25

=== -p <PREFERENCE> <VALUE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set <PREFERENCE> to <VALUE>. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

You can also use --pref instead of -p.
Example

probcli my.mch -p TIME_OUT 8000 -p CLPFD TRUE -mc 10000

=== -pref_group <PREFGROUP> <SETTING> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set to the group of preferences <PREFGROUP> to a predefined setting <SETTING>
|}

Example

probcli my.mch -pref_group model_check unlimited

Available groups and settings are:

* PREFERENCE GROUP integer : SETTINGS [int32] : Values for MAXINT and MININT
* PREFERENCE GROUP time_out : SETTINGS [disable_time_out] : To disable TIME_OUT
* PREFERENCE GROUP model_check : SETTINGS [disable_max,unlimited] : Model Checking Limits
* PREFERENCE GROUP dot_colors : SETTINGS [classic,dreams,winter] : Colours for Dot graphs

=== -prefs <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Set preferences from preference file <FILE>. The file should be created by the Tcl/Tk version of ProB; this version automatically creates a file called ProB_Preferences.pl. For more information about preferences please have a look at [[Using_the_Command-Line_Version_of_ProB#Preferences | Preferences]]
|}

Example

probcli my.mch -prefs ProB_Preferences.pl

=== -card <GS> <VAL> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set cardinality (scope in Alloy terminology) of a B deferred set. This overrides the default cardinality (which can be set using <tt>-p DEFAULT_SETSIZE <VAL></tt>).
|}

Example

probcli my.mch -card PID 5

=== -goal <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set GOAL predicate for model checker
|}

Example

probcli my.mch -mc 10000000 -goal "n=18" -strict -expcterr goal_found

=== -scope <PRED> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set SCOPE predicate for model checker; states which do not satisfy the SCOPE predicate will be ignored (invariant will not be checked and no outgoing transitions will be computed)
|}

Example

probcli my.mch -mc 10000000 -scope "n<18"

=== -s <PORT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on given port
|}

Example

probcli my.mch ...

=== -ss ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on port 9000
|}

Example

probcli my.mch ...

=== -sf ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| start socket server on some free port
|}

Example

probcli my.mch ...

=== -sptxt <FILE>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants and variables to a file
|}

Save the values of constants and variables to a text file in classical B syntax.
The -sptxt command is executed after the -init, -animate, -t or -mc commands.
The values are fully written out (some sets, e.g., infinite sets may be written out symbolically).

See also the -his command.

Example

probcli -animate 5 -sptxt state.txt supersimple.mch

This will write the values of all variables and constants to the file state.txt after animating the machine 5 steps.

=== -cache <DIRECTORY>===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save constants (and in future also variables) to a file to avoid recomputation
|}

This commands saves the values of constants for the current B machine and puts those values into files in the specified directory. The command will also tell ProB to try and reuse constants saved for subsidiary machines (included using SEES for example) whenever possible.
The purpose of the command is to avoid recomputing constants as much as possible, as this can be very time consuming.
This also works for values of variables computed in the initialisation or even using operations.
However, we do not support refinements at the moment.

Note: this command can also be used when starting up the ProB Tcl/Tk version.

=== -logxml <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities and results of probcli in XML format in <LogFile>
|}

A schema declaration file (xsd) can be found at <tt>doc/logxml_xsd.xml</tt> in the ProB [[Download#Sourcecode|Prolog sources]].
The log file contains information about the various commands performed by probcli.
It also contains version information, the parameters provided to probcli and details about the errors that occured.

Example

probcli my.mch -mc 1000 -logxml log.xml

=== -logxml_write_vars <PREFIX> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| after processing other commands (such as -execute) write values of variables having prefix PREFIX in their name into the XML log file (if XML logging has been activated using the -logxml command)
|}

Example

probcli my.mch -execute 1000 -logxml log.xml -logxml_write_vars out

=== -l <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in <LogFile> using Prolog format
|}

Example

probcli my.mch -mc 1000 -l my.log

=== -ll ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| log activities in /tmp/prob_cli_debug.log
|}

Example

probcli my.mch -mc 1000 -ll

=== -lg <LogFile> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| analyse <LogFile> using gnuplot
|}

Example

probcli my.mch ...

=== -pp <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>
|}

Example

probcli my.mch -pp my_pp.mch

=== -ppf <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| pretty-print internal representation to <FILE>, force printing of all type infos
|}

Example

probcli my.mch -ppf my_ppf.mch

=== -v ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| set ProB into verbose mode
|}

Example

probcli my.mch -mc 1000 -v

=== -version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| print version information
|}

There is also an alternate command called -svers which just prints the version number of ProB.
Example

probcli -version
ProB Command Line Interface
VERSION 1.3.4-rc1 (9556:9570M)
$LastChangedDate: 2011-11-16 18:36:18 +0100 (Wed, 16 Nov 2011) $
Prolog: SICStus 4.2.0 (x86_64-darwin-10.6.0): Mon Mar 7 20:03:36 CET 2011
Application Path: /Users/leuschel/svn_root/NewProB

probcli -svers
VERSION 1.3.4-rc1 (9556:9570M)

You can use <tt>probcli -version -v</tt> to obtain more information about your version of probcli.

=== -check_java_version ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check Java and B parser version information
|}

This command is available as of ProB version 1.5.1-beta5 or higher. It can be useful to check that your Java is correctly installed and that the ProB B parser can operate correctly

probcli -check_java_version
Result of checking Java version:
Java is correctly installed and version 1.7.0_55-b13 is compatible with ProB requirements (>= 1.7).
ProB B Java Parser available in version: 2016-02-25 15:27:18.55.

=== -assertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check ASSERTIONS of your machine

If you provide the -t switch, the ASSERTIONS will be checked after executing your trace. Otherwise, they will be checked in an initial state.
ProB will automatically initialize the machine if you have not provide the -init or -t switch.

You can also use -main_assertions to check only the ASSERTIONS found in the main file.

If your ASSERTIONS are all static (i.e., make no reference to variables), then ProB will remove all CONSTANTS and PROPERTIES from your machine which are not linked (directly or indirectly) to the ASSERTIONS.
This optimization will only be made if you provide no other switch, such as -mc or -animate which may require the computation of the variables.
|}

Example

probcli my.mch -init -assertions

=== -property ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| virtually add predicate to PROPERTIES
|}

Example

probcli my.mch -property "PRED"

=== -properties ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check PROPERTIES
Note: you should probably first initialise the machine (e.g., with -init).
If the constants have not yet been set up, probcli will debug the properties.
|}

Example

probcli my.mch -init -properties

=== -dot_output <PATH> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| define path for generation of dot files for false properties or assertions
|}

This option is applicable to -properties and -assertions. It will result in individual dot files being generated for every false or unknown property or assertion. Assertions are numbered A0,A1,... and properties P0,P1,... You can also force to generate dot files for all properties (i.e., also the true ones) using the -dot_all command-line flag.

Example

probcli my.mch -init -properties -dot_output somewhere/

This will generate files somewhere/my_P0_false.dot, somewhere/my_P1_false.dot, ...

=== -rc ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| runtime checking of types/pre-/post-conditions
|}

Example

probcli my.mch ...

=== -ltlfile <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL formulas in file <FILE>
|}

Example

probcli my.mch ...

=== -ltlassertions ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| check LTL assertions (in DEFINITIONS)
|}

Example

probcli my.mch ...

=== -ltllimit <LIMIT> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| explore at most <LIMIT> states when model-checking LTL
|}

Example

probcli my.mch ...

=== -save <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| save state space for later refinement check
|}

Example

probcli my.mch ...

=== -refchk <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| refinement check against previous saved state space
|}

Example

probcli my.mch ...

=== -mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE> ===

Generate test cases for the given specification. Each test case consists of a sequence of operations resp. events (a so-called trace) that
* start in a state after an initialisation
* contain a requested operation/event
* end in a state where the <EndPredicate> is fulfilled

The user can specify what requested operations/events are with the
option [[#-mcm_cover <Operation(s)>|-mcm_cover]].

ProB uses a "breadth-first" approach to search for test cases. When all requested operations/events are covered by test cases within maximum length M, the algorithm will explore the complete state space with that maximum distance M from the initialisation. It outputs all found traces that satisfy the requirements above.

The algorithm stops if either
* it has covered all required operations/events with the current search depth
* or it has reached the maximum search depth or maximum number of explored states.

The required parameters are:
;Depth
: The maximum length of traces that the algorithm searches for test until it stops without covering all required operations/events.
;MaxStates
: The maximum number of explored states until the algorithm stops without covering all required operations/events.
;EndPredicate
: A predicate in B syntax that the last state of a trace must fulfil. If you do not have any restrictions on that state, use a trivially true predicate like '''1=1'''
;FILE
: The found test cases a written to the XML file <FILE>.

Example

probcli my.mch -mcm_tests 10 2000 "EndStateVar=TRUE" testcases.xml -mcm_cover op1,op2

generates test cases for the operations '''op1''' and '''op2''' of the specification '''my.mch'''. The maximum length of traces is 10, at most 2000 states are explored. Each test case ends in a state where the predicate '''EndStateVar=TRUE''' holds. The found test cases are written to a file '''testcases.xml'''.

As of version 1.6.0, the operation arguments are also written to the XML file.
The preference <tt>INTERNAL_ARGUMENT_PREFIX</tt> can be used to provide a prefix for internal operation arguments; any argument/parameter whose name starts with that prefix is considered an internal parameter and not shown in the trace file.
Also, as of version 1.6.0, the non-deterministic initialisations are shown in the XML trace file: all variables and constants where more than one possible initialisation exists are written into the trace file, as argument of an INITIALISATION event.

=== -mcm_cover <Operation(s)> ===

Specify an operation or event that should be covered when generating test cases with the '''-mcm_test''' option. Multiple operations/events can be specified by seperating them by comma or by using '''-mcm_cover''' several times.

See [[#-mcm_tests <Depth> <MaxStates> <EndPredicate> <FILE>|-mcm-tests]] for further details.

=== -spdot <FILE> ===

Description

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Write graph of the state space to a dot <FILE>
|}

Example

probcli my.mch -mc 100 -spdot my_statespace.dot

=== -cbc_tests <Depth> <EndPredicate> <File> ===
Generate test cases by constraint solving with maximum
length '''Depth''', the last state satisfies '''EndPredicate'''
and the test cases are written to '''File'''. If the predicate is the empty string we assume truth. If the filename is the empty string no file is generated. See also the page on [[Test_Case_Generation]].

=== -cbc_cover <Operation> ===
When generating CB test cases, '''Operation''' should be covered.
The option can be given multiple times to specify several operations.
Alternatively, multiple operations can be separated by a comma. You can also use the option <pre>-cbc_cover_match PartialName</pre> to match all operations whose name contains PartialName. See also the page about [[Test_Case_Generation]].

=== -test_description <File> ===
Read the options for constraint based test case generation from '''File'''.

=== -bmc <Depth> ===

{| style="color:black; background-color:#FFFFEF; border:1px solid lightgray;" cellpadding="10" cellspacing="0" width="100%"
| Run the [[Bounded_Model_Checking|bounded model checker]] until maximum trace depth <Depth> specified. Looks for invariant violations using the constraint-based test case generation algorithm.
|}

Example

probcli my.mch -bmc 20

=== -csp-guide <File> ===
Use the CSP File '''File''' to guide the B Machine ("CSP||B").
(This feature is included since version 1.3.5-beta7.)

== Environment Variables ==

Set NO_COLOR environment variable to disable terminal colors.
See [https://no-color.org https://no-color.org].

== Preferences ==

You can use these preferences within the command:

-p <PREFERENCE> <VALUE>

{| cellpadding="5" cellspacing="1" width="100%" border="1"
!style="background-color:lightgrey;" | <PREFERENCE>
!style="background-color:lightgrey;" | <VALUE>
|-
| MAXINT
| nat ==> MaxInt, used for expressions such as xx::NAT (2147483647 for 4 byte ints)
|-
| MININT
| neg ==> MinInt, used for expressions such as xx::INT (-2147483648 for 4 byte ints)
|-
| DEFAULT_SETSIZE
| nat ==> Size of unspecified deferred sets in SETS section. Will be used if a set s is neither enumerated, has no no card(s)=nr predicate in the PROPERTIES and has no scope_s == Nr DEFINITION.
|-
| MAX_INITIALISATIONS
| nat ==> Max Number of Initialisations and ways to setup constants computed
|-
| MAX_OPERATIONS
| nat ==> Max Number of Enablings per Operation Computed
|-
| ANIMATE_SKIP_OPERATIONS
| bool ==> Animate operations which are skip or PRE C THEN skip
|-
| COMPRESSION
| bool ==> Use more aggressive COMPRESSION when storing states
|-
| EXPAND_CLOSURES_FOR_STATE
| bool ==> Convert lazy form back into explicit form for Variables, Constants, Operation Arguments. ProB will sometimes try to keep certain sets symbolic. If this preference is TRUE then ProB will try to expand those sets for variables and constants after an operation has been executed.
|-
| SYMBOLIC
| bool ==> Lazy expansion of lambdas and set comprehensions. By default ProB will keep certain sets symbolic (e.g., sets it knows are infinite). When this preference is set to TRUE then all set comprehensions and lambda abstractions will at first be kept symbolic and only expanded into explicit form if needed.
|-
| CLPFD
| bool ==> Use CLP(FD) solver for B integers (restricts range to -2^28..2^28-1 on 32 bit computers). Setting this preference to TRUE should substantially improve ProB's ability to solve complicated predicates involving integers. However, it may cause CLP(FD) overflows in certain circumstances.
|-
| SMT
| bool ==> Enable SMT-Mode (aggressive treatment of : and /: inside predicates). With this predicate set to TRUE ProB will be better at solving certain constraint solving tasks. It should be enabled when doing constraint-based invariant or deadlock checking. ProB Tcl/Tk will turn this preference on automatically for those checks.
|-
| STATIC_ORDERING
| bool ==> Use static ordering to enumerate constants which occur in most PROPERTIES first
|-
| SYMMETRY_MODE
| [off,flood,nauty,hash] ==> Symmetry Mode: off,flood,canon,nauty,hash
|-
| TIME_OUT
| nat1 ==> Time out for computing enabled transitions (in ms, is multiplied by a factor for other computations)
|-
| PROOF_INFO
| bool ==> Use Proof Information to restrict invariant checking to affected unproven clauses. Most useful in EventB for models exported from Rodin.
|-
| TRY_FIND_ABORT
| bool ==> Try more aggressively to detect ill-defined expressions (e.g. applying function outside of domain), may slow down animator
|-
| NUMBER_OF_ANIMATED_ABSTRACTIONS
| nat ==> How many levels of refined models are animated by default
|-
| ALLOW_INCOMPLETE_SETUP_CONSTANTS
| bool ==> Allow ProB to proceed even if only part of the CONSTANTS have been found.
|-
| PARTITION_PROPERTIES
| bool ==> Partition predicates (PROPERTIES) into components
|-
| USE_RECORD_CONSTRUCTION
| bool ==> Records: Check if axioms/properties describe a record pattern
|-
| OPERATION_REUSE
| bool ==> Try and reuse previously computed operation effects in B/Event-B
|-
| SHOW_EVENTB_ANY_VALUES
| bool ==> Show top-level ANY variable values of B Operations without parameters as parameters
|-
| RANDOMISE_OPERATION_ORDER
| bool ==> Randomise order of operations when computing successor states
|-
| EXPAND_FORALL_UPTO
| nat ==> When analysing predicates: max. domain size for expansion of forall (use 0 to disable expansion)
|-
| MAX_DISPLAY_SET
| int ==> Max size for pretty-printing sets (-1 means no limit)
|-
| CSP_STRIP_SOURCE_LOC
| bool ==> Strip source location for CSP; will speed up model checking
|-
| WARN_WHEN_EXPANDING_INFINITE_CLOSURES
| int ==> Warn when expanding infinite closures if MAXINT larger than:
|-
| TRACE_INFO
| bool ==> Provide various tracing information on the terminal/console.
|-
| DOUBLE_EVALUATION
| bool ==> Evaluate PREDICATES positively and negatively when analyzing assertions or properties
|-
| RECURSIVE
| bool ==> Lazy expansion of *Recursive* set Comprehensions and lambdas
|-
| IGNORE_HASH_COLLISIONS
| bool ==> Ignore Hash Collisions (if true not all states may be computed, visited states are not memorised !)
|-
| FORGET_STATE_SPACE
| bool ==> Do not remember state space (mainly useful in conjunction with Ignore Hash Collisions)
|-
| NEGATED_INVARIANT_CHECKING
| bool ==> Perform double evaluation (positive and negative) when checking invariants
|-
| CSE
| bool ==> Perform common-sub-expression elimination
|-
| CSE_SUBST
| bool ==> Perform common-sub-expression elimination also for B substitutions
|}

Example

probcli my.mch -p TIME_OUT 5000 -p CLPFD TRUE -p SYMMETRY_MODE hash -mc 1000

== Some probcli examples ==

To load a file My.mch, setup the constants and initialize it do:
<pre>
probcli -init My.mch
</pre>
To load a file M.mch, setup the constants, initialize and then check all assertions with Atelier-B's default values for MININT and MAXINT and an increased timeout of 5 seconds do:
<pre>
probcli -init -assertions -p MAXINT 2147483647 -p MININT -2147483647 -p TIME_OUT 5000 M.mch
</pre>

To fully model check a specification M.mch while tryining to minimize memory consumption do:
<pre>
probcli -model_check -p COMPRESSION TRUE M.mch
</pre>

To model check a specification M.mch while trying to minimize memory consumption further by not storing processed stats and using symmetry reduction (and accepting hash collisions) do:
<pre>
probcli -p COMPRESSION -p IGNORE_HASH_COLLISIONS TRUE -p FORGET_STATE_SPACE TRUE -p SYMMETRY_MODE hash -model_check M.mch
</pre>

== Command-line Arguments for ProB Tcl/Tk ==

Note that the stand-alone Tcl/Tk version also supports a limited form of command-line preferences:
* '''FILE''' (the name/path of the file to be loaded)
* '''-prefs PREF_FILE''' (to use a specific preferences file, rather than the default ProB_Preferences.pl in your home folder)
* '''-batch''' (to instruct ProB not to try to bring up windows, but to print information only to the terminal)
* '''-selfcheck''' (to run the standard unit tests)
* '''-t''' (to perform the Trace Check on the default trace file associated with the specification)
* '''-tcl TCL_Command''' (to run a particular pre-defined Tcl command)
* '''-mc''' (to perform model checking)
* '''-c''' (to compute the coverage)
* '''-ref''' (to perform the default trace refinment check)

However, the comand-line version of ProB, called '''probcli''', provides more features. It also does not depend on Tcl/Tk and can therefore be run on systems without Tcl/Tk.
{{Feedback}}

Rules-DSL

2025-03-31T07:33:43Z

Jan Gruteser: /* B-Rules DSL */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Rule Validation with probcli===
The probcli recognises the option <code>-rule_report <file></code> which generates the same HTML validation report as in ProB2-UI for the current animation state.
To validate all rules, use this option in combination with <code>-execute_all</code>.
The HTML report option is also available in ProB Tcl/Tk via the visualization menu.

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).

Rules-DSL

2025-03-31T07:30:17Z

Jan Gruteser: /* Rules */

== B-Rules DSL ==

The B-Rules domain-specific language (B-Rules DSL) mainly provides operations for data validation. Rules allow checking for expected properties, while computations can be used to define and compute variables based on the successful execution of certain rules. Furthermore you can use functions to compute values multiple times depending on different inputs.

===Setting up a Rules Machine===
Rules machines are stored in <code>.rmch</code>-files. The general setup for the machine header is:
<pre>
RULES_MACHINE machine_name
REFERENCES list of rules machines
</pre>
The latter allows the inclusion of other rules machines and ordinary B machines that contain only constants, but not yet any other B machines. Below, <code>SETS</code>, <code>DEFINITIONS</code>, <code>PROPERTIES</code> or <code>CONSTANTS</code> can be used as in a normal B machine. Note that <code>VARIABLES</code> are not allowed as they are set by rule based computations.

====Rules====
Rules can be defined in the <code>OPERATIONS</code>-section of a rules machine. Depending on whether the expectations are met, a rule returns <code>SUCCESS</code> or <code>FAIL</code>. If a rule fails, additionally provided string messages are returned as counterexamples.
In the B Rules-DSL a rule has the following structure:
<pre>
RULE rule_name // will be the name of the operation and variable storing the result
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
ERROR_TYPES positive number of error types
BODY
arbitrarily many rule bodys (see below)
END
</pre>
The specified <code>rule_name</code> will be the name of the operation and variable storing the result.
If a rule depends on other rules, it can only be executed if the specified rules have been successfully checked, i.e. their corresponding variables <code>rule_name</code> have the value <code>SUCCESS</code>. In addition, rules can depend on computations. In this case, a rule is enabled when the specified computations have been executed. If a rule uses variables that are defined by computations, the corresponding computations are added implicitly as dependencies and do not have to be declared explicitly. Any other preconditions can be specified as an <code>ACTIVATION</code> predicate. An important note is that the activation predicate is evaluated statically at initialisation and disables the rule if the predicate is false. Activation predicates and dependencies can be omitted if they are not needed.

To use different error types (for example, if a rule has multiple bodies and it is necessary to distinguish between them), the number of error types has to be declared in the rule header.
Error types are also optional.

The actual rule conditions are specified within the body of a rule, which contains the name and the preconditions.
A rule succeeds if and only if all rule conditions in its body are satisfied.
There are two constructs for rule bodies that can be used arbitrarily often in the body of a rule.
The following is formulated in a positive way, i.e. the execution of the rule leads to <code>SUCCESS</code> if the conditions in the <code>EXPECT</code>-part are fulfilled.
In contrast to the <code>RULE_FAIL</code> body (see below), in <code>RULE_FORALL</code> you can obtain success messages (such as counter examples) for successful applications of the rule.
<pre>
RULE_FORALL
list of identifiers
WHERE
conditions on identifiers
EXPECT
conditions that must be fulfilled for this rule
ERROR_TYPE
number encoding error type, must be in range of error types
ON_SUCCESS
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list) or
```${identifier from list}``` (template string)
END
</pre>
Alternatively, a negated rule can be formulated. Here the execution of the rule results in <code>FAIL</code> if the conditions in the <code>WHEN</code>-part are fulfilled.
<pre>
RULE_FAIL
list of identifiers
WHEN
conditions on identifiers for a failing rule
ERROR_TYPE
number encoding error type, must be in range of error types
COUNTEREXAMPLE
STRING_FORMAT("errorMessage ~w", identifier from list)
END
</pre>
Counterexamples are of the type <code>INTEGER <-> STRING</code>. The integer contains the error type, while the string contains the message of the counterexample.

Also valid for the rules header are:
<pre>
RULEID id
CLASSIFICATION identifier
TAGS identifier
</pre>
The <code>CLASSIFICATION</code> keyword can be used to group the rules in the [[#Rule_Validation_in_ProB2-UI|HTML validation report]] according to their classification.

====Computations====
Computations can be used to define variables. As for rules, their activation can depend on further rules, computations or any other predicate specified as an activation condition. Again, the activation condition is evaluated at initialisation and sets the computation status variable to <code>COMPUTATION_DISABLED</code> if the predicate is false. Furthermore, a <code>DUMMY_VALUE</code> can be set, which initialises the variable with the specified value instead of the empty set before execution of the computation. This mechanism implies that each variable defined by a computation must be a set of type <code>POW(S)</code> for any <code>TYPE</code> <code>S</code>. A computation can be replaced by a previously defined computation if it sets the same variable (of the same type) by using <code>REPLACES</code>. The general syntax for computations is:
<pre>
COMPUTATION computation_name
DEPENDS_ON_RULE list of rules
DEPENDS_ON_COMPUTATION list of computations
ACTIVATION predicate
REPLACES identifier of exactly one computation
BODY
DEFINE variable_name
TYPE type of variable
DUMMY_VALUE value of variable before execution (initialisation)
VALUE value of variable after execution
END
END
</pre>
Activation predicates, dependencies, and also the dummy value can be omitted if they are not needed. After the execution of a computation, the value of the corresponding variable <code>computation_name</code> is changed from <code>NOT_EXECUTED</code> to <code>EXECUTED</code> and the variable <code>variable_name</code> has the value \texttt{VALUE}. For related computations, it may be useful to use multiple <code>DEFINE</code> blocks in one computation.
Separated by <code>;</code>, the body of a computation can contain any number of variable definitions.

====Functions====
Functions can be called from any rules machine that references the machine containing the function. Depending on input parameters that must fulfil specified preconditions, the functions returns output value(s) that must fulfil optional postconditions. In the body, any B statement can be used to (sequentially) compute the output value.
<pre>
FUNCTION output <-- function_name(list of input parameters)
PRECONDITION
predicate
POSTCONDITION
predicate
BODY
some B statements
output := ...
END
</pre>

====Additional Syntax====
There are some useful predicates available in rules machines that can be used to check the success or failure of rules. It is also possible to check whether a certain error type was returned by a rule. These are:
<ul>
<li><code>SUCCEEDED_RULE(rule1)</code>: TRUE, if the check of rule1 succeeded</li>
<li><code>SUCCEEDED_RULE_ERROR_TYPE(rule1,1)</code>: TRUE, if the check of rule1 did not fail with error type 1</li>
<li><code>GET_RULE_COUNTEREXAMPLES(rule1)</code>: set of counterexamples of rule1</li>
<li><code>FAILED_RULE(rule1)</code>: TRUE, if the check of rule1 failed</li>
<li><code>FAILED_RULE_ERROR_TYPE(rule1,2)</code>: TRUE, if check of rule1 failed with error type 2</li>
<li><code>FAILED_RULE_ALL_ERROR_TYPES(rule1)</code>: TRUE, if the check of rule1 failed with all possible error types for rule1</li>
<li><code>NOT_CHECKED_RULE(rule1)</code>: TRUE, if rule1 has not yet been checked</li>
<li><code>DISABLED_RULE(rule1)</code>: TRUE, if rule1 is disabled (its preconditions are not fulfilled)</li>
</ul>

Another functionality of rules machines are FOR-loops. Their syntax is:
<pre>
FOR variable(s) IN set
DO
operation(s)
END
</pre>
An example:
<pre>
RULE example_rule
BODY
FOR x,y IN {1 |-> TRUE, 2 |-> FALSE, 3 |-> FALSE} DO
RULE_FAIL
WHEN y = FALSE
COUNTEREXAMPLE STRING_FORMAT("example_rule_fail: ~w", x)
END
END
</pre>
This rule always fails and returns <code>{1 |-> "example_rule_fail: 2", 1 |-> "example_rule_fail: 3"}</code>.

===Rule Validation in ProB2-UI===
Rule validation has been integrated into the ProB2-UI since version 1.2.2 (not yet released).
It allows convenient execution of rules and computations together with a graphical representation of the results.
Rules are grouped by their classification and can be additionally filtered by their name, ID, or tags.
The results can also be exported as an HTML report.
In addition, dependencies of rules and computations can be visualised as a graph either for all operations or for just one operation (the HTML report and the dependency graph are generated by the ProB Java API and can also be created without ProB2-UI).

[[File:ProB2 UI Rules View.png|500px|ProB2-UI Rules View]]

===Use Rules for Data Validation===
The concept of rule validation can be used to validate data from external sources such as CSV or XML files and load the validated data into ProB by successive computations.
For an XML file, this could look as follows:
<pre>
RULES_MACHINE XML_import
DEFINITIONS
"LibraryXML.def"
CONSTANTS
xml_data
PROPERTIES
xml_data = READ_XML("xml_file.xml", "auto")
END
</pre>
Now some properties can be validated. For example:
<pre>
RULE is_supported_version_of_type_xyz
ERROR_TYPES 2
BODY
RULE_FAIL e
WHEN
1 : dom(xml_data) & e = data(1)'element & e /= "xyz"
ERROR_TYPE 1 // optional: 1 is standard type
COUNTEREXAMPLE
STRING_FORMAT("Error: could not find element 'xyz', was '"^e^"'")
END;
RULE_FAIL v
WHEN
v = xml_data(1)'attributes("version") & v /: supported_versions
ERROR_TYPE 2
COUNTEREXAMPLE
"xyz of version "^v^" is currently not supported"
END
END;
</pre>

===Internal Representation===
Each rules machine is internally translated to an ordinary B machine, which can be accessed as its internal representation.
Consider the following example rule:
<pre>
RULE rule1 BODY RULE_FAIL WHEN bfalse COUNTEREXAMPLE "" END END;

COMPUTATION comp1
BODY
DEFINE x
TYPE POW(INTEGER)
VALUE 1..10
END
END;

RULE rule2
DEPENDS_ON_RULE rule1
// DEPENDS_ON_COMPUTATION comp1
BODY
RULE_FORALL i
WHERE i : 1..10
EXPECT i > 5
COUNTEREXAMPLE STRING_FORMAT("~w <= 5", i)
END
END
</pre>
Its internal representation in classical B is the following:
<pre>
`$RESULT`,`$COUNTEREXAMPLES` <-- rule1 =
SELECT
rule1 = "NOT_CHECKED"
THEN
rule1,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{}
END;

comp1 =
SELECT
comp1 = "NOT_EXECUTED"
THEN
x,comp1 := FORCE(1 .. 10),"EXECUTED"
END;

`$RESULT`,`$COUNTEREXAMPLES` <-- rule2 =
SELECT
rule2 = "NOT_CHECKED"
& rule1 = "SUCCESS"
& comp1 = "EXECUTED"
THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "SUCCESS","SUCCESS",{} ;
VAR `$ResultTuple`,`$ResultStrings`
IN
`$ResultTuple` := FORCE({i|i : x & not(i > 5)}) ;
`$ResultStrings` := FORCE({`$String`|`$String` : STRING & #i.(i : `$ResultTuple` & `$String` = FORMAT_TO_STRING("~w <= 5",[TO_STRING(i)]))});
rule2_Counterexamples := rule2_Counterexamples \/ {1} * `$ResultStrings` ;
IF `$ResultTuple` /= {} THEN
rule2,`$RESULT`,`$COUNTEREXAMPLES` := "FAIL","FAIL",rule2_Counterexamples
END
END
END
</pre>
Observe that the implicit dependency of rule2 on comp1 (rule2 uses its variable x) is detected automatically without explicit declaration.

===Include Rules Machines into other Projects===
Currently, it is not possible to include rules machines directly into any other machines. Instead, use the rules machine at the top of the hierarchy (of the rules project) and save the internal generated machine as <code>.mch</code>-file. After changing the machine name accordingly, the rules can be included and used via this machine.
Note that in this case it is not possible to perform Rules-DSL specific methods of the ProB Java API (like detailed information about rule results).