From df28db19c74edba0d9ee5287065564fafb50ccf5 Mon Sep 17 00:00:00 2001 From: mikucionisaau Date: Tue, 16 Apr 2024 05:31:20 +0000 Subject: [PATCH] deploy: 30269bb393738d8cb16ad7cfcbcb58dfecf0fe00 --- 404.html | 2 +- categories/index.html | 6 +++--- extensions/cora/index.html | 6 +++--- extensions/ecdar/index.html | 6 +++--- extensions/index.html | 6 +++--- extensions/tiga/index.html | 6 +++--- extensions/tron/index.html | 6 +++--- gui-reference/concrete-simulator/gantt-chart/index.html | 6 +++--- gui-reference/concrete-simulator/index.html | 6 +++--- gui-reference/concrete-simulator/process/index.html | 6 +++--- .../concrete-simulator/sequence-chart/index.html | 6 +++--- .../concrete-simulator/simulation-control/index.html | 6 +++--- gui-reference/concrete-simulator/variables/index.html | 6 +++--- gui-reference/index.html | 6 +++--- gui-reference/menu-bar/edit/index.html | 6 +++--- gui-reference/menu-bar/file/index.html | 6 +++--- gui-reference/menu-bar/help/index.html | 6 +++--- gui-reference/menu-bar/index.html | 6 +++--- gui-reference/menu-bar/options/index.html | 6 +++--- gui-reference/menu-bar/tools/index.html | 6 +++--- gui-reference/menu-bar/view/index.html | 6 +++--- gui-reference/symbolic-simulator/index.html | 6 +++--- gui-reference/symbolic-simulator/process/index.html | 6 +++--- .../symbolic-simulator/sequence-charts/index.html | 6 +++--- .../symbolic-simulator/simulation-control/index.html | 6 +++--- .../symbolic-simulator/symbolic-traces/index.html | 6 +++--- gui-reference/symbolic-simulator/variables/index.html | 6 +++--- gui-reference/system-editor/declarations/index.html | 6 +++--- gui-reference/system-editor/drawing/index.html | 6 +++--- gui-reference/system-editor/index.html | 6 +++--- gui-reference/system-editor/navigation-tree/index.html | 6 +++--- gui-reference/toolbar/index.html | 6 +++--- gui-reference/verifier/index.html | 6 +++--- gui-reference/verifier/specifying/index.html | 6 +++--- gui-reference/verifier/verifying/index.html | 6 +++--- gui-reference/yggdrasil/index.html | 6 +++--- gui-reference/yggdrasil/test-code/index.html | 6 +++--- gui-reference/yggdrasil/traces/index.html | 6 +++--- .../yggdrasil/tutorial/basic-test-generation/index.html | 6 +++--- gui-reference/yggdrasil/tutorial/index.html | 6 +++--- gui-reference/yggdrasil/tutorial/using-queries/index.html | 6 +++--- .../yggdrasil/tutorial/using-variables/index.html | 6 +++--- index.html | 4 ++-- index.json | 2 +- language-reference/expressions/identifiers/index.html | 6 +++--- language-reference/expressions/index.html | 6 +++--- language-reference/index.html | 6 +++--- language-reference/query-semantics/index.html | 6 +++--- .../query-semantics/smc_queries/ci_estimation/index.html | 6 +++--- language-reference/query-semantics/smc_queries/index.html | 6 +++--- .../query-semantics/symb_queries/index.html | 6 +++--- .../query-syntax/controller_synthesis/index.html | 6 +++--- language-reference/query-syntax/index.html | 6 +++--- .../query-syntax/learning_queries/index.html | 6 +++--- .../query-syntax/statistical_queries/index.html | 6 +++--- .../query-syntax/strategy_queries/index.html | 6 +++--- .../query-syntax/symbolic_queries/index.html | 6 +++--- language-reference/reserved-keywords/index.html | 6 +++--- .../declarations/external-functions/index.html | 8 ++++---- .../system-description/declarations/functions/index.html | 6 +++--- .../system-description/declarations/index.html | 6 +++--- .../system-description/declarations/types/index.html | 6 +++--- language-reference/system-description/index.html | 6 +++--- .../system-description/parameters/index.html | 6 +++--- .../system-description/priorities/index.html | 6 +++--- .../system-description/scope-rules/index.html | 6 +++--- .../system-description/semantics/index.html | 6 +++--- .../system-definition/gantt-chart/index.html | 6 +++--- .../system-description/system-definition/index.html | 6 +++--- .../system-definition/progress-measures/index.html | 6 +++--- .../system-definition/template-instantiation/index.html | 6 +++--- .../system-description/templates/edges/index.html | 6 +++--- .../system-description/templates/index.html | 6 +++--- .../system-description/templates/locations/index.html | 6 +++--- preview-build/index.html | 6 +++--- tags/index.html | 6 +++--- toolsandapi/file-formats/index.html | 6 +++--- toolsandapi/index.html | 6 +++--- toolsandapi/javaapi/index.html | 6 +++--- toolsandapi/latex/index.html | 6 +++--- toolsandapi/socketserver/index.html | 6 +++--- toolsandapi/uppaal/index.html | 6 +++--- toolsandapi/verifyta/index.html | 6 +++--- 83 files changed, 245 insertions(+), 245 deletions(-) diff --git a/404.html b/404.html index d051a86f..77b4954b 100644 --- a/404.html +++ b/404.html @@ -1,2 +1,2 @@ 404 Page not found -

Error

Woops. Looks like this page doesn't exist ¯\_(ツ)_/¯.

Go to homepage

Page not found!

\ No newline at end of file +

Error

Woops. Looks like this page doesn't exist ¯\_(ツ)_/¯.

Go to homepage

Page not found!

\ No newline at end of file diff --git a/categories/index.html b/categories/index.html index 62991ab9..aede0597 100644 --- a/categories/index.html +++ b/categories/index.html @@ -1,7 +1,7 @@ Categories :: UPPAAL Documentation -

category :: -Categories

    \ No newline at end of file +Categories
    \ No newline at end of file diff --git a/extensions/cora/index.html b/extensions/cora/index.html index 73d16d2f..b5a78405 100644 --- a/extensions/cora/index.html +++ b/extensions/cora/index.html @@ -1,10 +1,10 @@ CORA :: UPPAAL Documentation -

    CORA

    Language Guide

    UPPAAL CORA is based on the newest internal development version of UPPAAL. On one hand this means that it contains all the new and exciting features of the next version of UPPAAL, but on the other it also means that it contains many new and untried features, that might change before the final release of UPPAAL. This page describes the new language features compared to the UPPAAL 4.0 series.

    Cost Annotation

    In LPTA, an implicit continuous monotonic variable called cost is defined. The rate at which this variable grows can be specified in the location invariant as:

    cost’ == INTEXPR

    where INTEXPR is an integer expression. If specified in multible locations, the actual cost rate is the sum of the cost rate specified in the current location of each process. The cost can be incremented on edges using the increment operator +=.

    Here is an example of the aircraft landing problem: xta, q.

    Remaining Cost Estimation

    The performance of UPPAAL CORA can be improved dramatically by annotating the model with an admissible estimate of the remaining cost to reach the goal condition. Admissible means that the estimate is not bigger than the actual cost of reaching the goal, i.e., the estimate provides a lower bound on the remaining cost. The estimate is specified by declaring a meta integer variable named remaining. Specifying a good value for remaining is crucial for good performance.

    In previous versions of UPPAAL, remaining had to be a lower bound on the remaining cost from the state and all its delay successors, but this is no longer required. Now remaining must simply be a lower bound on the remaining cost. When computing a successor, UPPAAL automatically adjusts the value of remaining. Thus even when you do not recompute remaining, it will still be a lower bound of the remaining cost. You will probably be able to come up with a better lower bound on the remaining cost, so you should try compute a remaining cost yourself on each edge transition.

    Command Line Options

    Below we describe the new options supported by the command line interface of UPPAAL (verifyta). Most of these options are also available from the options menu in the graphical frontend.

    Guiding

    A number of different search orders are supported. These can be selected with the -o option:

    • -o0 Breadth first.
    • -o1 Depth first.
    • -o2 Random depth first.
    • -o3 Smallest heur first.
    • -o4 Best first.
    • -o5 Best depth first.

    The first two are well known from previous releases of UPPAAL. Random depth first search is similar to depth first search, but it randomises the order in which the successors of a state are searched. Smallest heur first requires the presence of an integer variable named heur in the model. The state with the smallest value of this variable is always explored next. In most cases, this variable should be a meta variable. Best first and best depth first are used for optimal reachability, see the next topic.

    Optimal Reachability

    UPPAAL CORA has support for finding optimal schedules. Optimality is defined in terms of a cost variable, see the Language Guide for details. The optimal trace can be found by using the -t3 option. With this option, UPPAAL CORA keeps searching until a trace to a goal state with the smallest value for the cost variable has been found. Alternatively you can use the -E option to find the optimal cost without generating the trace.

    UPPAAL CORA automatically enables the -o4 option (best first) when using the -t3 option. This can be changed by manually using a different -o option after the -t3 option. In the best first search order, the state with the smallest value of the cost variable is searched next. An alternative is to use best depth first. This search order performs a depth first search, but always searches the state with the lowest cost first. If a remaining cost estimate annotation is provided, the interpretation of the best first and best depth first is changed to search the state with the smallest sum of the cost variable and the remaining variable next.

    Examples

    The jugs example has been updated to the new syntax. You can download it here: jugs2.ta, jugs2.q. You can find the optimal solution like this:

    verifyta -E jugs2.ta jugs2.q

    Limitations

    UPPAAL CORA has a number of limitations. These limitations are not fundamental, but are a result of using new internal data structures with a currently limited feature set. Over time, these limitations will be resolved.

    • No extrapolation, hence termination is not guaranteed unless you guarantee that either:
      • The system is acyclic.
      • All clocks are bound by invariants.
    • Simple reachability only:
      • No liveness check
      • No deadlock check
    • Limited use of guiding:
      • Support for (cost + remaining) sorting is implemented (best first search)
      • Support for heuristic variable is implemented, but the expression cannot refer to the cost variable.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/extensions/ecdar/index.html b/extensions/ecdar/index.html index 3d82d04e..fd6e8751 100644 --- a/extensions/ecdar/index.html +++ b/extensions/ecdar/index.html @@ -1,7 +1,7 @@ ECDAR :: UPPAAL Documentation -

    Known Issues

    \ No newline at end of file +
    \ No newline at end of file diff --git a/extensions/index.html b/extensions/index.html index af2159f2..ec13d6ed 100644 --- a/extensions/index.html +++ b/extensions/index.html @@ -1,8 +1,8 @@ Extensions :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/extensions/tiga/index.html b/extensions/tiga/index.html index 188a7b7d..12f0fd45 100644 --- a/extensions/tiga/index.html +++ b/extensions/tiga/index.html @@ -1,10 +1,10 @@ UPPAAL Tiga :: UPPAAL Documentation -

    UPPAAL Tiga

    Manual

    The manual (updated 9/8/07) is available separately from the distribution. You can access it from here.

    Known Issues

    • Extrapolation option -n 4. This option should not be used, it would give wrong results.
    • It is possible to get the GUI choose randomly wrong points w.r.t. the strategy occasionally.
    • The generated C-code makes sense only for models with winning non-cooperative strategies.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/extensions/tron/index.html b/extensions/tron/index.html index c2feeee1..deb2d89f 100644 --- a/extensions/tron/index.html +++ b/extensions/tron/index.html @@ -1,7 +1,7 @@ UPPAAL TRON :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/gantt-chart/index.html b/gui-reference/concrete-simulator/gantt-chart/index.html index 356d6fd2..726fe05d 100644 --- a/gui-reference/concrete-simulator/gantt-chart/index.html +++ b/gui-reference/concrete-simulator/gantt-chart/index.html @@ -1,10 +1,10 @@ Gantt Chart Panel :: UPPAAL Documentation -

    Gantt Chart Panel

    The Gantt Chart panel is the middle rightmost panel of the simulator. It displays another view of the generated trace according to the Gantt Chart specification given in system definition.

    In the Gantt Chart view, the horizontal axis represents the time span, and in the vertical axis the list of activities (usually some of the system processes) defined in the Gantt chart specification are listed. A vertical line is used to represent the current time (which corresponds to the one displayed in the Simulation Trace-combo box). Horizontal bars of varying lengths and colors represent when the different expressions in the Gantt chart specification are satisfied according to the current state of the trace.

    If the mouse is placed over a Gantt bar, information about the intervals when the corresponding expressions are satisfied are shown.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/index.html b/gui-reference/concrete-simulator/index.html index 82e9a51b..62cda59f 100644 --- a/gui-reference/concrete-simulator/index.html +++ b/gui-reference/concrete-simulator/index.html @@ -1,10 +1,10 @@ Concrete Simulator :: UPPAAL Documentation -

    Concrete Simulator

    The concrete simulator is similar to the symbolic simulation in the sense that it is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. The difference is that the simulation is based on concrete traces, i.e. one can choose a specific time to fire a transition. The tool helps to see at which time a transition can be fired.

    The concrete simulator consists of the following panels:

    Concrete Simulator

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/process/index.html b/gui-reference/concrete-simulator/process/index.html index a13858f4..670022bc 100644 --- a/gui-reference/concrete-simulator/process/index.html +++ b/gui-reference/concrete-simulator/process/index.html @@ -1,10 +1,10 @@ Process Panel :: UPPAAL Documentation -

    Process Panel

    The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.

    Clicking inside a process box with the right mouse button opens a pop-up menu with the following items:

    • Zoom In: increases the zoom of the process,
    • Zoom Out: decreases the zoom of the process,
    • Hide: hides the process,
    • Export: opens a file dialog for saving the process in encapsulated postscript format.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/sequence-chart/index.html b/gui-reference/concrete-simulator/sequence-chart/index.html index 32b6fc06..ab9949c0 100644 --- a/gui-reference/concrete-simulator/sequence-chart/index.html +++ b/gui-reference/concrete-simulator/sequence-chart/index.html @@ -1,10 +1,10 @@ Message Sequence Chart :: UPPAAL Documentation -

    Message Sequence Chart

    The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).

    In the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/simulation-control/index.html b/gui-reference/concrete-simulator/simulation-control/index.html index 5a9d17b4..1456bc24 100644 --- a/gui-reference/concrete-simulator/simulation-control/index.html +++ b/gui-reference/concrete-simulator/simulation-control/index.html @@ -1,10 +1,10 @@ Simulation Control :: UPPAAL Documentation -

    Simulation Control

    The simulation control is the left panel of the simulator. It is used to control the simulation and to select the state or transition to be visualized in the others panels of the simulator. The control panel is divided in two parts:

    The upper part is used for performing step-by-step simulation. The Transition chooser area is a clickable area where vertical axis displays the active transitions at this location and horizontal axis displays the time at which the transition will be fired. The time interval where a transition is enabled and the time interval where a transition is selectable are colored in different way. The time interval in which a transition can be fired (where the transition is selectable) is delimited by markers: one small circle at the beginning and one at the end of the interval (full if it is close, empty if it is open). When the mouse move to a selectable area, the color of the interval become brighter. By clicking one can select a specific transition and a specific time for firing the transition. The selected transition will be highlighted. The time selected is displayed in the Delay-combo box. One can also specified directly the time in the Delay-combo, once the transition has been selected. If one click in a non-selectable zone of a transition, the tool chooses the closest valid time. The Reset Delay-button is used to reset the delay to zero. Pressing the Take transition-button causes the simulated system to fire the selected transition at the specified time. The Reset-button is used to reset the simulated system to its initial state.

    The lower part of the control panel, the Simulation Trace area, has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.

    The Simulation Trace area contains a combo box that displays the current time (according to the hightlighted state in the trace) and the following buttons:

    • First: highlights the first element in the trace.
    • Last: highlights the last element in the trace.
    • Prev: highlights the element immediately preceding the current selection (if any) in the trace.
    • Next: highlights the element immediately following the current selection (if any) in the trace.
    • Play: replays the trace starting from the currently selected element.
    • Open: opens a file dialog for loading a trace from file.
    • Save: opens a file dialog for saving the current trace on file. The valid file extension is “uctr”. When no file extension is provided, it will be automatically appended.
    • Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions at random time.

    The slider is used to control the speed used when traces are replayed and when random simulation is performed.

    Keyboard Shortcuts

    KeyShortcut to
    QCorrespond to the button Prev.
    ACorrespond to the button Next.
    PCorrespond to the button Replay.
    RCorrespond to the button Random.
    FCorrespond to the button First.
    LCorrespond to the button Last.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/concrete-simulator/variables/index.html b/gui-reference/concrete-simulator/variables/index.html index ebbde85a..95ba16eb 100644 --- a/gui-reference/concrete-simulator/variables/index.html +++ b/gui-reference/concrete-simulator/variables/index.html @@ -1,10 +1,10 @@ Variables Panel :: UPPAAL Documentation -

    Variables Panel

    The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/index.html b/gui-reference/index.html index 39784be9..fc1a77f2 100644 --- a/gui-reference/index.html +++ b/gui-reference/index.html @@ -1,8 +1,8 @@ GUI Reference :: UPPAAL Documentation -

    Chapter 1

    GUI Reference

    Discover the UPPAAL gui.

    UPPAAL GUI

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/edit/index.html b/gui-reference/menu-bar/edit/index.html index 437fd5e1..7139a67d 100644 --- a/gui-reference/menu-bar/edit/index.html +++ b/gui-reference/menu-bar/edit/index.html @@ -1,10 +1,10 @@ Edit Menu :: UPPAAL Documentation -

    Edit Menu

    The Edit menu offers a set of commands supported in the system editor. The items are:

    • Undo: reverses the most recent editing action. This function is only available in the editor.
    • Redo: re-applies the editing action that has most recently been reversed by the Undo action. This function is only available in the editor.
    • Cut: removes the selected text and places it in the clipboard. There must be an active text selection.
    • Copy: places a copy of the selected text in the clipboard. There must be an active text selection.
    • Paste: places text in the clipboard at the cursor location in the currently active editor. There must be text in the clipboard, and an editor must be active.
    • Delete: delete selected text. There must be an active text selection.
    • Insert Template: adds a new empty template to the system description.
    • Remove Template: removes the currently selected template from the system description. There must be a template selected.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/file/index.html b/gui-reference/menu-bar/file/index.html index a87f47c8..fe7b7a06 100644 --- a/gui-reference/menu-bar/file/index.html +++ b/gui-reference/menu-bar/file/index.html @@ -1,10 +1,10 @@ File Menu :: UPPAAL Documentation -

    File Menu

    The leftmost menu of the menu bar is the file menu. It is mainly used to open and save (part of) system descriptions or requirement specifications created in UPPAAL. The available items are:

    • New System: re-initiates the editor with an empty system.
    • Open System: loads an existing system from file. The corresponding requirement specification (i.e. same file name but with the suffix .q) is loaded into the verifier, if it exists.
    • Save System: saves the system in the editor to file.
    • Save System As: saves the system in the editor to a specified file.
    • Import Template: imports template(s) from an existing system description. A dialog window is shown which allows a subset of the available templates to be imported.
    • Export Template: exports the currently edited template in Encapsulated Postscript format to file.
    • New Queries: re-initiates the requirement specification editor with an empty file.
    • Open Queries: loads an existing set of requirement specifications from file.
    • Save Queries: saves the requirement specifications in the editor to file.
    • Save Queries As: saves the requirement specifications in the editor to a specified file name.
    • Exit: exits UPPAAL.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/help/index.html b/gui-reference/menu-bar/help/index.html index edc22502..c1f59971 100644 --- a/gui-reference/menu-bar/help/index.html +++ b/gui-reference/menu-bar/help/index.html @@ -1,10 +1,10 @@ Help Menu :: UPPAAL Documentation -

    Help Menu

    The help menu has two items: Help which opens a separate window showing the help pages, and About which opens a window showing the version number and information about the copyrights of UPPAAL.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/index.html b/gui-reference/menu-bar/index.html index 3f282373..22b47d45 100644 --- a/gui-reference/menu-bar/index.html +++ b/gui-reference/menu-bar/index.html @@ -1,10 +1,10 @@ Menu Bar :: UPPAAL Documentation -

    Menu Bar

    The menu bar is located in the upper part of the main window or at the top of the screen. It contains the following menu items:

    UPPAAL menu bar

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/options/index.html b/gui-reference/menu-bar/options/index.html index fbef27cf..2ba05f75 100644 --- a/gui-reference/menu-bar/options/index.html +++ b/gui-reference/menu-bar/options/index.html @@ -1,10 +1,10 @@ Options Menu :: UPPAAL Documentation -

    Options Menu

    The options menu contains settings to control the behavior of the model-checker.

    Search Order

    This option influences the order in which the state space is explored.

    Breadth first
    Search the state space in breadth first search order. This is typically the most efficient option when the complete state space must be searched. When generating shortest or fastest traces, this is likely the best setting.
    Depth first
    Search the state space in depth first search order. If a counter example or witnessing trace is expected to exist, this setting is usually better than the breadth first setting. It is not recommended to use this search order when generating shortest or fastest traces.
    Random depth first
    Search the state space in randomised depth first search order. If a counter example or witnessing trace is expected to exist, this is usually the best setting. Due to the randomisation, traces may vary from run to run. It is not recommended to use this search order when generating shortest or fastest traces.

    State Space Reduction

    When searching the state space, UPPAAL does not necessarily have to store all states in memory in order to guarantee termination. This option influences how aggressively UPPAAL tries to avoid storing states. There is normally a tradeoff between space and speed.

    None
    Store all states.
    Conservative
    Avoid storing committed states.
    Aggressive
    Avoid storing more than one state per cycle.

    State Space Representation

    This option determines how the state space should be represented in the model checker.

    Some representations are approximative in the sence that either a larger or smaller state space than the real one is generated. When an approximative representation is used, UPPAAL may conclude that a query is maybe satisfied, i.e., UPPAAL cannot make a decisive conclusions given the representation selected.

    Difference Bound Matrices (DBM)
    DBMs are often fast, but for models with many clocks they require a lot of memory.
    Compact Data Structure
    A more compact, but slower representation than DBMs. In particular for models with many clocks, this setting will often significantly reduce memory consumption. Even for models with no or few clocks, this option enables other memory saving techniques at the expense of speed.
    Under Approximation
    Uses bit-state hashing to represent the state space. This results in an under approximation, however the degree of approximation can be adjusted by adjusting the size of the hash table: Large hash tables result in a larger part of the state space being searched. The hash table size can be selected with the hash table size option.
    Over Approximation
    Uses convex-hull approximation of zones. This results in an over approximation of the state space. For models without clocks, this setting has no effect.

    Note that if a model contains stopwatches (invariant expressions like x'==0 where x is a clock), then the resulting analysis is overapproximate even if DBM or Compact Data Structure options are selected (DBM cannot represent additional constraints required by stopwatches). In such case, UPPAAL may also report that a reachability propery is maybe satisfied, meaning that the found counter-example trace may be spurious (i.e. not realizable).

    Diagnostic Trace

    This option controls if a counter-example or witnessing trace (if there is one) should be generated during verification. The trace is loaded into the simulator after verification. Enabling trace generation has two side effects:

    • Only one property at a time can be verified.
    • Symmetry reduction is disabled.

    The possible settings for trace generation are:

    None
    Do not generated any diagnostic trace.
    Some
    Generate a diagnostic trace.
    Shortest
    Generate a shortest trace, i.e. a trace with the smallest number of transitions.
    Fastest
    Generate a fastest trace, i.e. a trace with the shortest accumulated time delay.

    Extrapolation

    The range of clocks is unbounded, i.e., clocks can obtain arbitrarily large real values. To guarantee termination, UPPAAL uses an abstraction techniques called extrapolation. The extrapolated state space is finite. UPPAAL implements a number of extrapolation techniques that differ in the size of the extrapolated state space. Not all extrapolation techniques preserve all properties for all kinds of models. UPPAAL automatically selects the coarsets extrapolation, which still preserves the property being analysed.

    Sometimes it may be of benefit to use a coarser (and faster) extrapolation that the one selected by UPPAAL. By doing so, the analysis will use an over-approximation of the state space. Listed from finest to coarsets, the choices are: None, Difference, Local, and Lower/Upper.

    Automatic
    Selects the coarsest extrapolation preserving the property being analysed. If in doubt, use this setting.
    None
    Do not use extrapolation. Termination is no longer guaranteed. Since performing the extrapolation is relatively expensive, this may be of use if you know that the symbolic state space is finite.
    Difference
    Used whenever the model or the query contain difference constraints over clocks, e.g., x - y < 3.
    Local
    Used whenever the query contains either the deadlock keyword or involves a liveness property (except if the model or the query contain difference constraints).
    Lower/Upper
    Used whenever a reachability analysis is performed, except when the deadlock keyword is used or when the model or the query contain difference constraints.

    Hash table size

    Adjusts the amount of memory used to represent the state space when using bit-state hashing. This option has no effect unless under approximation is selected.

    Reuse

    When selected, instructs the verifier to (whenever possible) reuse the generated portion of the state space when several properties of the same system are checked.

    Statistical Parameters

    Lower probabilistic deviation (-δ)
    Used in hypothesis testing (qualitative model-checking) to specify the lower bound of indifference region from the specified probability.
    Upper probabilistic deviation (+δ)
    Used in hypothesis testing (qualitative model-checking) to specify the upper bound of indifference region from the specified probability.
    Probability of false positives (α)
    Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) <= 0.5) and probability estimation (quantitative model-checking queries like Pr[...](...)) to specify the level of significance (probability of Type I error).
    Probability of false negatives (β)
    Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) <= 0.5) to specify the level of significance (probability of Type II error).
    Probability uncertainty (ε)
    Used in probability estimation (qualitative model-checking) to constrain the size of the confidence interval in a form of p ± ε (1-α CI).
    Ratio lower bound (u0)
    Used in comparison of two probabilities.
    Ratio upper bound (u1)
    Used in comparison of two probabilities.
    Histogram bucket width
    Specifies the width of each column in the histogram. By default it is set to zero meaning that the width is determined by ratio of entire histogram width divided by a bucket count.
    Histogram bucket count
    Specifies the number of columns in the histogram. By default it is set to zero meaning that the count is determined by taking a square root of a total number of samples and dividing by four.

    More Information

    The compact data structure and the options for state space reduction are described in the following paper:

    Efficient Verification of Real-Time Systems: Compact Data Structure and State Space Reduction, Kim G. Larsen, Fredrik Larsson, Paul Pettersson and Wang Yi. In Proceedings of the 18th IEEE Real-Time Systems Symposium, pages 14-24. San Francisco, California, USA, 3-5 December 1997.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/tools/index.html b/gui-reference/menu-bar/tools/index.html index 84890ea8..716fa6ac 100644 --- a/gui-reference/menu-bar/tools/index.html +++ b/gui-reference/menu-bar/tools/index.html @@ -1,10 +1,10 @@ Tools Menu :: UPPAAL Documentation -

    Tools Menu

    The tools menu contains a set of tools useful in the system edtior. The items are:

    • Check Syntax: checks if syntax and types are correct in the edited system. Any found errors and warnings are listed in the lower part of the drawing area of the system editor, and (when applicable) underlinded in the automata.
    • Convert Syntax: assists in convering a system complying with the syntax used in UPPAAL 3.4 to the current syntax.
    • Align to Grid: makes all existing objects of the current template align to the specified drawing grid.
    • Plot Composer: creates a new Plot Composer window to superimpose multiple results from statistical model checking in the Verifier.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/menu-bar/view/index.html b/gui-reference/menu-bar/view/index.html index f4fdc3a2..db18ab53 100644 --- a/gui-reference/menu-bar/view/index.html +++ b/gui-reference/menu-bar/view/index.html @@ -1,10 +1,10 @@ View Menu :: UPPAAL Documentation -

    View Menu

    The view menu is used to modify the appearance of the system currently shown in the system editor and the simulator. The items are:

    • Zoom: shows a sub menu with fixed zoom values, zoom to fit, and itemes for zooming in, out, or to normal size. A change in the zoom value affects the templates the editor or the processes in the simulator (if one of the tools is active).

    • Labels: shows a sub menu from which one can select which type of labels should be shown in the drawing area. Even when hidden, all labels can be seen in the tooltip of locations and edges.

    • Show Grid: the drawing grid is shown when this item is checked.

    • Snap to Grid: makes new drawing objects (such as locations, nails, and labels) align to the snap grid. The size of the snap grid is related to the size of the drawing grid.

      Note: the Snap to Grid option can be used even if the drawing grid is not shown.

    • Coarser: increases the distance between the lines in the drawing grid.

    • Tighter: decreases the distance between the lines in the drawing grid.

    • Mark Visited highlights the locations and edges traversed by a trace in the simulator process panel.

    • Show Coverage shows graphs of location and edge coverage dynamics over the simulated trace in a popup window. The Mark Visited option above enables this menu item.

    • Reload Simulator: uploads the system currently loaded in the editor, to the simulator and the verifier.

    • Processes: displays a dialog window for hiding and showing processes in the process panel of the simulator.

    • Variables: shows a dialog window for hiding and showing variables in the variables panel of the simulator.

    • Full DBM: shows all constraints on the clocks in the variables panel of the simulator. If not selected a minimal number of constraints will be shown.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/index.html b/gui-reference/symbolic-simulator/index.html index 6bf0d4c9..7d4c452d 100644 --- a/gui-reference/symbolic-simulator/index.html +++ b/gui-reference/symbolic-simulator/index.html @@ -1,10 +1,10 @@ Symbolic Simulator :: UPPAAL Documentation -

    Symbolic Simulator

    The simulator is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. In this sense, it provides an inexpensive mean of fault detection prior to verification by the model-checker. The simulator is also used to visualise executions (i.e. symbolic traces) generated by the verifier. Please see the Symbolic Traces section for a brief introduction of the concept.

    The simulator consist of four panels: the leftmost called simulation control, the middle called variables, the upper right called processes, and the lower right called message sequence chart.

    Symbolic Simulator

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/process/index.html b/gui-reference/symbolic-simulator/process/index.html index aedd7b2c..b59a552d 100644 --- a/gui-reference/symbolic-simulator/process/index.html +++ b/gui-reference/symbolic-simulator/process/index.html @@ -1,10 +1,10 @@ Process Panel :: UPPAAL Documentation -

    Process Panel

    The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.

    Clicking inside a process box with the right mouse button opens a pop-up menu with the following items:

    • Zoom In: increases the zoom of the process,
    • Zoom Out: decreases the zoom of the process,
    • Hide: hides the process,
    • Export: opens a file dialog for saving the process in encapsulated postscript format.

    Note: several items in the View menu affect the processes in the process panel. For example, the “Processes…” item may be used to hide and show processes.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/sequence-charts/index.html b/gui-reference/symbolic-simulator/sequence-charts/index.html index b620c3d1..8fc7e771 100644 --- a/gui-reference/symbolic-simulator/sequence-charts/index.html +++ b/gui-reference/symbolic-simulator/sequence-charts/index.html @@ -1,10 +1,10 @@ Message Sequence Chart :: UPPAAL Documentation -

    Message Sequence Chart

    The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).

    In the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.

    Message Sequence Chart

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/simulation-control/index.html b/gui-reference/symbolic-simulator/simulation-control/index.html index 093be2f9..0ddce8f0 100644 --- a/gui-reference/symbolic-simulator/simulation-control/index.html +++ b/gui-reference/symbolic-simulator/simulation-control/index.html @@ -1,10 +1,10 @@ Simulation Control :: UPPAAL Documentation -

    Simulation Control

    The simulation control is the left panel of the simulator. It is used to control the simulation and to select the (symbolic) state or transition to be visualized in the other two panels of the simulator. The control panel is divided in two parts:

    The upper part is used for performing step-by-step simulation. A list view displays the enabled transitions, with the currently selected transition highlighted. Pressing the Next-button causes the simulated system to take the selected transition. The Reset-button is used to reset the simulated system to its initial state.

    The lower part of the control panel has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.

    The six buttons below the trace view have the following semantics:

    • Prev: highlights the element immediately preceding the current selection (if any) in the trace.
    • Next: highlights the element immediately following the current selection (if any) in the trace.
    • Replay: replays the trace starting from the currently selected element.
    • Open: opens a file dialog for loading a trace from file.
    • Save: opens a file dialog for saving the current trace on file. The valid file extension is “xtr”. When no file extension is provided, it will be automatically appended.
    • Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions.

    The slider at the bottom of the control panel is used to control the speed used when traces are replayed and when random simulation is performed.

    Keyboard Shortcuts

    KeyShortcut to
    ZMove selection up in the enabled transitions list view.
    XMove selection down in the enabled transitions list view.
    QCorrespond to the button Prev.
    ACorrespond to the button Next.
    PCorrespond to the button Replay.
    RCorrespond to the button Random.
    FHighlights the first element in the trace.
    LHighlights the last element in the trace.
    Toggle selection of an enabled transition.
    Follow the selected enabled transition.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/symbolic-traces/index.html b/gui-reference/symbolic-simulator/symbolic-traces/index.html index 2b5e4cba..45112f67 100644 --- a/gui-reference/symbolic-simulator/symbolic-traces/index.html +++ b/gui-reference/symbolic-simulator/symbolic-traces/index.html @@ -1,10 +1,10 @@ Symbolic Traces :: UPPAAL Documentation -

    Symbolic Traces

    Since clocks range over the non-negative reals, timed automata can have infinitely many states (not to be confused with locations) and infinitely many traces. The simulator cannot visualize all these concrete traces. Instead it shows an infinite set of traces - a so called symbolic trace. Each symbolic state of a symbolic trace is a set of states and their delay successors described by a number of constraints on the clocks. In a given symbolic state, the active locations and the values of discrete variables are the same for all states.

    Symbolic traces shown in the simulator are backward stable, but not forward stable:

    **Forward stable**
    Given two symbolic states A and B on a symbolic trace such that A is before B, every state in A can reach a state in B.
    **Backward stable**
    Given two symbolic states A and B on a symbolic trace such that A is before B, every state in B can be reached by a state in A.

    In particular, care must be taken when interpreting a counter example produced by the model checker: Not every state in the symbolic states along a symbolic trace will necessarily lead to an error state, although all states in the last symbolic state are indeed reachable from the initial state.

    Note: verifyta can be used to produce forward stable traces.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/symbolic-simulator/variables/index.html b/gui-reference/symbolic-simulator/variables/index.html index 6d129529..dda98615 100644 --- a/gui-reference/symbolic-simulator/variables/index.html +++ b/gui-reference/symbolic-simulator/variables/index.html @@ -1,10 +1,10 @@ Variables Panel :: UPPAAL Documentation -

    Variables Panel

    The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.

    The data variable values are always shown as integers. The clock values are shown symbolically as a conjunction of clock guards of lower and upper bounds on individual clocks or differences between pairs of clocks (see Expressions section for more information on clock guards). The possible clock values of the associated state (or transition) are all possible solutions to the conjunction of all clock constraints. The symbols “[” and “]” are used for closed intervals and “(” and “)” for open intervals in the usual way.

    If the selected element in the simulation control panel is a state, the variables panel shows the symbolic values of the state (in normal black color). If the selected element is a transition, the shown symbolic values are those of the immediately preceding state satisfying the guard(s) of the transition (shown in blue color).

    Note: variables can be hidden and displayed using the “Variables…” item in the View menu. The representation of the clock constraints can also be changed from this menu, using the “Full DBM” item. When “Full DBM” is checked a constraint is shown for each pair of clocks, otherwise a minimum set of constraints is shown. The minimum set of constraints is such that all constraints that are in the full DBM but not in the minimum set can be derived from constraints in the minimum set.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/system-editor/declarations/index.html b/gui-reference/system-editor/declarations/index.html index c097c5f6..59acd556 100644 --- a/gui-reference/system-editor/declarations/index.html +++ b/gui-reference/system-editor/declarations/index.html @@ -1,10 +1,10 @@ Declarations :: UPPAAL Documentation -

    Declarations

    Types, constants, variables and functions can be defined in the global scope by placing them in the global section labelled Declarations or System declarations, or locally for a template by placing in the Declarations section of a template.

    Processes are instantiated by placing a process assignments in the System declarations section.

    Finally, the system is defined as a parallel composition of a number of processes by placing a system declaration in the System declarations section.

    The syntax for each of these sections is defined in the Language Reference.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/system-editor/drawing/index.html b/gui-reference/system-editor/drawing/index.html index 36ae8afc..6ec682ea 100644 --- a/gui-reference/system-editor/drawing/index.html +++ b/gui-reference/system-editor/drawing/index.html @@ -1,10 +1,10 @@ Drawing :: UPPAAL Documentation -

    Drawing

    The rightmost panel of the system editor is used for drawing automata. There are currently four drawing tools named Select, Location, Edge, and Nail represented by the buttons in the tool bar.

    • Select tool: The select tool is used to select, move, modify and delete elements. Elements can be selected by clicking on them or by dragging a rubber band arround one or more elements. Elements can be added or removed from a selection by holding down the control key while clicking on the element. The current selection can be moved by dragging them with the mouse. Double clicking an element brings up the editor for that element. Right clicking an element brings up a pop-up menu from which properties of the element can be changed. It is possible to change the source and target of an edge by moving the mouse to the beginning or end of an edge until a small circle appears. Drag this circle to a new location in order to change the source or target of the edge.
    • Location tool: The location tool is used to add new locations. Simply click with the left mouse button in order to add a new location.
    • Branch tool: The branch tool is used to create probabilistic branches. Simply click with the left mouse button in order to add a new branch point, then choose edge tool to create connecting edges.
    • Edge tool: The edge tool is used to add new edges between locations. Start the edge by clicking on the source location, then click in order to place nails and finally click the target location. The operation can be cancelled by pressing the right mouse button.
    • Nail tool: The nail tool is used to add new nails to an edge. Simply click and drag anywhere on an edge to add and place a new nail.

    For users with a three button mouse, the middle mouse button can be used to create new elements. The editor automatically chooses the correct tool: Clicking on an empty spot creates a new location, clicking on a location creates a new edge and clicking on an edge creates a new nail. With this feature it is possible to use the functionallity of all four tools without having to select the tools directly.

    Colors

    The display color of individual locations and edges can be changed from the pop-up menu for these elements. UPPAAL does not assign any semantic meaning to the colors of locations and edges.

    Comments

    Comments can be added to locations and edges. Double click the location or edge to bring up the editor for that element. The editor has a Comments tab for adding comments. UPPAAL does not assign any semantic meaning to the comments.

    Comments are shown as document elements on the canvas. These elements can be resized by distributing the content of the comments over multiple lines.

    When shown in the tooltip of an element, comments are interpreted as HTML, i.e. tags like <p> and <b> may be used for formating.

    Tooltips

    A tooltip is shown when hovering the mouse over an automaton element. The tooltip contains useful information such as syntax errors.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/system-editor/index.html b/gui-reference/system-editor/index.html index 91c4c1f1..1af2e972 100644 --- a/gui-reference/system-editor/index.html +++ b/gui-reference/system-editor/index.html @@ -1,10 +1,10 @@ System Editor :: UPPAAL Documentation -

    System Editor

    The system editor is used to create and edit the system to be analysed. A system description is defined by a set of process templates (possibly with local declarations), global declarations, and a system definition.

    In this help section we describe how to use the left panel of the editor, called the navigation tree, how to draw automata with the editor, and where to place declarations. The system description language used in UPPAAL is described in the Language Reference section.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/system-editor/navigation-tree/index.html b/gui-reference/system-editor/navigation-tree/index.html index c2bb9788..099dc4c2 100644 --- a/gui-reference/system-editor/navigation-tree/index.html +++ b/gui-reference/system-editor/navigation-tree/index.html @@ -1,10 +1,10 @@ Navigation Tree :: UPPAAL Documentation -

    Navigation Tree

    The navigation tree is shown in the left panel of the system editor. It is used for accessing the various components of a system description. A node in the tree can be double clicked to view (or hide) the sub tree of the node. The root of the navigation tree is named Project.

    The sub node Declarations is used for declarations of global scope. They can be referred to directly in template declarations.

    Each process template of the system description is represented by a node placed under the root node of the navigation tree. When this node is selected (i.e. clicked) the automaton becomes available for editing in the right panel of the system editor. Each template has a sub node named Declarations that is used for typing in local declarations and documentation comments.

    The remaining sub node of the root, named System declarations is used for further declarations, process assignments, and the system declaration.

    Note: the navigation tree can be opened in a separate window using the “Drag out” button. The window returns to its original position when it is closed.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/toolbar/index.html b/gui-reference/toolbar/index.html index 038ebd30..4fbbc9f7 100644 --- a/gui-reference/toolbar/index.html +++ b/gui-reference/toolbar/index.html @@ -1,9 +1,9 @@ Tool Bar :: UPPAAL Documentation -

    Tool Bar

    The tool bar is normally located just below the menu bar but can be moved (using the mouse) to other positions or even to a separate window. The tool bar is divided into four groups. The three leftmost groups provide quick access to some of the most frequently used menu items. The rightmost group contains editing tools.

    UPPAAL Toolbar

    The first group contains the following buttons: New, Open Project, and Save. These features are described in the File menu section.

    The second group contains the following buttons: Undo and Redo. These features are described in the Edit menu section.

    The third group contains the following buttons: Zoom to Fit, Zoom In, and Zoom Out. This features are described in the View menu section.

    The fourth group contains tools used in the editor for selecting and moving elements of an automaton, and for adding locations, edges and nails. This features are described in the section on Drawing.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/verifier/index.html b/gui-reference/verifier/index.html index 08b79b81..a508b899 100644 --- a/gui-reference/verifier/index.html +++ b/gui-reference/verifier/index.html @@ -1,10 +1,10 @@ Verifier :: UPPAAL Documentation -

    Verifier

    The verifier is to check safety and liveness properties by on-the-fly exploration of the state-space of a system in terms of symbolic states represented by constraints. The verification tool in UPPAAL also provides a requirement specification editor for specifying and documenting the system requirements.

    In this help section we describe how to operate the verification tool, in terms of how to specify and verify requirements. The requirement specification language and the verification options are described in separate sections.

    Symbolic Simulator

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/verifier/specifying/index.html b/gui-reference/verifier/specifying/index.html index 37466e1d..26e151ec 100644 --- a/gui-reference/verifier/specifying/index.html +++ b/gui-reference/verifier/specifying/index.html @@ -1,10 +1,10 @@ Specifying Requirements :: UPPAAL Documentation -

    Specifying Requirements

    An overview of the system requirements (called queries below and in the GUI) is shown in the panel named Overview of the verifier. The toggle button Comments/Queries is used to control if the queries or the comments are to be shown in the overview.

    Queries are selected and de-selected using the mouse alone, or in combination with the Shift or the Control key of the keyboard (use the Shift key to (de-)select a range of entries and the Control key to (de-)select single entries). The first selected requirement and its comment is always shown in the two editor fields named Query and Comment, where they may be edited.

    New entries are added using the button named Insert. A new entry is inserted before the first selected entry, or appended after the last entry if no entry is selected.

    The button named Remove is used for deleting selected entries in the overview. Nothing is deleted if no entries are selected.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/verifier/verifying/index.html b/gui-reference/verifier/verifying/index.html index bbe254a2..7de4c351 100644 --- a/gui-reference/verifier/verifying/index.html +++ b/gui-reference/verifier/verifying/index.html @@ -1,10 +1,10 @@ Verifying Requirements :: UPPAAL Documentation -

    Verifying Requirements

    The queries (i.e. the system requirements) are verified from the verifier interface of UPPAAL. A verification is always performed according to the settings specified in the Options menu of the main menu bar.

    The selected queries are verified when the button named Check is pressed. The verification progress dialog displays the progress of how many queries have been verified, what is the current load of a passed-waiting list, current processor time usage (the time spent for verification is in blue, the time spent by operating system is in red), current usage of host’s random access memory (verification memory is in blue, memory used by other running processes is in gray and operating system cache and buffers are in yellow), swap disk usage (swapped out verification is in blue, other is in grey). Note that resource figures do not include the overhead of UPPAAL GUI and command line utilities (like memtime run on verifyta) are more accurate. Some figures are not available on some OSes (system cache allocation is not documented on Windows API and swap usage per process is not maintained by Linux kernel), therefore they might not show up.

    The verification output is displayed in the Status field at the bottom of the verifier panel. The result is also indicated by the circular markers in the rightmost column of the Overview panel. A grey marker indicates that the truth value of the property is unknown, a green marker that the property is satisfied, and a red marker that the property is not satisfied.

    In case the Over Approximation or the Under Approximation options are selected for State Space Representation, the output of the verifier might be that property is “maybe satisfied”. This happens when the verifier cannot determine the truth value of the property due to the approximations used.

    Statistical Model Checking

    Parameters for statistical model checking can be changed in the Options menu. Various data plots (if available) can be accessed via popup-menu by right-clicking the statistical property. The y-axis always denotes a probability or its density, while x-axis denotes either the variable values limited by the statistical query or a step (transition) count in the model run.

    Probability density distribution
    A histogram created from probability distribution where each bucket is normalized by a bucket width. Useful for comparison of various distributions, potentially with different bucket widths.
    Probability distribution
    A histogram created from a frequency histogram where each bucket is normalized by a total number of runs. Useful for assessing a probability of a property being satisfied at a particular moment in time interval.
    Cumulative probability distribution
    A histogram created by adding up all frequency histogram buckets up to the current bucket and normalized by a total number of runs.
    Confidence Intervals for Probabilities
    The confidence intervals for probabilities are computed using Clopper-Pearson method (also known as "exact") for binomial distribution for a given level of confidence (1-α). The method is conservative in a sense that it guarantees the minimum coverage of the real probability in (1-α) of cases. In the plots, the estimated confidence is valid only for one bucket at a time (the gathered data is reused to compute each individual bucket).
    Confidence Intervals for Mean
    The confidence intervals for mean estimation are computed using quantiles of Student's t-distribution for a given level of confidence of 1-α. Note that t-distribution approaches the commonly used Normal (Gaussian) distribution when the number of samples is high.
    Frequency histogram
    The frequency histogram is created by calculating the number of runs satisfying the property at a particular moment in time interval. Useful for calculating the number of runs.

    Any plot can be customized from a popup menu by right-clicking on the plot.

    Further, the plot labels and titles can be edited and several data sets can be superimposed in one figure by using Plot Composer, accessible from the Tools menu. It is possible to create several composite plots at a time by invoking Plot Composer multiple times.

    An extensive overview and comparison of methods for computing confidence intervals for binomial distribution can be found in the following publications:

    Interval Estimators for a Binomial Proportion: Comparison of Twenty Methods, Ana M. Pires and Conceicao Amado. REVSTAT – Statistical Journal, Vol.6, No.2, June 2008, pages 165-197.

    Interval Estimation for a Binomial Proportion, Lawrence D. Brown, T. Tony Cai and Anirban DasGupta. Statistical Science, 2001, Vol.16, No.2, pages 101-133.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/index.html b/gui-reference/yggdrasil/index.html index 9585ee08..e4656a06 100644 --- a/gui-reference/yggdrasil/index.html +++ b/gui-reference/yggdrasil/index.html @@ -1,10 +1,10 @@ Test Cases (Yggdrasil) :: UPPAAL Documentation -

    Test Cases (Yggdrasil)

    Test Cases (Yggdrasil) tab contains an offline test-case generation tool with a purpose of increasing edge coverage. It generates traces from the model, and translates them into test cases based on test code entered into the model on edges and locations next to comments.

    The main features of the Test Cases generator are:

    • The generated test code is backend agnostic, meaning that it is user-defined and independent of specific test execution engines.
    • Three modes for test case generation:
      • Test purpose mode: Generates a test case specified by a reachability query
      • An auto-depth mode: Generates tests automatically aiming at achieving edge/location coverage
      • Single-step mode: Generates an individual test case per uncoverd edge.
    • Visualization of coverage

    Determinism

    Test generator expects a deadlock free and mostly deterministic model.

    Deadlocks can be checked against in the Verifier tab using A[] not deadlock query.

    There are no checks or reinforcements made for determinism. Non-deterministic implementation requirements (behavior not controlled by a test execution harness) may yield test-cases which cannot be executed in a controlled manner. For example, test execution harness might not be able to force the implementation under test to respond in a specific way assumed by a test case if the implementation is allowed to respond in multiple ways non-deterministically. The environment assumption model (edges controlled by the test execution harness) is encouraged to be non-deterministic to facilitate a more focused and flexible control when selecting test cases.

    Basic operation

    The buttons Add will generate traces based on the verification options selected in the Options menu where the search order and diagnostic trace options are overridden by the corresponding drop-down list selection. Unless intimately familiar with the search algorithms of Uppaal, leave the options at their default settings.

    The traces are added and shown in the Traces list below on the left. Selecting a trace will show the statistics for this trace in the Trace statistics on the right. The Total Coverage button will show the combined statistics of all the traces added so far. Double clicking a trace loads the trace in the Simulator tab, where the execution scenario can be examined in detail. Simulator colors the covered locations and edges in blue when Mark Visited option is selected under the View menu.

    Test cases are exported to a specified directory specified by clicking Save Test Cases button at the bottom. Previously stored test cases are overwritten by new test ones.

    Test Cases Generator tab

    Note: the traces and statistics are lost when the model is reloaded. Traces and statistics are not saved with the model. Only the test cases can be saved.

    Suggested methodology:

    Test Cases can be generated in several ways, depending on the actual project, but it is designed to support the method outlined below:

    1. Test purposes very often represent mandatory critical observations that must be observed on the system under test. First, Add the test cases representing the test purposes. These test are mandated anyway, and will cover some parts of the model, but this coverage is typically insufficient.
    2. Generate tests that improves the (edge/location) coverage of the model (but does not guarantee so). Second, Add the test cases using the auto-depth mode to improve the coverage.
    3. The coverage achieved by the second step can be completed by adding an individual test-case for each of these uncovered edges or locations. Hence, third, Add the test cases using the single-step mode.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/test-code/index.html b/gui-reference/yggdrasil/test-code/index.html index 0272a0d0..a7882212 100644 --- a/gui-reference/yggdrasil/test-code/index.html +++ b/gui-reference/yggdrasil/test-code/index.html @@ -1,7 +1,7 @@ Specifying Test Code :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/traces/index.html b/gui-reference/yggdrasil/traces/index.html index d6daf8d7..38abd074 100644 --- a/gui-reference/yggdrasil/traces/index.html +++ b/gui-reference/yggdrasil/traces/index.html @@ -1,10 +1,10 @@ Generating Traces :: UPPAAL Documentation -

    Generating Traces

    Traces are generated using three purposes: queries, depth search, and individual edges.

    In the Verifier tab the existential queries (E<>) can be used to specify a desired functionality to be tested and hence can be selected as a test purpose for test case generation. All or specific queries can be selected and the resulting trace is added to be used as a test case.

    The second option uses heuristics of random depth first search of the specified number of steps with a hope of increasing the coverage. The resulting trace is used as a test case. The search process is repeated until the newly generated trace does not contribute new coverage over the previous traces. In order to use this method a global integer variable named __reach__ must be declared, initialized to zero and should not be used anywhere in the model. The number of steps depends on the model (size and depth of the model) and application domain (how long test cases are acceptable). If depth is configured too small there is a risk that many edges wil not be covered. If depth is configured very high, needlessly long test cases will be generated.

    The third option attempts to cover the remaining edges which are not covered by the previously generated traces. This method submits a separate reachability query for each uncovered edge. Large models may have many edges, and therefore many queries may take a long time to execute. Even worse: some edges might be unreachable at all and thus require exhaustive search which may consume a lot of time and memory. In order to use this method a global integer variable named __single__ must be declared, initialized to zero and should not be used throughout the model.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/tutorial/basic-test-generation/index.html b/gui-reference/yggdrasil/tutorial/basic-test-generation/index.html index 7f4b77ff..2746ad81 100644 --- a/gui-reference/yggdrasil/tutorial/basic-test-generation/index.html +++ b/gui-reference/yggdrasil/tutorial/basic-test-generation/index.html @@ -1,7 +1,7 @@ Basic Test Generation :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/tutorial/index.html b/gui-reference/yggdrasil/tutorial/index.html index d7029498..1e10fffb 100644 --- a/gui-reference/yggdrasil/tutorial/index.html +++ b/gui-reference/yggdrasil/tutorial/index.html @@ -1,11 +1,11 @@ Tutorial :: UPPAAL Documentation -

    Tutorial

    This tutorial shows how to use the Uppaal Test Generator (Yggdrasil) to generate test scripts step-by-step. It assumes that you are familar with the basic syntax and semantics of Uppaal automata, the basic query language, and is able to use the model-editor.

    At the end of the tutorial you will be able to generate simple executable test cases.

    The features for generating offline test cases are presented terms of two simple example systems: An On/Off system and an Up/Down counter. The behavior of these systems are generic, but could, respectively, represent a lamp with on/off capabilities and a dimmer lamp, which can be turned up or down.

    Both examples include a model, decorated with test-code, a (supposedly) correct implementation of the system, and a implementation mutant representing an implementation mistake. The system and mutant are implemented in Java so they should be platform independent. The generated test cases are output in Java and is, when compiled, executable on these implementations. Execution scripts are included for Windows and Linux.

    The necessary files are provided as part of the Uppaal distribution in the directory demo/testcases/.

    The tutorial proceeds in three steps:

    1. Basic Test Cases Generation. Here you will learn the basic steps involved in annotating the model with test code, and generating simple test cases.
    2. Test cases with model-variables. Here you will learn how to insert the values of model variables into the test code, and how to generate a covering test suite.
    3. Generating testcases using queries (test purposes). Here you will learn to generate test cases based on test purpose queries.

    The concepts of Test Cases generation is explained in the Test Cases section.

    For comments or questions please contact Brian Nielsen bnielsen@cs.aau.dk or Marius Mikucionis marius@cs.aau.dk.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/tutorial/using-queries/index.html b/gui-reference/yggdrasil/tutorial/using-queries/index.html index 2ae4b269..50e813ac 100644 --- a/gui-reference/yggdrasil/tutorial/using-queries/index.html +++ b/gui-reference/yggdrasil/tutorial/using-queries/index.html @@ -1,7 +1,7 @@ Using Queries :: UPPAAL Documentation -

    Using Queries

    This tutorial assumes you have understood using variables.

    The system model

    This tutorial uses the same Up/Down model as in the section using variables. Open the updown/updown.xml file in Uppaal.

    Editing the Queries

    Sometimes it is desirable to generate test cases for specific purposes. This can be done by creating a verification query for the purpose, and use that to generate a test trace.

    In the Verifier tab you can enter queries. The Test Cases generator is able to search for traces satisfying reachability queries (that is queries which start with E<>. The query entered in this tutorial should be E<> System.Max, which asks the verifier to find a trace where the System process is in the location Max.

    Test case queries

    Generating test traces from queries

    To generate test cases go to the Test Cases tab and activate the Query mode, and hit Add.

    Test Case Generation with queries

    This will generate a trace from the query file that leads to the Max location. You can inspect in the trace statistics that that location is infact now covered. By default, a test trace will be generated per query for all queries in the query file. In the drop-down selector you can chosse a specific query to generate and add.

    Resulting test trace

    Further, you can double click the trace and go to the Simulator tab and verify that this trace does indeed lead to the Max location. From the Off location this requires doing up ten successive times. Inspecting the test trace in Simulator

    Generating tests using the combined methodology

    As recommended, start by adding test cases for the test purposes (queries), then optimize coverage by the auto-depth mode, and finally single-step mode. This results in the three sections listed the test traces output panel.

    Coveage followin the methodology

    \ No newline at end of file +
    \ No newline at end of file diff --git a/gui-reference/yggdrasil/tutorial/using-variables/index.html b/gui-reference/yggdrasil/tutorial/using-variables/index.html index 96784511..24074287 100644 --- a/gui-reference/yggdrasil/tutorial/using-variables/index.html +++ b/gui-reference/yggdrasil/tutorial/using-variables/index.html @@ -1,7 +1,7 @@ Using Model Variables :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/index.html b/index.html index 4efae9db..d508108e 100644 --- a/index.html +++ b/index.html @@ -1,4 +1,4 @@ :: UPPAAL Documentation -
    navigation

    UPPAAL Help

    UPPAAL is a tool for modeling, validation and verification of real-time systems. It is appropriate for systems that can be modeled as a collection of non-deterministic processes with finite control structure and real-valued clocks (i.e. timed automata), communicating through channels and (or) shared data structures. Typical application areas include real-time controllers, communication protocols, and other systems in which timing aspects are critical.

    The UPPAAL tool consists of three main parts:

    • a graphical user interface (GUI),
    • a verification server, and
    • a command line tool.

    The GUI is used for modelling, symbolic simulation, concrete simulation, and verification. For both simulation and verification, the GUI uses the verification server. In simulation, the server is used to compute successor states. See also the section on setting up a remote server. The command line tool is a stand-alone verifier, appropriate for e.g. batch verifications.

    More information can be found at the UPPAAL web site: http://www.uppaal.org.

    \ No newline at end of file diff --git a/index.json b/index.json index f426f086..34befb4d 100644 --- a/index.json +++ b/index.json @@ -1 +1 @@ -[{"uri":"/gui-reference/yggdrasil/tutorial/basic-test-generation/","title":"Basic Test Generation","tags":[],"description":"","content":" Create the models Open the On/Off System model \u0026ldquo;onoff/onoff.xml\u0026rdquo; file in Uppaal. The system contains two templates entitled System and User. The System represents the system or device (e.g. lamp) under test. The User models the possible user interactions with the system.\nThe system can be either On or Off, with channels on and off changing between them. The user can non-deterministically press on or off.\nSystem template User template Add Test Cases specific model annotations First, some Test Cases specific declarations muse be made; these are required for the generator to use depth-first reachability and single step techniques for test-case generation. These variables must not be altered in the model. Hence, these two variables must be declared in the global Declarations section:\nint __reach__ = 0; int __single__ = 0; Add test pre-fix and post-fix code Second, there are two blocks of comments in the System declarations section of the model. The contents of a multi-line comment starting with TEST_PREFIX or TEST_POSTFIX are ejected as prefix code (before the actual test case behavior) or postfix code (after actual test case behavior) for each test case.\nIn this example each test case is a Java class with a main method; executing this Java class constitutes running the test case. Therefore the prefix and postfix code is the wrapper code to setup this Java class.\n/** TEST_PREFIX package app; import app.App; class Test extends App { public static void main(String[] args) { */ /** TEST_POSTFIX } } */ The test case class extends the App class we are testing. If you use a specific unit test framework, these lines should be changed to match its requiements. Each step in the test case will execute some methods on this class.\nBy default, test cases will be named and sequentially numbered like testcase0.code. If desired, the filename and file extension can be changed by the following special comments in the System declarations section. For now, stay with the defaults.\n/** TEST_FILENAME test- */ /** TEST_FILEEXT .txt */ Add test step code annotations The system model must be decorated with test code. Double clicking the edge labeled on? and selecting the Test Code tab reveals an area for entering test code. In this model the test code should be set_on();. This will execute the method set_on() on the application whenever this edge is taken in a test case. Similarly, set_off(); is added to the edge labeled off?.\nFor locations, test code can be entered in two areas, Enter and Exit. This test code is added to the test case when the trace reaches the location or leaves it, respectively.\nAdding edge test code Adding location test code Generating the test cases To generate test cases go to the Test Cases tab. You may need to enable the tab in the GUI first.\nEnable Test Cases Tab Test Cases Tab Select which techniques for test case generation to use. For now only select the auto-depth search mode with a depth of 20, and click add.\nClicking add should generate a single trace. Each trace generated will have a line in the list similar to Trace coverage: 4/4. This shows that the trace covered four out of four edges. Further information about which locations and edges are/are not covered are shown in the Statistics panel to the right. Here, all of the 3 locations and 4 edges are trivially covered.\nBy double clicking the trace and selecting the Simulator tab, the trace can be examined. Unsurprisingly, the trace simply runs in circles with alternating on/off presses.\nNext output the test cases to the file by clicking Save Test Cases. Select the output folder for test cases. Make this point to the onoff folder in this tutorial. Inspecting the test case code Pressing the Save Test Cases button in the Test Cases tab will generate a file called testcase0.code in the selected output folder. If several traces have been generated, several files will be generated with sequential numbering.\nEach of these will be a Java class with the sequence of method invocations induce by the generated trace. A snippet is shown below.\n1: package app; 2: import app.App; 3: 4: class Test extends App { 5: 6: public static void main(String[] args) { 7: 8: expect_off(); 9: 10: set_on(); 11: 12: expect_on(); 13: 14: set_off(); 15: \u0026lt;... snip ... \u0026gt; 93: 94: } 95: } The test case starts with the prefix code on lines 1-6. Line 8 is the first step of the trace. This is expect_off(); since the initial location is Off. The first transition is the one labeled on?, the test code for this transition is set_on();. This is entered in the trace at line 10. The trace then enters location On and expect_on(); is in the test case at line 12. The test case continues in this fashion. The trace ends with the postfix code on lines 94-95. Exectuting the test cases Running the test.sh (or test.bat on Windows) will compile and run the test cases one at a time. It will output the name of each file as it executes them. No output from the test case signifies successful execution.\nonoff$ ./test.sh testcase0.code onoff$ Running the testMutant.sh (or testMutant.bat on Windows) will compile and run the test cases on the mutant (intentionally wrong) implementation. This should result in an exception being thrown, signifying a test error.\nonoff$ ./testMutant.sh testcase0.code Exception in thread \"main\" java.lang.AssertionError at app.App.expect_on(App.java:17) at app.Test.main(Test.java:15) onoff$ The implementation code can be examined in the onoff/app folder. See file onoff/app/AppC.java for the correct implementation and onoff/app/AppM.java for the mutant.\nIn order to transfer this to you own applications, you will have to decorate the model with test code such that the output from the generator constitutes an executable test case in whatever test execution framework you use.\n"},{"uri":"/language-reference/system-description/declarations/","title":"Declarations","tags":[],"description":"","content":"Declarations are either global or local (to a template) and can contain declarations of clocks, bounded integers, channels (although local channels are useless), arrays, records, and types. The syntax is described by the grammar for Declarations:\nDeclarations ::= (VariableDecl | TypeDecl | [Function] | [ChanPriority])* VariableDecl ::= [Type] VariableID (\u0026#39;,\u0026#39; VariableID)* \u0026#39;;\u0026#39; VariableID ::= ID [ArrayDecl]* [ \u0026#39;=\u0026#39; Initialiser ] Initialiser ::= [Expression] | \u0026#39;{\u0026#39; Initialiser (\u0026#39;,\u0026#39; Initialiser)* \u0026#39;}\u0026#39; TypeDecls ::= \u0026#39;typedef\u0026#39; Type ID ArrayDecl* (\u0026#39;,\u0026#39; ID ArrayDecl*)* \u0026#39;;\u0026#39; The global declarations may also contain at most one channel priority declaration.\nExamples const int a = 1; constant a with value 1 of type integer. bool b[8], c[4]; two boolean arrays b and c, with 8 and 4 elements respectively. int[0,100] a=5; an integer variable with the range [0, 100] initialised to 5. int a[2][3] = { { 1, 2, 3 }, { 4, 5, 6} }; a multidimensional integer array with default range and an initialiser. clock x, y; two clock variables x and y. chan d; a channel variable. urgent chan e; an urgent channel variable which forces the transition to be taken as soon as it is enabled. struct { int a; bool b; } s1 = { 2, true }; an instantiation of the structure from above where the members a and b are set to 2 and true. meta int swap; int a; int b; Update: swap = a; a = b; b = swap; a meta variable swap is used to swap the contents of two integers a and b. The value of a meta variable is stored outside the state space (hence saves some state memory), but its value is valid only during one transition (e.g. transfering value between synchronizing processes). Currently struct can\u0026rsquo;t contain members of type double or clock.\nType Declarations The typedef keyword is used to name types.\nExample The following declares a record type S containing an integer a and a boolean b members:\ntypedef struct { int a; bool b; } S; "},{"uri":"/gui-reference/menu-bar/file/","title":"File Menu","tags":[],"description":"","content":"The leftmost menu of the menu bar is the file menu. It is mainly used to open and save (part of) system descriptions or requirement specifications created in UPPAAL. The available items are:\nNew System: re-initiates the editor with an empty system. Open System: loads an existing system from file. The corresponding requirement specification (i.e. same file name but with the suffix .q) is loaded into the verifier, if it exists. Save System: saves the system in the editor to file. Save System As: saves the system in the editor to a specified file. Import Template: imports template(s) from an existing system description. A dialog window is shown which allows a subset of the available templates to be imported. Export Template: exports the currently edited template in Encapsulated Postscript format to file. New Queries: re-initiates the requirement specification editor with an empty file. Open Queries: loads an existing set of requirement specifications from file. Save Queries: saves the requirement specifications in the editor to file. Save Queries As: saves the requirement specifications in the editor to a specified file name. Exit: exits UPPAAL. "},{"uri":"/gui-reference/yggdrasil/traces/","title":"Generating Traces","tags":[],"description":"","content":"Traces are generated using three purposes: queries, depth search, and individual edges.\nIn the Verifier tab the existential queries (E\u0026lt;\u0026gt;) can be used to specify a desired functionality to be tested and hence can be selected as a test purpose for test case generation. All or specific queries can be selected and the resulting trace is added to be used as a test case.\nThe second option uses heuristics of random depth first search of the specified number of steps with a hope of increasing the coverage. The resulting trace is used as a test case. The search process is repeated until the newly generated trace does not contribute new coverage over the previous traces. In order to use this method a global integer variable named __reach__ must be declared, initialized to zero and should not be used anywhere in the model. The number of steps depends on the model (size and depth of the model) and application domain (how long test cases are acceptable). If depth is configured too small there is a risk that many edges wil not be covered. If depth is configured very high, needlessly long test cases will be generated.\nThe third option attempts to cover the remaining edges which are not covered by the previously generated traces. This method submits a separate reachability query for each uncovered edge. Large models may have many edges, and therefore many queries may take a long time to execute. Even worse: some edges might be unreachable at all and thus require exhaustive search which may consume a lot of time and memory. In order to use this method a global integer variable named __single__ must be declared, initialized to zero and should not be used throughout the model.\n"},{"uri":"/gui-reference/","title":"GUI Reference","tags":[],"description":"","content":"Chapter 1 GUI Reference Discover the UPPAAL gui.\n"},{"uri":"/language-reference/expressions/identifiers/","title":"Identifiers","tags":[],"description":"","content":"The valid identifier names are described by the following regular expression: [a-zA-Z_]([a-zA-Z0-9_])*\nExamples a, B, c2, d2 valid identifier names. 1, 2a, 3B, 4c5 invalid identifier names. "},{"uri":"/language-reference/system-description/templates/locations/","title":"Locations","tags":[],"description":"","content":"Locations of a timed automaton are graphically represented as circles. If a timed automaton is considered as a directed graph, then locations represent the vertices of this graph. Locations are connected by edges.\nNames Locations can have an optional name. Besides serving as an identifier allowing you to refer to the location from the requirement specification language, named locations are useful when documenting the model. The name must be a valid identifier and location names share the name space with variables, types, templates, etc.\nInvariants Locations are labelled with invariants. Invariants are expressions and thus follow the abstract syntax of expressions. However, the type checker restricts the set of possible expressions allowed in invariants.\nAn invariant must be a conjunction of simple conditions on clocks, differences between clocks, and boolean expressions not involving clocks. The bound must be given by an integer expression. Furthermore lower bounds on clocks are disallowed. It is important to understand that invariants influence the behaviour of the system \u0026ndash; they are distinctly different from specifying safety properties in the requirements specification language. States which violate the invariants are undefined; by definition, such states do not exist. This influences the interpretation of urgent channels and broadcast channels. Please see the section on synchronisations for a detailed discussion of this topic.\nIn addition, stop-watches are supported and they are declared with invariants. Clock rate expressions are specified and they are part of the conjunction in the invariant. Furthermore, the forall construct is accepted in invariants to ease use of arrays.\nStatistical model checker supports any integer expression as a clock rate which allows modeling costs.\nRate of Exponential The rate of exponential is a ratio expression which specifies the rate of exponential probability distribution. The rate expression can be a simple integer expression or two integer expressions separated by a colon like r:q where the rate is determined as ratio r/q.\nThe rate of exponential is used in a statistical model checking. If the location does not have an invariant over time, then it is assumed that the probability of leaving the location is distributed according to the exponential distribution: Pr(leaving after t)=1−e−λt, where e=2.718281828…, t is time and λ is the fixed rate. Probability density of the exponential distribution is λe−λt and thus intuitively λ means the probability density of leaving at time zero, i.e. as soon as some edge is enabled. The smaller the rate is specified, the longer the delay is preferred.\nThe generation of exact delay relies on pseudo random number generator and on 32-bit architectures the longest possible delay is rather limited: ln(231)/λ ≈ 21.49/λ.\nExamples The following are valid invariants. Here x and y are clocks and i is an integer array.\nx \u0026lt;= 2 x is less than or equal to 2. x \u0026lt; y x is (strictly) less than y. forall(i:int[0,2]) x[i] \u0026lt;= 3 The clocks x[0], x[1] and x[2] of the clock array x are less or equal to 3. forall(i:int[0,2]) y[i]' == b[i] The clock rates y[0]', y[1]', and y[2]' are set to, respectively, b[0], b[1] and b[2]. Note that for symbolic queries the only valid values are 0 and 1. Setting the rate to 0 effectively stops a clock (makes it a stop-watch). In statistical model checking the rate is allowed to be any floating point value. hybrid clock can be interpreted as a continuous cost and abstracted away in symbolic queries while maintaining concrete values in statistical queries. Initial locations Each template must have exactly one initial location. The initial location is marked by a double circle.\nUrgent locations Urgent locations freeze time; i.e. time is not allowed to pass when a process is in an urgent location.\nSemantically, urgent locations are equivalent to:\nadding an extra clock, say x, that is reset on every incomming edge, and adding an invariant x \u0026lt;= 0 to the location. Committed locations Like urgent locations, committed locations also freeze time. Furthermore, if any process is in a committed location, the next transition must involve an edge from one of the committed locations.\nCommitted locations are useful for creating atomic sequences and for encoding synchronization between more than two components. Notice that if several processes are in a committed location at the same time, then they will interleave.\n"},{"uri":"/gui-reference/menu-bar/","title":"Menu Bar","tags":[],"description":"","content":"The menu bar is located in the upper part of the main window or at the top of the screen. It contains the following menu items:\nFile Menu Edit Menu View Menu Tools Menu Options Menu Help Menu "},{"uri":"/gui-reference/system-editor/navigation-tree/","title":"Navigation Tree","tags":[],"description":"","content":"The navigation tree is shown in the left panel of the system editor. It is used for accessing the various components of a system description. A node in the tree can be double clicked to view (or hide) the sub tree of the node. The root of the navigation tree is named Project.\nThe sub node Declarations is used for declarations of global scope. They can be referred to directly in template declarations.\nEach process template of the system description is represented by a node placed under the root node of the navigation tree. When this node is selected (i.e. clicked) the automaton becomes available for editing in the right panel of the system editor. Each template has a sub node named Declarations that is used for typing in local declarations and documentation comments.\nThe remaining sub node of the root, named System declarations is used for further declarations, process assignments, and the system declaration.\nNote: the navigation tree can be opened in a separate window using the \u0026ldquo;Drag out\u0026rdquo; button. The window returns to its original position when it is closed.\n"},{"uri":"/language-reference/query-semantics/symb_queries/","title":"Semantics of the Symbolic Queries","tags":[],"description":"","content":"In the following we give a pseudo-formal semantics for the requirement specification language of UPPAAL. We assume the existence of a timed transition system (S, s0, →) as defined in the semantics of UPPAAL timed automata. In the following, p and q are state properties for which we define the following temporal properties:\nSee also Syntax of Symbolic Queries.\nPossibly The property E\u0026lt;\u0026gt; p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → \u0026hellip; → sn, where s0 is the initial state and sn satisfies p.\nInvariantly The property A[] p evaluates to true if (and only if) every reachable state satisfy p.\nAn invariantly property A[] p can be expressed as the possibly property not E\u0026lt;\u0026gt; not p.\nPotentially always The property E[] p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → \u0026hellip; → si → \u0026hellip; for which p holds in all states si and which either:\nis infinite, or ends in a state (Ln, vn) such that either for all d: (Ln, vn+d) satisfies p and Inv(Ln), or there is no outgoing transition from (Ln, vn) Eventually The property A\u0026lt;\u0026gt; p evaluates to true if (and only if) all possible transition sequences eventually reaches a state satisfying p.\nAn eventually property A\u0026lt;\u0026gt; p can be expressed as the potentially property not E[] not p.\nLeads To The syntax p --\u0026gt; q denotes a leads to property meaning that whenever p holds eventually q will hold as well. Since UPPAAL uses timed automata as the input model, this has to be interpreted not only over action transitions but also over delay transitions.\nA leads to property p --\u0026gt; q can be expressed as the property A[] (p imply A\u0026lt;\u0026gt; q).\nState Properties Any side-effect free expression is a valid state property. In addition it is possible to test whether a process is in a particular location and whether a state is a deadlock. State proprerties are evaluated for the initial state and after each transition. This means for example that a property A[] i != 1 might be satisfied even if the value of i becomes 1 momentarily during the evaluation of initializers or update-expressions on edges.\nLocations Expressions on the form P.ℓ, where P is a process and ℓ is a location, evaluate to true in a state (L, v) if and only if P.ℓ is in L.\nDeadlocks The state property deadlock evaluates to true for a state (L, v) if and only if for all d ≥ 0 there is no action successor of (L, v + d).\nProperty Equivalences The UPPAAL requirement specification language supports five types of properties, which can be reduced to two types as illustrated by the following table.\nName Property Equivalent to Possibly E\u0026lt;\u0026gt; p Invariantly A[] p not E\u0026lt;\u0026gt; not p Potentially always E[] p Eventually A\u0026lt;\u0026gt; p not E[] not p Leads to p --\u0026gt; q A[] (p imply A\u0026lt;\u0026gt; q) "},{"uri":"/gui-reference/concrete-simulator/simulation-control/","title":"Simulation Control","tags":[],"description":"","content":"The simulation control is the left panel of the simulator. It is used to control the simulation and to select the state or transition to be visualized in the others panels of the simulator. The control panel is divided in two parts:\nThe upper part is used for performing step-by-step simulation. The Transition chooser area is a clickable area where vertical axis displays the active transitions at this location and horizontal axis displays the time at which the transition will be fired. The time interval where a transition is enabled and the time interval where a transition is selectable are colored in different way. The time interval in which a transition can be fired (where the transition is selectable) is delimited by markers: one small circle at the beginning and one at the end of the interval (full if it is close, empty if it is open). When the mouse move to a selectable area, the color of the interval become brighter. By clicking one can select a specific transition and a specific time for firing the transition. The selected transition will be highlighted. The time selected is displayed in the Delay-combo box. One can also specified directly the time in the Delay-combo, once the transition has been selected. If one click in a non-selectable zone of a transition, the tool chooses the closest valid time. The Reset Delay-button is used to reset the delay to zero. Pressing the Take transition-button causes the simulated system to fire the selected transition at the specified time. The Reset-button is used to reset the simulated system to its initial state.\nThe lower part of the control panel, the Simulation Trace area, has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.\nThe Simulation Trace area contains a combo box that displays the current time (according to the hightlighted state in the trace) and the following buttons:\nFirst: highlights the first element in the trace. Last: highlights the last element in the trace. Prev: highlights the element immediately preceding the current selection (if any) in the trace. Next: highlights the element immediately following the current selection (if any) in the trace. Play: replays the trace starting from the currently selected element. Open: opens a file dialog for loading a trace from file. Save: opens a file dialog for saving the current trace on file. The valid file extension is \u0026ldquo;uctr\u0026rdquo;. When no file extension is provided, it will be automatically appended. Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions at random time. The slider is used to control the speed used when traces are replayed and when random simulation is performed.\nKeyboard Shortcuts Key Shortcut to Q Correspond to the button Prev. A Correspond to the button Next. P Correspond to the button Replay. R Correspond to the button Random. F Correspond to the button First. L Correspond to the button Last. "},{"uri":"/gui-reference/verifier/specifying/","title":"Specifying Requirements","tags":[],"description":"","content":"An overview of the system requirements (called queries below and in the GUI) is shown in the panel named Overview of the verifier. The toggle button Comments/Queries is used to control if the queries or the comments are to be shown in the overview.\nQueries are selected and de-selected using the mouse alone, or in combination with the Shift or the Control key of the keyboard (use the Shift key to (de-)select a range of entries and the Control key to (de-)select single entries). The first selected requirement and its comment is always shown in the two editor fields named Query and Comment, where they may be edited.\nNew entries are added using the button named Insert. A new entry is inserted before the first selected entry, or appended after the last entry if no entry is selected.\nThe button named Remove is used for deleting selected entries in the overview. Nothing is deleted if no entries are selected.\n"},{"uri":"/language-reference/query-syntax/symbolic_queries/","title":"Syntax of Symbolic Queries","tags":[],"description":"","content":"Symbolic Queries Symbolic queries are performed using symbolic operations based on symbolic semantics of timed automata and correspond to a mathematically rigorous proof.\nSymbolicQuery ::= \u0026#39;A[]\u0026#39; Expression Subjection | \u0026#39;E\u0026lt;\u0026gt;\u0026#39; Expression Subjection | \u0026#39;E[]\u0026#39; Expression Subjection | \u0026#39;A\u0026lt;\u0026gt;\u0026#39; Expression Subjection | Expression --\u0026gt; Expression Subjection | \u0026#39;sup\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;sup\u0026#39; \u0026#39;{\u0026#39; Expression \u0026#39;}\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;inf\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;inf\u0026#39; \u0026#39;{\u0026#39; Expression \u0026#39;}\u0026#39; \u0026#39;:\u0026#39; List Subjection List ::= Expression | Expression \u0026#39;,\u0026#39; List Subjection ::= // empty for no subjection | under StrategyName Subjection indicates whether the query should be subjected to a strategy. For sup properties, expression may not contain clock constraints and must evaluate to either an integer or a clock.\nSee rail road diagram for the entire SymbolicQuery syntax.\nSee also: Semantics of the Symbolic Queries\nExamples A[] 1\u0026lt;2 invariantly 1\u0026lt;2. E\u0026lt;\u0026gt; p1.cs and p2.cs true if the system can reach a state where both process p1 and p2 are in their locations cs. A[] p1.cs imply not p2.cs invariantly process p1 in location cs implies that process p2 is not in location cs. A[] not deadlock invariantly the process is not deadlocked. sup: Train(1).x, Train(2).x computes the suprema of Train(1).x and Train(2).x expressions (maximal values in case of integers, upper bounds, strict or not, for clocks). sup{Train(1).Crossing}: Train(1).x computes the supremum of Train(1).x but only when Train(1) is in Crossing. inf{Gate.Occ}: Gate.len similarly to sup, infquery computes infimum of the given expression Gate.len while process Gate is in Occ location. When a clock infimum is needed, the state predicate should be used, otherwise the result is trivially \u0026gt;=0. "},{"uri":"/language-reference/system-description/","title":"System Description","tags":[],"description":"","content":"A system model in UPPAAL consists of a network of processes described as extended timed automata. The description of a model consist of three parts: its global and local declarations, the automata templates, and the system definition.\n"},{"uri":"/language-reference/system-description/system-definition/template-instantiation/","title":"Template Instantiation","tags":[],"description":"","content":"New templates can be defined from existing templates using the grammar for Instantiation. The new template has the same automaton structure and the same local variables as the template it is defined from. However, arguments are provided for any formal parameters of the template, thus changing the interface of the template.\nInstantiation ::= ID [ \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; ] \u0026#39;=\u0026#39; ID \u0026#39;(\u0026#39; [Arguments] \u0026#39;)\u0026#39; \u0026#39;;\u0026#39; Template instantiation is most often used to bind formal parameters to actual arguments. The resulting template is later instantiated into a process by listing it in the system line.\nThe new template can itself be parameterised. This provides the opportunity to make a partial instantiation of a template, where some formal parameters are bound while others remain free. Examples of typical uses are listed below.\nFor more examples, see the example systems included in the UPPAAL distribution.\nExamples Renaming P1 = Q(); P2 = Q(); system P1, P2; Q is a template without any formal parameters. P1 and P2 become templates identical to Q. This is used to make several instances of Q with different names. Notice that P1=Q() is a shorthand of P1()=Q().\nBinding parameters In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess R(int \u0026amp;i, const int j) { ... } int x; S = R(x, 1); system S; Here we bind the formal parameters of R, i and j, to x and 1 respectively. S becomes a template without any parameters. When listed in the system line, S is instantiated into a process with the same name.\nPartial instantiation In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess P(int \u0026amp;x, int y, const int n, const int m) { ... } int v, u; const struct { int a, b, c; } data[2] = { { 1, 2, 3 }, { 4, 5, 6 } }; Q(int \u0026amp;x, const int i) = P(x, data[i].a, data[i].b, 2 * data[i].c); Q1 = Q(v, 0); Q2 = Q(u, 1); system Q1, Q2; Here P is a template with four formal parameters integer parameters. The first must be passed by reference, the remaining by value. Q is a template with two formal integer parameters. The first must be passed by reference, the second by value. Q1 is equivalent to P(v, data[0].a, data[0].b, 2 * data[0].c.\nThis is very convenient when defining many instances of the same template with almost the same arguments. It is also useful to bind some formal parameters and leave others free. When the resulting template is listed in the system line, UPPAAL will create a process for each possible combination of arguments to the free parameters.\n"},{"uri":"/language-reference/system-description/declarations/types/","title":"Types","tags":[],"description":"","content":"There are 6 predefined types: int, bool, clock, chan, double and string. Array and record types can be defined over all types except string.\nType ::= Prefix TypeId Prefix ::= \u0026#39;urgent\u0026#39; | \u0026#39;broadcast\u0026#39; | \u0026#39;meta\u0026#39; | \u0026#39;const\u0026#39; TypeId ::= ID | \u0026#39;int\u0026#39; | \u0026#39;clock\u0026#39; | \u0026#39;chan\u0026#39; | \u0026#39;bool\u0026#39; | \u0026#39;double\u0026#39; | \u0026#39;string\u0026#39; | \u0026#39;int\u0026#39; \u0026#39;[\u0026#39; [Expression] \u0026#39;,\u0026#39; [Expression] \u0026#39;]\u0026#39; | \u0026#39;scalar\u0026#39; \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; | \u0026#39;struct\u0026#39; \u0026#39;{\u0026#39; FieldDecl (FieldDecl)* \u0026#39;}\u0026#39; FieldDecl ::= Type ID ArrayDecl* (\u0026#39;,\u0026#39; ID ArrayDecl*)* \u0026#39;;\u0026#39; ArrayDecl ::= \u0026#39;[\u0026#39; [Expression] \u0026#39;]\u0026#39; | \u0026#39;[\u0026#39; Type \u0026#39;]\u0026#39; The default range of an integer is [-32768, 32767]. Any assignment out of range will cause the verification to abort.\nVariables of type bool can have the values false and true, which are equivalent to the the integer values 0 and 1. Like in C, any non-zero integer value evalutes to true and 0 evaluates to false.\nChannels can be declared as urgent and/or broadcast channels. See the section on synchronisations for information on urgent and broadcast channels.\nFloating-point variables of the double-type behave like C-double. Doubles values are not supported in the symbolic verification and simulation engine and are simply ignored, which can lead to unexpected results.\nVariables of string type must be declared constant. The primary use of string variables is in combination with External Functions\nConstants Integers, booleans, doubles strings, and arrays and records over integers and booleans can be marked constant by prefixing the type with the keyword const.\nMeta variables Integers, booleans, doubles, and arrays and records over integers and booleans can be marked as meta variables by prefixing the type with the keyword meta.\nMeta variables are stored outside of the state vector and are semantically not considered part of the state. I.e. two states that only differ in meta variables are considered to be equal.\nArrays The size of an array is specified either as an integer or as a bounded integer type or scalar set type. In the first case the array will be 0-indexed. In the latter case, the index will be of the given type. The following declares a scalar set s_t of size 3 and an integer array a of size 3 indexed by the scalar:\ntypedef scalar[3] s_t; int a[s_t]; Record Variables Record types are specified by using the struct keyword, following the C notation. For example, the record s below consist of the two fields a and b:\nstruct { int a; int b; } s; Scalars Scalars in UPPAAL are integer like elements with a limitted number of operations: Assignment and identity testing. Only scalars from the same scalar set can be compared.\nThe limitted number of operations means that scalars are unordered (or that all orders are equivalent in the sense that the model cannot distinguish between any of the them). UPPAAL applies symmetry reduction to any model using scalars. Symmetry reduction can lead to dramatic reductions of the state space of the model. resulting in faster verification and less memory being used.\nNotice that symmetry reduction is not applied if diagnostic trace generation is enabled or when A\u0026lt;\u0026gt;, E[] or --\u0026gt; properties are verified.\nScalar sets are treated as types. New scalar sets are constructed with the scalar[n] type constructor, where n is an integer indicating the size of the scalar set. Scalars of different scalar sets are incomparable. Use typedef to name a scalar set such that is can be used several times, e.g.\ntypedef scalar[3] mySet; mySet s; int a[mySet]; Here mySet is a scalar set of size 3, s is a variable whos value belongs to the scalar set mySet and a is an array of integers indexed by the scalar set mySet. Thus a[s] = 2 is a valid expression.\nCharacter Strings or Textual Type UPPAAL supports text constants via const string type for calling External Functions and refering to file system paths.\nFor example:\nconst string text = \u0026#34;message\u0026#34;; "},{"uri":"/toolsandapi/uppaal/","title":"UPPAAL","tags":[],"description":"","content":"UPPAAL can be executed from the command line using the following command on unix:\nuppaal [OPTION] \u0026hellip; [FILENAME]\nOn windows, the following command can be used (for instance, using \u0026ldquo;Run\u0026rdquo; from the Start Menu):\njava -jar \\path\\uppaal.jar [OPTION] \u0026hellip; [FILENAME]\nwhere path is the complete path to the uppaal.jar file (it might also be necessary to specify the complete path to the java executable).\nThe optional filename refers to a model to be loaded at startup.\nThe available command line options are:\n--antialias on|off (default on) turns antialiasing on or off in the automata rendering. --engineName The name of verification server (default is server on Unix and server.exe on Windows) to be used by the GUI. --enginePath The path to the verification server (e.g. bin-Windows) to be used by the GUI. --help Displays a summary of options. --serverHost Host name of remote machine running verification server. --serverPort Port number used by verification server on remote machine. --export templateName filename.ext Export the named template to a graphics file. The graphics format is determined by the filename extension, and EPS will be used instead if format is not recognized. Use system keyword to export all templates where the filenames will be taken from the template name. --psColors on|off Selects whether to export automata in color or greyscale EPS. "},{"uri":"/gui-reference/yggdrasil/tutorial/using-variables/","title":"Using Model Variables","tags":[],"description":"","content":"This tutorial assumes you have understood basic test case generation.\nThe model: Up/Down system Open the updown/updown.xml file in Uppaal.\nThe system contains two templates: System and User.\nThe system can be either On, Max, or Off, with channels up and down changing between them. The user can non-deterministically press up or down.\nSystem template User template Add model annotations and test pre- and post-fix code Global variable declarations and prefix/postfix code is the same as for the on/off model.\nAdd test step code annotations accessing model variables The system model is decorated with slightly different test code.\nThe location Off is still decorated with expect_off();, similarly the location Max is decorated with expect_max();. The state On is different, since here we want to verify the value of the variable val as well as the location. This is done by entering the value of val into the test case using the code expect_on($(System.val));. This will execute the expect_on with the value of val as parameter. Since val is local to the process System the name is entered as System.val. Generating the test cases Like the basic case, to generate test cases go to the Test Cases tab.Select which techniques for test case generation to use. For now only select Depth auto mode and a depth of 20. Click Add to generate the test cases. Inspecting the coverage The test generation will normally generate 2-3 test case traces (depending on randomization). Here 3 traces were generated. Each trace generated will have a line in the list similar to Trace coverage: 5/8. This shows that the trace covered five out of eight edges. Selecting a specific trace will show furter coverage statistics about that trace, i.e., which locations/edges are traversed how many times. Here, the System\u0026rsquo;s edge from location On to On has been traversed 6 times, whereas the edge from On to Off is traversed 0 times, revealing that it is not covered by this trace.\nBy double clicking the trace and then selecting the Simulator tab, the trace can be further examined. By selecting Mark Visited in the View menu, all covered edges will be colored blue in the simulator.\nThe total coverage achieved by the previous steps can be viewed by clicking the Total Coverage button which updates the trace statistics with the combined coverage. Due to the randomness of the model and the test case generation algorithm it is unlikely to get 100% coverage. Here, 1 location and 3 edges are left uncovered.\nCompleting coverage using the Single Step method This coverage can be increased by using the Single step method. This method searches for traces for uncovered edges. Adding these, should result in a number of test trace being added (here one, thus four in total) giving 8/8 in total coverage, thereby achieving the desired high coverage; here complete edge- and location-coverage.\nInspecting the test case code Save the test cases using the Save Test Cases button; select the output folder for test case to be the updown folder in this tutorial. This will produce a test-case file named testcase0.code in the selected output folder. If several traces have been generated, several files will be generated with sequential numbering.\nEach of these will be a Java class with the sequence of method invocations induce by the generated trace. A snippet is shown below.\n1: package app; 2: import app.App; 3: 4: class Test extends App { 5: 6: public static void main(String[] args) { 7: 8: 9: expect_off(); 10: 11: up(); 12: 13: expect_on(1); 14: 15: up(); 16: 17: expect_on(2); 18: 19: up(); 20: 21: expect_on(3); 22: 23: down(); 24: 25: expect_on(2); 26: 27: up(); \u0026lt;... snip ...\u0026gt; 94: } 95: } The overall composition of the test case is the same as in the first part of the tutorial The difference can be seen on lines 13, 17, 21, and 25. Here it is seen that the value of val is entered into the trace. It can be seen that the value increases after up(); and decreases after down();. Running the test.sh (or test.bat on Windows) will compile and run the test cases one at a time. It will output the name of each file as it executes them. No output from the test case signifies successful execution.\nupdown$ ./test.sh testcase0.code testcase1.code testcase2.code testcase3.code updown$ Running the testMutant.sh (or testMutant.bat on Windows) will compile and run the test cases on the mutant implementation. This should result in an exception being thrown when executing test case number 3, signifying a test error.\nupdown$ ./testMutant.sh testcase0.code testcase1.code testcase2.code testcase3.code Exception in thread \"main\" java.lang.AssertionError at app.App.expect_on(App.java:17) at app.Test.main(Test.java:15) updown$ The implementation can be examined in the updown/app folder. See updown/app/AppC.java for the correct implementation and updown/app/AppM.java for the mutant.\n"},{"uri":"/gui-reference/yggdrasil/tutorial/using-queries/","title":"Using Queries","tags":[],"description":"","content":"This tutorial assumes you have understood using variables.\nThe system model This tutorial uses the same Up/Down model as in the section using variables. Open the updown/updown.xml file in Uppaal.\nEditing the Queries Sometimes it is desirable to generate test cases for specific purposes. This can be done by creating a verification query for the purpose, and use that to generate a test trace.\nIn the Verifier tab you can enter queries. The Test Cases generator is able to search for traces satisfying reachability queries (that is queries which start with E\u0026lt;\u0026gt;. The query entered in this tutorial should be E\u0026lt;\u0026gt; System.Max, which asks the verifier to find a trace where the System process is in the location Max.\nGenerating test traces from queries To generate test cases go to the Test Cases tab and activate the Query mode, and hit Add.\nThis will generate a trace from the query file that leads to the Max location. You can inspect in the trace statistics that that location is infact now covered. By default, a test trace will be generated per query for all queries in the query file. In the drop-down selector you can chosse a specific query to generate and add.\nFurther, you can double click the trace and go to the Simulator tab and verify that this trace does indeed lead to the Max location. From the Off location this requires doing up ten successive times. Generating tests using the combined methodology As recommended, start by adding test cases for the test purposes (queries), then optimize coverage by the auto-depth mode, and finally single-step mode. This results in the three sections listed the test traces output panel.\n"},{"uri":"/language-reference/query-syntax/controller_synthesis/","title":"Syntax of Controller Synthesis","tags":[],"description":"","content":"Controller Synthesis Queries Controller synthesis queries are decided using symbolic techniques over Timed Game (TIGA) automata, where the discrete actions are either controllable (controller\u0026rsquo;s actions, solid edges) or uncontrollable (environment actions, dashed edges). The result is either a strategy solving the game objective or that the strategy does not exist.\nControlQuery ::= ControlSpecifier Goal Subjection | CollaborativeControlSpecifier Goal Subjection | PartialControlSpecifier Goal Subjection | TimeEfficientGameSpecifier Goal ControlSpecifier ::= \u0026#39;control:\u0026#39; CollaborativeControlSpecifier ::= \u0026#39;E\u0026lt;\u0026gt;\u0026#39; \u0026#39;control:\u0026#39; PartialControlSpecifier ::= \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; \u0026#39;control:\u0026#39; TimeEfficientGameQuery ::= \u0026#39;control_t*\u0026#39; \u0026#39;(\u0026#39; GameTimeLimitExpression \u0026#39;,\u0026#39; LocalGameTimeLimitExpression \u0026#39;):\u0026#39; | \u0026#39;control_t*\u0026#39; \u0026#39;(\u0026#39; u \u0026#39;):\u0026#39; | \u0026#39;control_t*:\u0026#39; Goal ::= \u0026#39;A\u0026lt;\u0026gt;\u0026#39; WinExpression | \u0026#39;A[\u0026#39; NotLoseExpression \u0026#39;U\u0026#39; WinExpression \u0026#39;]\u0026#39; | \u0026#39;A[\u0026#39; NotLoseExpression \u0026#39;W\u0026#39; WinExpression \u0026#39;]\u0026#39; | \u0026#39;A[]\u0026#39; NotLoseExpression WinExpression ::= Expression NotLoseExpression ::= Expression GameTimeLimitExpression ::= Expression LocalGameTimeLimitExpression ::= Expression Subjection ::= // empty for no subjection | under StrategyName GameTimeLimitExpression describes a time limit within the game must be won. This expression is only evaluated once at the beginning, thus should not depend on the current state. LocalGameTimeLimitExpression describes an additional time limit such that the game can be won within GameTimeLimitExpression - LocalGameTimeLimitExpression time units. This expression is evaluated in each state, and can therefore depend on state or clock constraints. Must be side-effect free. See rail road diagram for the entire ControlQuery syntax.\nExamples control: E\u0026lt;\u0026gt; goal compute a strategy where goal state predicate is eventually true no matter what the oponent/environment chooses to do. The resulting strategy is deterministic in a sense that for a given state the strategy proposes one action for the player/controller (while the oponent/environment may still choose from multiple actions). control: A[] safe compute a strategy where safe state predicate is always true no matter what the opponent/environment chooses to do. The strategy is permissive in a sense that for a given state the strategy may propose multiple actions for the player/controller. Such permissive strategy can be thought of as a union of all strategies satisfying the predicate, therefore it does not have any notion of progress and may include infinite loops. A[ safe U goal ] computes a safety strategy but only up until the goal is reached. A[ safe W goal ] (weakly until the goal) either a safety strategy is found or a safety strategy holds until the goal is reached. See also Strategy Queries below on how to store and query the properties of the computed strategies.\n"},{"uri":"/language-reference/query-syntax/","title":"Query Syntax","tags":[],"description":"","content":"This section describes a BNF-grammar for the requirement specification language used in the verifier of UPPAAL.\nSymbolic Queries Controller Synthesis Statistical Queries Learning Queries Strategy Queries See also rail road diagram for the entire Query syntax.\n"},{"uri":"/gui-reference/system-editor/drawing/","title":"Drawing","tags":[],"description":"","content":"The rightmost panel of the system editor is used for drawing automata. There are currently four drawing tools named Select, Location, Edge, and Nail represented by the buttons in the tool bar.\nSelect tool: The select tool is used to select, move, modify and delete elements. Elements can be selected by clicking on them or by dragging a rubber band arround one or more elements. Elements can be added or removed from a selection by holding down the control key while clicking on the element. The current selection can be moved by dragging them with the mouse. Double clicking an element brings up the editor for that element. Right clicking an element brings up a pop-up menu from which properties of the element can be changed. It is possible to change the source and target of an edge by moving the mouse to the beginning or end of an edge until a small circle appears. Drag this circle to a new location in order to change the source or target of the edge. Location tool: The location tool is used to add new locations. Simply click with the left mouse button in order to add a new location. Branch tool: The branch tool is used to create probabilistic branches. Simply click with the left mouse button in order to add a new branch point, then choose edge tool to create connecting edges. Edge tool: The edge tool is used to add new edges between locations. Start the edge by clicking on the source location, then click in order to place nails and finally click the target location. The operation can be cancelled by pressing the right mouse button. Nail tool: The nail tool is used to add new nails to an edge. Simply click and drag anywhere on an edge to add and place a new nail. For users with a three button mouse, the middle mouse button can be used to create new elements. The editor automatically chooses the correct tool: Clicking on an empty spot creates a new location, clicking on a location creates a new edge and clicking on an edge creates a new nail. With this feature it is possible to use the functionallity of all four tools without having to select the tools directly.\nColors The display color of individual locations and edges can be changed from the pop-up menu for these elements. UPPAAL does not assign any semantic meaning to the colors of locations and edges.\nComments Comments can be added to locations and edges. Double click the location or edge to bring up the editor for that element. The editor has a Comments tab for adding comments. UPPAAL does not assign any semantic meaning to the comments.\nComments are shown as document elements on the canvas. These elements can be resized by distributing the content of the comments over multiple lines.\nWhen shown in the tooltip of an element, comments are interpreted as HTML, i.e. tags like \u0026lt;p\u0026gt; and \u0026lt;b\u0026gt; may be used for formating.\nTooltips A tooltip is shown when hovering the mouse over an automaton element. The tooltip contains useful information such as syntax errors.\n"},{"uri":"/language-reference/system-description/templates/edges/","title":"Edges","tags":[],"description":"","content":"Locations are connected by edges. Edges are annotated with selections, guards, synchronisations and updates. Edges may also have branches of possible destinations with their own updates and probabilistic weights.\nSelections Selections non-deterministically bind a given identifier to a value in a given range. The other three labels of an edge are within the scope of this binding. Guards An edge is enabled in a state if and only if the guard evaluates to true. Synchronisation Processes can synchronize over channels. Edges labelled with complementary actions over a common channel synchronise. Updates When an edge is traversed, the update expression of the edge is evaluated. The side effect of this expression changes the state of the system. Weights Edges emanating from a branchpoint can be assigned a probabilistic weight. The probability such edge-transition is proportional to the edge weight and inversely proportional to the sum of weights over all edges leaving that branchpoint. Selections SelectList ::= ID \u0026#39;:\u0026#39; Type | SelectList \u0026#39;,\u0026#39; ID \u0026#39;:\u0026#39; Type For each ID in SelectList, bind ID non-deterministically to a value of type Type domain. The identifiers are available as variables within the other labels of this edge (guard, synchronization, or update). The supported types are bounded integers and scalar sets. Note: The identifiers will shadow any variables with the same name.\nExample Select: i : int[0,3]\nSynchronization: a[i]?\nUpdate: receive_a(i)\nThis edge will non-deterministically bind i to an integer in the range 0 to 3, inclusive. The value i is then used both as an array index when deciding what channel to synchronize on, and as an argument in the subsequent call to the function receive_a.\nGuards Guards follow the abstract syntax of expressions. However, the type checker restricts the set of possible expressions allowed in guards: A guard must be a conjunction of simple conditions on clocks, differences between clocks, and boolean expressions not involving clocks. The bound must be given by an integer expression.\nExamples x \u0026gt;= 1 \u0026amp;\u0026amp; x \u0026lt;= 2 x is in the interval [1,2]. x \u0026lt; y x is (strictly) less than y. (i[0]+1) != (i[1]*10) Value at position 0 in an integer array i plus one is not equal to value at position 1 times 10 (i must be an integer array since we use arithmetic operations on its elements). Synchronisations Channels are used to synchronise processes. This is done by annotating edges in the model with synchronisation labels. Synchronisation labels are syntactically very simple. They are of the form e? or e!, where e is a side effect free expression evaluating to a channel.\nThe intuition is that two processes can synchronise on enabled edges annotated with complementary synchronisation labels, i.e. two edges in different processes can synchronise if the guards of both edges are satisfied, and they have synchronisation labels e1? and e2! respectively, where e1 and e2 evaluate to the same channel.\nWhen two processes synchronise, both edges are fired at the same time, i.e. the current location of both processes is changed. The update expression on an edge synchronizing on e1! is executed before the update expression on an edge synchronizing on e2?. This is similar to the kind of synchronisation used in CCS or to rendezvous synchronisation in SPIN.\nUrgent channels are similar to regular channels, except that it is not possible to delay in the source state if it is possible to trigger a synchronisation over an urgent channel. Notice that clock guards are not allowed on edges synchronising over urgent channels.\nBroadcast channels allow 1-to-many synchronisations. The intuition is that an edge with synchronisation label e! emits a broadcast on the channel e and that any enabled edge with synchronisation label e? will synchronise with the emitting process. I.e. an edge with an emit-synchronisation on a broadcast channel can always fire (provided that the guard is satisfied), no matter if any receiving edges are enabled. But those receiving edges, which are enabled will synchronise. Notice that clock guards are not allowed on edges receiving on a broadcast channel. The update on the emitting edge is executed first. The update on the receiving edges are executed left-to-right in the order the processes are given in the system definition.\nNotice that for both urgent and broadcast channels it is important to understand when an edge is enabled. An edge is enabled if the guard is satisfied. Depending on the invariants, the target state might be undefined. This does not change the fact that the edges are enabled! E.g. when two edges in two different processes synchronise via a broadcast channel, and the invariant of the target location of the receiving edge is violated, then this state is not defined. It is not the case that the emitting edge can be fired by itself since the receiving edge is enabled and thus must synchronise. Please see the section about the semantics for further details.\nUpdates An update is a comma separated list of expressions. These expressions will typically have side effects. Assignments to clocks are limited to the regular = assignment operator and only integer expressions are allowed on the right hand side of such assignments. The syntax of updates is defined by the grammar for Update:\nUpdate ::= [Expression (\u0026#39;,\u0026#39; Expression)*] Note: Assignments are evaluated sequentially (not concurrently). On synchronizing edges, the assignments on the !-side (the emitting side) are evaluated before the ?-side (the receiving side).\nThe regular assignment operator, =, can be used for assigning values to integer, boolean, record and clock variables. The other assignment operators are limitted to integer and boolean variables and work as in C, e.g. i += 2 is equivalent to i = i + 2 except that any side effect of evaluating i is only executed once in the first case whereas it is executed twice in the latter case.\nPlease remember that any integers are bounded. Any attempt to assign a value outside the declared range to an integer, will cause an error and the verification will be aborted.\nExamples x = 0 clock (or integer variable) x is reset. j = ( i[1]\u0026gt;i[2] ? i[1] : i[2] ) integer j is assigned the maximum value of array elements i[1] and i[2]. This is equivalent to j = i[1] \u0026gt;? i[2], except that one of the sub-expressions is evaluated twice in the example (once in the condition, and again in either the true case or the false case). x = 1, y = 2 * x integer variable x is set to 1 and y to 2 (as assignments are interpreted sequentially). Weights The weight over branch is a constant non-negative integer expressions denoting the probabilistic likely-hood of the branch being executed. The probability of a particular branch is determined as a ratio of its weight over the sum of weights of all branches emanating from the same branch node.\nThe weights are used in probabilistic and statistical model checking.\nExample Select: i : int[0,3]\nUpdate: gen_data(i)\nWeight: w[i]\n"},{"uri":"/gui-reference/menu-bar/edit/","title":"Edit Menu","tags":[],"description":"","content":"The Edit menu offers a set of commands supported in the system editor. The items are:\nUndo: reverses the most recent editing action. This function is only available in the editor. Redo: re-applies the editing action that has most recently been reversed by the Undo action. This function is only available in the editor. Cut: removes the selected text and places it in the clipboard. There must be an active text selection. Copy: places a copy of the selected text in the clipboard. There must be an active text selection. Paste: places text in the clipboard at the cursor location in the currently active editor. There must be text in the clipboard, and an editor must be active. Delete: delete selected text. There must be an active text selection. Insert Template: adds a new empty template to the system description. Remove Template: removes the currently selected template from the system description. There must be a template selected. "},{"uri":"/language-reference/system-description/declarations/functions/","title":"Functions","tags":[],"description":"","content":"Functions can be declared alongside other declarations. The syntax for functions is defined by the grammar for Function:\nFunction ::= [Type] [ID] \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; Block Block ::= \u0026#39;{\u0026#39; LocalDeclaration* Statement* \u0026#39;}\u0026#39; LocalDeclation ::= TypeDeclaration | VariableDeclaration Statement ::= Block | \u0026#39;;\u0026#39; | [Expression] \u0026#39;;\u0026#39; | ForLoop | Iteration | WhileLoop | DoWhileLoop | IfStatement | ReturnStatement ForLoop\t::= \u0026#39;for\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;;\u0026#39; [Expression] \u0026#39;;\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement Iteration ::= \u0026#39;for\u0026#39; \u0026#39;(\u0026#39; [ID] \u0026#39;:\u0026#39; [Type] \u0026#39;)\u0026#39; Statement WhileLoop ::= \u0026#39;while\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement DoWhile ::= \u0026#39;do\u0026#39; Statement \u0026#39;while\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; \u0026#39;;\u0026#39; IfStatment ::= \u0026#39;if\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement [ \u0026#39;else\u0026#39; Statement ] ReturnStatement ::= \u0026#39;return\u0026#39; [ [Expression] ] \u0026#39;;\u0026#39; See rail road diagram for the entire Function declaration.\nFunctions The declarations inside functions include only variable and type declarations. Nested function declarations and recursion are not supported.\nIteration The keyword for has two uses: the first is a C/C++/Java like for-loop, and the second is a Java like iterator or ranged-loop in C++. The second is primarily used to iterate over arrays indexed by scalars.\nA statement for (ID : Type) Statement will execute Statement once for each value ID of the domain of type Type. The scope of ID is bound to the Statement, and Type must be a bounded integer or a scalar set.\nSee also rail road diagrams for the entire ForStatement and WhileStatement.\nExamples add The following function returns the sum of two integers. The arguments are call by value.\nint add(int a, int b) { return a + b; } swap The following procedure swaps the values of two call-by-reference integer parameters.\nvoid swap(int \u0026amp;a, int \u0026amp;b) { int c = a; a = b; b = c; } initialize The following procedure initializes an array such that each element contains its index in the array. Notice that the an array parameter is a call-by-value parameter unless an ampersand is used in the declaration. This is different from C++ syntax, where the parameter could be considered an array of references to integer.\nvoid initialize(int\u0026amp; a[10]) { for (i : int[0,9]) { a[i] = i; } } Special Functions The following are the signatures of special functions which can be declared to be called on special verification events:\nvoid __ON_CONSTRUCT__(); void __ON_DESTRUCT__(); void __ON_BEGIN__(); void __ON_END__(); __ON_CONSTRUCT__ Called after the system (or a process) representation is constructed when specified in global declarations (or a template local declarations respectively). Useful to initialize meta variables and external libraries. __ON_DESTRUCT__ Called before the system (or a process) representation is destroyed when specified in global declarations (or a template local declarations respectively). Useful to release resources in external libraries. __ON_BEGIN__ Called before a query is started. Useful to initialize variables and external libraries. __ON_END__ Called after a query is finished. Useful to release resources in external libraries. One can also declare a statement to be executed before a transition is taken and after:\nbefore_update { old_value = variable } after_update { new_value = variable } "},{"uri":"/language-reference/","title":"Language Reference","tags":[],"description":"","content":"Chapter 2 UPPAAL Language Reference "},{"uri":"/language-reference/system-description/system-definition/progress-measures/","title":"Progress Measures","tags":[],"description":"","content":"A progress measure is an expression that defines progress in the model. It should be weakly monotonically increasing, although occasional decreasses are acceptable. E.g. sequence numbers used in communication protocols might be used to define a progress measure, provided that the sequence number does not overflow to often.\nIf progress measures are defined, UPPAAL uses the generalized sweepline method to reduce the memory usage. However to be efficient, the domain of a progress measure should not be too large - otherwise performance might degrade significantly.\nProgress measures are placed after the system definition. The syntax is defined by the grammar for ProgressDecl:\nProgressDecl ::= \u0026#39;progress\u0026#39; \u0026#39;{\u0026#39; ( [Expression] \u0026#39;;\u0026#39; )* \u0026#39;}\u0026#39; Examples int i, j, k; ... progress { i; j + k; } For the above to be a useful progress measure, i and j + k should increase weakly monotonically.\n"},{"uri":"/language-reference/query-semantics/","title":"Query Semantics","tags":[],"description":"","content":"Semantics of requirement specification language used in the verifier of UPPAAL.\nSymbolic Queries Statistical Queries Confidence Interval Estimation "},{"uri":"/gui-reference/yggdrasil/test-code/","title":"Specifying Test Code","tags":[],"description":"","content":"Traces are translated into executable test cases based on test code entered into the model. The test code is entered as verbatim text, so any language or execution back-end can be used. Test code can be entered in five areas: Prefix code, location enter code, location exit code, edge code, and postfix code. Each test case starts with the prefix code, continues with test code along the locations and edges of the trace and ends with the postfix code.\nThe prefix (and the postfix) code is entered as a comment after the system definition section using a special multi-line comment starting with the word TEST_PREFIX (and TEST_POSTFIX respectively).\nEach location in the transition system has two areas for test code. Double clicking a location in the editor will bring up a window with a test code tab. The location enter code is added to the test case when this location is entered, and the location exit code is added when the location is left.\nSimilarly double clicking an an edge will bring up a window with a single test code field. This code is added to the test case when the transition containing this edge is traversed.\nFor location and edge test code the value of variables can be entered into the test case. This is done using $(var) for global variables or $(Process.var) for process-local variables. Dollar signs can be escaped with backslash like $ and backslash can be escaped with backslash like \\. For location enter code the value is read after the transition into the state has been taken. For location exit code the value is read before the transition out of the state is taken. For edge code the value is read before taking the transition.\nThe test case file name and extension can be configured using special comments too: TEST_FILENAME and TEST_FILEEXT. These comments must be on one line. Generic name \u0026ldquo;testcase\u0026rdquo; and \u0026ldquo;.code\u0026rdquo; are used if these settings are not set.\nExample test case generation settings in the system declarations after the system definition:\n/** TEST_FILENAME test- */ /** TEST_FILEEXT .java */ /** TEST_PREFIX public class Test { public static int main(String[] args){ */ /** TEST_POSTFIX } } */ Note the double star in the special multiline comment start, single space characters in the TEST_FILE* options and no other characters on the comment begin and end lines in the TEST*FIX options._\n"},{"uri":"/language-reference/query-syntax/statistical_queries/","title":"Syntax of Statistical Queries","tags":[],"description":"","content":"Statistical Queries Statistical queries are decided using concrete semantics of stochastic hybrid automata over a number of bounded concrete simulation runs and correspond to empirical measurements of the system performance. The results are of statistical estimate nature and may vary across different executions based on uncertainties specified in Statistical parameters.\nSMCQuery ::= Simulate Subjection | Probability Subjection | ProbUntil Subjection | Probability ( \u0026#39;\u0026lt;=\u0026#39; | \u0026#39;\u0026gt;=\u0026#39; ) PROB Subjection | Probability Subjection \u0026#39;\u0026gt;=\u0026#39; Probability Subjection | Estimate Subjection Simulate ::= \u0026#39;simulate\u0026#39; \u0026#39;[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; [ \u0026#39;:\u0026#39; [ SATRUNS \u0026#39;:\u0026#39; ] Expression ] Probability ::= \u0026#39;Pr\u0026#39; MITLExpression | \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; PathType Expression \u0026#39;)\u0026#39; ProbUntil ::= \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; Expression \u0026#39;U\u0026#39; Expression \u0026#39;)\u0026#39; Estimate ::= \u0026#39;E[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; (\u0026#39;min:\u0026#39; | \u0026#39;max:\u0026#39;) Expression \u0026#39;)\u0026#39; SMCBounds ::= BoundType [ ; RUNS ] BoundType ::= ( | Clock | \u0026#39;#\u0026#39; ) \u0026#39;\u0026lt;=\u0026#39; BOUND PathType ::= ( \u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39; ) Subjection ::= // empty for no subjection | under StrategyName BOUND is a non-negative integer constant denoting an upper bound over the absolute global time (when a variable is not specified), specific Clock (cost) variable or a number of action-transitions (#). RUNS is an optional positive integer constant denoting the maximum number of runs. If the number of runs is not specified, then it is decided based on Statistical parameters and the particular estimation algorithm. SATRUNS is an optional positive integer constant denoting the maximum number of runs that satisfy the state expression. PROB is a floating point number from interval [0; 1] denoting a probability bound. \u0026rsquo;#\u0026rsquo; means a number of simulation steps \u0026ndash; discrete edge-transitions \u0026ndash; in the run. \u0026lsquo;min:\u0026rsquo; means the minimum value over a run of the proceeding expression. \u0026lsquo;max:\u0026rsquo; means the maximum value over a run of the proceeding expression. All expressions are state predicates and must be side effect free. It is possible to test whether a certain process is in a given location using expressions on the form process.location.\nSee rail road diagram for the entire SMCQuery syntax.\nSee also: Semantics of the SMC Queries\nExamples simulate [\u0026lt;=10] { x } creates one stochastic simulation run of up to 10 time units in length and plot the values of x expression over time (after checking, right-click the query and choose a plot). simulate [c\u0026lt;=10] { x, y+z } creates one simulation run of up to 10 cost units in terms of clock variable c and plot the values of x and y+z expressions over the cost c. simulate [#\u0026lt;=10] { x, y+z } creates one simulation run of up to 10 edge-transitions and plot the values of x and y+z expressions over the discrete simulation steps (edge-transitions). simulate [\u0026lt;=10; 100] { x, y+z } : 2 : goal selects up to 2 simulation runs from 100 simulations of up to 10 time units in length, which satisfy goal state predicate, and then plot the values of expressions x and y+z over time. The query will also estimate a probability confidense interval of the expression goal being true just like in Pr query. The confidence level is controlled by α-level of significance in the Statistical parameters. Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) runs a number of stochastic simulations and estimates the probability of good eventually becoming true within 10 time units. The number of runs is decided based on the probability interval precision (±ε) and confidence level (level of significance α in Statistical parameters), see Confidence Intervals for details. The query also computes a probability distribution over time when the predicate good is satisfied (right-click the property and choose a plot). Pr[c\u0026lt;=10; 100]([] safe) runs 100 stochastic simulations and estimates the probability of safe remaining true within 10 cost units in terms of clock c. Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) \u0026gt;= 0.5 checks if the probability of reaching good within 10 time units is greater than 50%. Such query uses Wald\u0026rsquo;s algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, α and β Statistical parameters. Pr[\u0026lt;=10](\u0026lt;\u0026gt; best) \u0026gt;= Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) checks if the probability of reaching best is greater than reaching good within 10 time units. Such query uses a sequential algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, u0, u1, α and β Statistical parameters. The query also provides a probability comparison plot over time/cost (right-click the query and choose plot). E[\u0026lt;=10; 100](max: cost) estimates the maximal value of cost expression over 10 time units of stochastic simulation. Uses 100 stochastic simulations and assumes that the value follows Student\u0026rsquo;s t-distribution with 1-α confidence level. The plots can be super-imposed using the Plot Composer from the Tools menu.\n"},{"uri":"/language-reference/system-description/templates/","title":"Templates","tags":[],"description":"","content":"UPPAAL provides a rich language for defining templates in the form of extended timed automata. In contrast to classical timed automata, timed automata in UPPAAL can use a rich expression language to test and update clock, variables, record types, call user defined functions, etc.\nThe automaton of a template consist of Locations and edges. A template may also have local declarations and parameters. A template is instantiated by a process assignment (in the system definition).\n"},{"uri":"/gui-reference/toolbar/","title":"Tool Bar","tags":[],"description":"","content":"The tool bar is normally located just below the menu bar but can be moved (using the mouse) to other positions or even to a separate window. The tool bar is divided into four groups. The three leftmost groups provide quick access to some of the most frequently used menu items. The rightmost group contains editing tools.\nThe first group contains the following buttons: New, Open Project, and Save. These features are described in the File menu section.\nThe second group contains the following buttons: Undo and Redo. These features are described in the Edit menu section.\nThe third group contains the following buttons: Zoom to Fit, Zoom In, and Zoom Out. This features are described in the View menu section.\nThe fourth group contains tools used in the editor for selecting and moving elements of an automaton, and for adding locations, edges and nails. This features are described in the section on Drawing.\n"},{"uri":"/gui-reference/concrete-simulator/variables/","title":"Variables Panel","tags":[],"description":"","content":"The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.\n"},{"uri":"/gui-reference/verifier/verifying/","title":"Verifying Requirements","tags":[],"description":"","content":"The queries (i.e. the system requirements) are verified from the verifier interface of UPPAAL. A verification is always performed according to the settings specified in the Options menu of the main menu bar.\nThe selected queries are verified when the button named Check is pressed. The verification progress dialog displays the progress of how many queries have been verified, what is the current load of a passed-waiting list, current processor time usage (the time spent for verification is in blue, the time spent by operating system is in red), current usage of host\u0026rsquo;s random access memory (verification memory is in blue, memory used by other running processes is in gray and operating system cache and buffers are in yellow), swap disk usage (swapped out verification is in blue, other is in grey). Note that resource figures do not include the overhead of UPPAAL GUI and command line utilities (like memtime run on verifyta) are more accurate. Some figures are not available on some OSes (system cache allocation is not documented on Windows API and swap usage per process is not maintained by Linux kernel), therefore they might not show up.\nThe verification output is displayed in the Status field at the bottom of the verifier panel. The result is also indicated by the circular markers in the rightmost column of the Overview panel. A grey marker indicates that the truth value of the property is unknown, a green marker that the property is satisfied, and a red marker that the property is not satisfied.\nIn case the Over Approximation or the Under Approximation options are selected for State Space Representation, the output of the verifier might be that property is \u0026ldquo;maybe satisfied\u0026rdquo;. This happens when the verifier cannot determine the truth value of the property due to the approximations used.\nStatistical Model Checking Parameters for statistical model checking can be changed in the Options menu. Various data plots (if available) can be accessed via popup-menu by right-clicking the statistical property. The y-axis always denotes a probability or its density, while x-axis denotes either the variable values limited by the statistical query or a step (transition) count in the model run.\nProbability density distribution A histogram created from probability distribution where each bucket is normalized by a bucket width. Useful for comparison of various distributions, potentially with different bucket widths. Probability distribution A histogram created from a frequency histogram where each bucket is normalized by a total number of runs. Useful for assessing a probability of a property being satisfied at a particular moment in time interval. Cumulative probability distribution A histogram created by adding up all frequency histogram buckets up to the current bucket and normalized by a total number of runs. Confidence Intervals for Probabilities The confidence intervals for probabilities are computed using Clopper-Pearson method (also known as \"exact\") for binomial distribution for a given level of confidence (1-α). The method is conservative in a sense that it guarantees the minimum coverage of the real probability in (1-α) of cases. In the plots, the estimated confidence is valid only for one bucket at a time (the gathered data is reused to compute each individual bucket). Confidence Intervals for Mean The confidence intervals for mean estimation are computed using quantiles of Student's t-distribution for a given level of confidence of 1-α. Note that t-distribution approaches the commonly used Normal (Gaussian) distribution when the number of samples is high. Frequency histogram The frequency histogram is created by calculating the number of runs satisfying the property at a particular moment in time interval. Useful for calculating the number of runs. Any plot can be customized from a popup menu by right-clicking on the plot.\nFurther, the plot labels and titles can be edited and several data sets can be superimposed in one figure by using Plot Composer, accessible from the Tools menu. It is possible to create several composite plots at a time by invoking Plot Composer multiple times.\nAn extensive overview and comparison of methods for computing confidence intervals for binomial distribution can be found in the following publications:\nInterval Estimators for a Binomial Proportion: Comparison of Twenty Methods, Ana M. Pires and Conceicao Amado. REVSTAT \u0026ndash; Statistical Journal, Vol.6, No.2, June 2008, pages 165-197.\nInterval Estimation for a Binomial Proportion, Lawrence D. Brown, T. Tony Cai and Anirban DasGupta. Statistical Science, 2001, Vol.16, No.2, pages 101-133.\n"},{"uri":"/toolsandapi/verifyta/","title":"verifyta","tags":[],"description":"","content":"The verifier functionality is accessible through verifyta command line utility in bin-Windows or bin-Linux directory of the distribution. The supported options are displayed when running verifyta -h.\n"},{"uri":"/language-reference/query-syntax/learning_queries/","title":"Syntax of Learning Queries","tags":[],"description":"","content":"Learning Queries LearningQuery ::= ExpQuantifier \u0026#39;(\u0026#39; Expression \u0026#39;)\u0026#39; \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection | ExpQuantifier \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection | ExpPrQuantifier \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection ExpQuantifier ::= ( minE | maxE ) ExpPrQuantifier ::= ( minPr | maxPr ) Features ::= \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; \u0026#39;-\u0026gt;\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; Subjection ::= // empty for no subjection | under StrategyName Features describes a mapping (state space partition) from a partial state to a player action. The first list maps in the discrete space (values interpreted as distinct categories) and the second list maps in continuous space (assumes distance between values: similar values yield similar cost). See rail road diagram for the entire LearningQuery syntax.\nExamples minE(cost) [\u0026lt;=10] : \u0026lt;\u0026gt; goal learns a strategy that minimizes the expected cost expression within 10 time units or when goal predicate becomes true given that the entire system state is observable. maxE(gain) [\u0026lt;=10] : \u0026lt;\u0026gt; goal learns a strategy that maximizes the expected gain expression withing 10 time units or when goal predicate becomes true given that the entire system state is observable. The goal predicate is deprecated, for best results use a predicate which stops together with the simulation bound, like t\u0026gt;=10, where t is a clock that is never reset.\nminE(cost) [\u0026lt;=10] { i, j } -\u0026gt; { d, f } : \u0026lt;\u0026gt; goal learns a strategy that minimizes the expected cost expression within 10 time units or when goal predicate becomes true. Where only the expressions i, j, d and f are observable. The {..} -\u0026gt; {..} syntax controls what is observable. On one hand, by observing only a partial state learning times can be significantly reduced and the strategy structure simplified. On the other hand, the resulting strategy is not guaranteed to converge to a optimal solution under partial observability. There are two types of observable state expressions: discrete and continuous. The discrete are specified in the first bracket and the continuous in the second: {discrete expressions} -\u0026gt; {continuous expressions}. By default the entire state is considered during learning. Discrete expressions are observed as they are, i.e the query minE(cost) [\u0026lt;=10] { i, j } -\u0026gt; { } : \u0026lt;\u0026gt; goal creates a strategy by only observing the values of i and j.\nContinuous expressions are discretized using online partition refinement (see Teaching Stratego to Play Ball). The query minE(cost) [\u0026lt;=10] { } -\u0026gt; { d, f } : \u0026lt;\u0026gt; goal learns a strategy based on the discretized expressions d and f.\nIntegers, clocks, floating points or even arbitrary expressions can be used in either type of observabilty. However we suggest caution when using floating point numbers or clocks in discrete observability.\nProcess locations are ignored when specifying observability unless explicitly specified using location keyword. For example Cat.location and Mouse.location refer to the locations of Cat and Mouse processes.\nThe learning queries are usually used together with strategy assignment and refinement explained in Strategy Queries.\n"},{"uri":"/gui-reference/system-editor/declarations/","title":"Declarations","tags":[],"description":"","content":"Types, constants, variables and functions can be defined in the global scope by placing them in the global section labelled Declarations or System declarations, or locally for a template by placing in the Declarations section of a template.\nProcesses are instantiated by placing a process assignments in the System declarations section.\nFinally, the system is defined as a parallel composition of a number of processes by placing a system declaration in the System declarations section.\nThe syntax for each of these sections is defined in the Language Reference.\n"},{"uri":"/language-reference/expressions/","title":"Expressions","tags":[],"description":"","content":"Most of the expression syntax of UPPAAL coincides with that of C, C++ and Java. For example assignments are done using the = operator (the older := still works, but = is preferred). Notice that assignments are expressions themselves, for example expression b = (a = 1) + 2 assigns 1 to a, then adds 2 and assigns the result to b.\nThe syntax of expressions is defined by the grammar for Expression.\nExpression = [ID] | NAT | Expression \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; | Expression \u0026#34;\u0026#39;\u0026#34; | \u0026#39;(\u0026#39; Expression \u0026#39;)\u0026#39; | Expression \u0026#39;++\u0026#39; | \u0026#39;++\u0026#39; Expression | Expression \u0026#39;--\u0026#39; | \u0026#39;--\u0026#39; Expression | Expression Assign Expression | Unary Expression | Expression Binary Expression | Expression \u0026#39;?\u0026#39; Expression \u0026#39;:\u0026#39; Expression | Expression \u0026#39;.\u0026#39; ID | Expression \u0026#39;(\u0026#39; Arguments \u0026#39;)\u0026#39; | \u0026#39;forall\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;exists\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;sum\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;deadlock\u0026#39; | \u0026#39;true\u0026#39; | \u0026#39;false\u0026#39;; Arguments = [ Expression ( \u0026#39;,\u0026#39; Expression )* ]; Assign = \u0026#39;=\u0026#39; | \u0026#39;:=\u0026#39; | \u0026#39;+=\u0026#39; | \u0026#39;-=\u0026#39; | \u0026#39;*=\u0026#39; | \u0026#39;/=\u0026#39; | \u0026#39;%=\u0026#39; | \u0026#39;|=\u0026#39; | \u0026#39;\u0026amp;=\u0026#39; | \u0026#39;^=\u0026#39; | \u0026#39;\u0026lt;\u0026lt;=\u0026#39; | \u0026#39;\u0026gt;\u0026gt;=\u0026#39;; Unary = \u0026#39;+\u0026#39; | \u0026#39;-\u0026#39; | \u0026#39;!\u0026#39; | \u0026#39;not\u0026#39;; Binary = \u0026#39;\u0026lt;\u0026#39; | \u0026#39;\u0026lt;=\u0026#39; | \u0026#39;==\u0026#39; | \u0026#39;!=\u0026#39; | \u0026#39;\u0026gt;=\u0026#39; | \u0026#39;\u0026gt;\u0026#39; | \u0026#39;+\u0026#39; | \u0026#39;-\u0026#39; | \u0026#39;*\u0026#39; | \u0026#39;/\u0026#39; | \u0026#39;%\u0026#39; | \u0026#39;\u0026amp;\u0026#39; | \u0026#39;|\u0026#39; | \u0026#39;^\u0026#39; | \u0026#39;\u0026lt;\u0026lt;\u0026#39; | \u0026#39;\u0026gt;\u0026gt;\u0026#39; | \u0026#39;\u0026amp;\u0026amp;\u0026#39; | \u0026#39;||\u0026#39; | \u0026#39;\u0026lt;?\u0026#39; | \u0026#39;\u0026gt;?\u0026#39; | \u0026#39;or\u0026#39; | \u0026#39;and\u0026#39; | \u0026#39;imply\u0026#39;; Like in C++, assignment, preincrement and predecrement expressions evaluate to references to the first operand. The inline-if operator does in some cases (e.g. when both the true and false operands evaluate to compatible references) also evaluate to a reference, i.e., it is possible to use an inline-if on the left hand side of an assignment.\nThe use of the deadlock keyword is restricted to the requirement specification language.\nSee rail road diagram for the entire Expression syntax.\nBoolean Values Boolean values are type compatible with integers. An integer value of 0 (zero) is evaluated to false and any other integer value is evaluated to true. The boolean value true evaluates to the integer value 1 and the boolean value false evaluates to the integer value 0. Notice: A comparison like 5 == true evaluates to false, since true evaluates to the integer value 1. This is consistent with C++.\nPrecedence UPPAAL operators have the following associativity and precedence, listed from the highest to lowest. Operators borrowed from C keep the same precedence relationship with each other.\nAssociativity Operator left () [] . right ! not ++ -- unary - unary + left * / % left binary - binary + left \u0026lt;\u0026lt; \u0026gt;\u0026gt; left \u0026lt;? \u0026gt;? left \u0026lt; \u0026lt;= \u0026gt;= \u0026gt; left == != left \u0026amp; left ^ left | left \u0026amp;\u0026amp; and left || or imply right ?: right = := += -= *= /= %= \u0026amp;= |= \u0026lt;\u0026lt;= \u0026gt;\u0026gt;= ^= left forall exists sum Operators Anybody familiar with the operators in C, C++, Java or Perl should immediately feel comfortable with the operators in UPPAAL. Here we summarise the meaning of each operator.\nOperator Description Example () Parenthesis alter the evaluation order 3 * (5 - 2) → 9 [] Array lookup my_array[0] . Infix lookup operator to access process or structure type scope my_struct.field1 ! Logical negation ! true → false not Logical negation not true → false ++ Increment (can be used as both prefix and postfix operator) ++counter counter++ -- Decrement (can be used as both prefix and postfix operator) --counter counter-- - Integer subtraction (can also be used as unary negation:-7) 5 - 3 → 2 + Integer addition (can also be used as unary plus: +7) 5 + 3 → 8 * Integer multiplication 5 * 3 → 15 / Integer division 5 / 3 → 1 % Modulo 5 % 3 → 2 \u0026lt;\u0026lt; Left bitshift 1 \u0026lt;\u0026lt; 4 → 16 \u0026gt;\u0026gt; Right bitshift 16 \u0026gt;\u0026gt; 4 → 1 \u0026lt;? Minimum 8 \u0026lt;? 12 → 8 \u0026gt;? Maximum 8 \u0026gt;? 12 → 12 \u0026lt; Less than 5 \u0026lt; 3 → true \u0026lt;= Less than or equal to 5 \u0026lt;= 3 → true == Equality operator 5 == 3 → false != Inequality operator 5 != 3 → true \u0026gt;= Greater than or equal to 5 \u0026gt;= 3 → true \u0026gt; Greater than 5 \u0026gt; 3 → true \u0026amp; Bitwise and 3 \u0026amp; 2 → 2 ^ Bitwise xor 1 ^ 3 → 2 | Bitwise or 1 | 3 → 3 \u0026amp;\u0026amp; Logical and (conjunction) true \u0026amp;\u0026amp; false → false and Logical and (conjunction) true and false → false || Logical or (disjunction) true || false → true or Logical or (disjunction) true or false → true ?: Inline if-then-else (ternary) operator true ? 8 : 12 → 8 imply Logical implication true imply false → false forall Forall quantifier forall (i : int[2, 10]) i*10 \u0026gt; 10 → true exists Exists quantifier exists (i : int[2, 10]) i*10 \u0026gt; 90 → true sum Sum expression sum (i : int[2, 10]) i*10 → 540 Notice that the keywords not, and and or behave the same as the !, \u0026amp;\u0026amp;, and || operators.\nAn integer expression used in logical expression is converted into boolean value by comparing the integer expression with zero. For example, x ? 1 : 2 is interpreted as (x != 0) ? 1 : 2.\nA few binary operators can be syntactically combined with assignment to produce a compact assignment expression:\nOperator Assignment Example Meaning + += x += y x = x + y - -= x -= y x = x - y * *= x *= y x = x * y / /= x /= y x = x / y % %= x %= y x = x % y \u0026amp; \u0026amp;= x \u0026amp;= y x = x \u0026amp; y ^ ^= x ^= y x = x ^ y | |= x |= y x = x | y \u0026lt;\u0026lt; \u0026lt;\u0026lt;= x \u0026lt;\u0026lt;= y x = x \u0026lt;\u0026lt; y \u0026gt;\u0026gt; \u0026gt;\u0026gt;= x \u0026gt;\u0026gt;= y x = x \u0026gt;\u0026gt; y Expressions Involving Clocks When involving clocks, the actual expression syntax is restricted by the type checker. Expressions involving clocks are divided into three categories: Invariants, guards, and constraints:\nAn invariant is a conjunction of upper bounds on clocks and differences between clocks, where the bound is given by an integer expression, and clock rates. A guard is a conjunction of bounds (both upper and lower) on clocks and differences between clocks, where the bound is given by an integer expression. A constraint is any boolean combination (involving negation, conjunction, disjunction and implication) of bounds on clocks and differences between clocks, where the bound is given by an integer expression. In addition, any of the three expressions can contain expressions (including disjunctions) over integers, as long as invariants and guards are still conjunctions at the top-level. The full constraint language is only allowed in the requirement specification language.\nOut of Range Errors and Invalid Evaluations An evaluation of an expression is invalid if out of range errors occur during evalution. This happens in the following situations:\nDivision by zero. Shift operation with negative count. Out of range assignment. Out of range array index. Assignment of a negative value to a clock. Function calls with out of range arguments. Function calls with out of range return values. In case an invalid evaluation occurs during the computation of a successor, i.e., in the evaluation of a guard, synchronisation, assignment, or invariant, then the verification is aborted.\nQuantifiers An expression forall (ID : Type) Expr evaluates to true if Expr evaluates to true for all values ID of the type Type. An expression exists (ID : Type) Expr evaluates to true if Expr evaluates to true for some value ID of the type Type. In both cases, the scope of ID is the inner expression Expr, and Type must be a bounded integer or a scalar set.\nExample The following function can be used to check if all elements of the boolean array a have the value true.\nbool alltrue(bool a[5]) { return forall (i : int[0,4]) a[i]; } Sum An expression sum (ID : Type) Expr evaluates to an integer and is equal to the sum of the expressions evaluated with ID ranging over the given type argument. Boolean or state predicates (in TCTL expressions only) are accepted but not clock constraints. The expressions must be side-effect free. The type must be a bounded integer or a scalar set.\nMITL Expressions Statistical model checking (SMC) supports the full logic of weighted metric interval temporal logic (MITL). The syntax of MITL expressions is defined by the grammar for MITLExpression.\nMITLExpression = BExpr | (MITLExpression \u0026amp;\u0026amp; MITLExpression) | (MITLExpression || MITLExpression) | (MITLExpression \u0026#39;U\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (MITLExpression \u0026#39;R\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;X\u0026#39; MITLExpression) | (\u0026#39;\u0026lt;\u0026gt;\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;[]\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression); BExpr describes a Boolean expression over clocks, variables, and locations. See rail road diagram of entire MITLExpression syntax: Floating Point Type Support Statistical model checking (SMC) supports double precision floating point type double. The clock variables also have floating point values in SMC. Symbolic and statistical model checking can be applied on the same model provided that double and hybrid clock type variables do not influencing the model logic, i.e. they cannot be used in guard and invariant constraints (but can be used in ODE expressions).\nThe following is the list of builtin floating point functions (mostly imported from C math library, hence the C math manual can be consulted for more details):\nint abs(int) absolute value of integer argument. double fabs(double) absolute value of double argument. double fmod(double x, double y) remainder of the division opration x/y. double fma(double x, double y, double z) computes x*y+z as if to infinite precision. double fmax(double x, double y) the larger of the two arguments. double fmin(double x, double y) the smaller of the two arguments. double exp(double x) Euler\u0026rsquo;s number raised to the given power: ex. double exp2(double x) 2 raised to the given power: 2x. double expm1(double x) Euler\u0026rsquo;s number raised to the given power minus 1: ex-1. double ln(double x) logarithm to the base of Euler\u0026rsquo;s number: loge(x). double log(double x) logarithm to the base of 10 log10(x) (this is different from C library, kept for backward compatibility). double log10(double x) logarithm to the base of 10: log10(x). double log2(double x) logarithm to the base of 2: log2(x). double log1p(double x) logarithm to the base of Euler\u0026rsquo;s number with argument plus 1: loge(1+x). double pow(double x, int y) raises to the specified integer power xy. double pow(double x, double y) raises to the specified floating point power xy. double sqrt(double x) computes a square root of x. double cbrt(double x) computes cubic root of x. double hypot(double x, double y) computes a hypotenuse of the right triangle using Pythogoras theorem: sqrt(x2+y2). double sin(double x) sine of an angle x in radians. double cos(double x) cosine of an angle x in radians. double tan(double x) tangent of an angle x in radians. double asin(double x) arc sine in radians. double acos(double x) arc cosine in radians. double atan(double x) arc tangent in radians. double atan2(double y, double x) arc tangent of the ratio y/x in radians. double sinh(double x) hyperbolic sine: (exp(x)-exp(-x))/2. double cosh(double x) hyperbolic cosine: (exp(x)+exp(-x))/2. double tanh(double x) hyperbolic tangent: (exp(x)-exp(-x))/(exp(x)+exp(-x)). double asinh(double x) inverse hyperbolic sine. double acosh(double x) inverse hyperbolic cosine. double atanh(double x) inverse hyperbolic tangent. double erf(double x) Gauss error function (special non-elementary function of sigmoid). double erfc(double x) complement of a Gauss error function. double tgamma(double x) absolute value of the Gamma function (an extension of a factorial function Γ(n)=(n-1)!). double lgamma(double x) natural logarithm of the Gamma function. double ceil(double x) the ceiling function, the smallest integer value not less than x. double floor(double x) the floor function, the largest integer value not greater than x. double trunc(double x) nearest integer not greater in magnitude than x. double round(double x) nearest integer value to x rounding halfway cases away from zero. int fint(double x) converts floating point value into integer (like trunc(), except returns an integer). double ldexp(double x, int y) multiplies by a specified power of two: x*2y. int ilogb(double x) extracts unbiased exponent: trunc(log2(x+1)). double logb(double x) extracts unbiased exponent: trunc(log2(x+1)). double nextafter(double from, double to) a next representable floating point value of from in the direction of to. double copysign(double x, double y) floating point value with magnitude of x and sign of y. bool signbit(double x) true if the argument x is negative. double random(double max) pseudo random number distributed uniformly over the range [0, max). double normal(double mean, double sd) pseudo random number according to Normal (Gaussian) distribution for a given mean and standard deviation sd (until Stratego-10). double random_normal(double mean, double sd) pseudo random number distributed according to Normal (Gaussian) distribution for a given mean and standard deviation sd (since Stratego-10). double random_poisson(double lambda) pseudo random number according to Poisson distribution for a given lambda expected number of occurances (since Stratego-10). double random_arcsine(double from, double till) pseudo random number according to Arcsine distribution over the range [from, till] (since Stratego-10). double random_beta(double alpha, double beta) pseudo random number distributed according to Beta distribution for alpha and beta shape parameters (since Stratego-10). double random_gamma(double shape, double scale) pseudo random number distributed according to Gamma distribution for the given shape and scale parameters (since Stratego-10). double random_tri(double from, double mode, double till) pseudo random number according to Triangular distribution over the range [from, till] with the given mode (since Stratego-10). double random_weibull(double shape, double scale) pseudo random number according to Weibull distribution for the given shape and scale parameters (since Stratego-10). A few common constants and types can be declared as follows (built-in since Stratego-10):\nconst int INT8_MIN = -128; const int INT8_MAX = 127; const int UINT8_MAX = 256; const int INT16_MIN = -32768; const int INT16_MAX = 32767; const int UINT16_MAX = 65535; const int INT32_MIN = -2147483648; const int INT32_MAX = 2147483647; typedef int[INT8_MIN, INT8_MAX] int8_t; typedef int[0, UINT8_MAX] uint8_t; typedef int[INT16_MIN, INT16_MAX] int16_t; typedef int[0, UINT16_MAX] uint16_t; typedef int[INT32_MIN, INT32_MAX] int32_t; const double FLT_MIN = 1.1754943508222875079687365372222456778186655567720875e-38; const double FLT_MAX = 340282346638528859811704183484516925440.0; const double DBL_MIN = 2.2250738585072013830902327173324040642192159804623318e-308; const double DBL_MAX = 1.79769313486231570814527423731704356798070567525845e+308; const double M_PI = 3.141592653589793115997963468544185161590576171875; // pi const double M_PI_2 = 1.5707963267948965579989817342720925807952880859375; // pi/2 const double M_PI_4 = 0.78539816339744827899949086713604629039764404296875; // pi/4 const double M_E = 2.718281828459045090795598298427648842334747314453125; // e const double M_LOG2E = 1.442695040888963387004650940070860087871551513671875; // log_2(e) const double M_LOG10E = 0.43429448190325181666793241674895398318767547607421875; // log_10(e) const double M_LN2 = 0.69314718055994528622676398299518041312694549560546875; // log_e(2) const double M_LN10 = 2.30258509299404590109361379290930926799774169921875; // log_e(10) const double M_1_PI = 0.31830988618379069121644420192751567810773849487304688; // 1/pi const double M_2_PI = 0.63661977236758138243288840385503135621547698974609375; // 2/pi const double M_2_SQRTPI = 1.1283791670955125585606992899556644260883331298828125; // 2/sqrt(pi) const double M_SQRT2 = 1.4142135623730951454746218587388284504413604736328125; // sqrt(2) const double M_SQRT1_2 = 0.70710678118654757273731092936941422522068023681640625; // sqrt(1/2) "},{"uri":"/language-reference/system-description/declarations/external-functions/","title":"External Functions","tags":[],"description":"","content":" The external functions are supported since Uppaal Stratego version 4.1.20-7, or Uppaal version 5.0 or later.\nExternal Functions is an expert user feature and requires a high-level understanding of dynamic library loading and linking.\nThe feature is supported on Linux and experimental on Windows and macOS.\nThe external function calls must be deterministic: for any argument values, the function should produce the same result at any time when called with the same values.\nFor example, side-effect-free (or free) functions, which do not depend on static variables, are deterministic.\nMemoization is allowed.\nExternal Functions can be declared alongside other declaratios. External functions are local to the current scope, defined by the grammar:\nExternDecl = \u0026#39;import\u0026#39; Path \u0026#39;{\u0026#39; [FwdDeclList] \u0026#39;}\u0026#39; FwdDeclList = FwdDecl \u0026#39;;\u0026#39; | FwdDeclList FwdDecl \u0026#39;;\u0026#39; FwdDecl = [ID \u0026#39;=\u0026#39;] Type ID \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; Path is a double-quoted (using \u0026quot;) character sequence (string) denoting a file path to the library placed on the same computer as the used engine (server or verifyta).\nNote that the backslash (\\) character in (Windows) paths needs to be either escaped with another backslash or replaced with the forwardslash (/), i.e. \\ should be replaced with either \\\\ or /. For example, \u0026quot;C:\\libexternal.dll\u0026quot; should be written as \u0026quot;C:\\\\libexternal.dll\u0026quot; or \u0026quot;C:/libexternal.dll\u0026quot;. The following code will load the external libary libexternal.so from the path /home/user/lib and import the functions get_number, set_number and is_the_world_safe. The function is_the_world_safe will be imported with the name is_safe.\nEven though Uppaal will attempt to locate the library in several default paths, we recommend using a fully qualified path to the library file.\nIf you are using integers in external function, we recommend defining a full integer range in order to avoid Uppaal int range ([-32768,32767]) errors.\nconst int INT32_MIN = -2147483648; // not needed since Stratego 4.1.20-11 const int INT32_MAX = 2147483647; // not needed since Stratego 4.1.20-11 typedef int[INT32_MIN,INT32_MAX] int32_t; // not needed since Stratego 4.1.20-11 import \u0026#34;/home/user/lib/libexternal.so\u0026#34; { int32_t get_number(); void set_number(int32_t n); int32_t get_sqrt(int32_t n); is_safe = bool is_the_world_safe(); }; Type Conversion and Restrictions The types transfarable between Uppaal and external functions are curretly limited to bool, int, double, clock, chan, ptr_t and string. Omitting complex types such as structs and nested data structures. Only single-dimentional arrays are supported on only mutable types; arrays of chan and strings are not currently supported.\nThe following table summarizes the current support:\nUPPAAL Type C Type By Value Return Array bool bool x x x int int32_t x x x double double x x x clock double x chan const char* ptr_t size_t x x x string const char* \u0026lt;type\u0026gt;[] \u0026lt;type\u0026gt; A violation of a range of a bounded integer (either pass-by-reference or return) will cause a runtime error.\nResource Initialization and Release The library is loaded during document parsing and the library can be instructed to initialize and release its resources using Special Functions.\nDefining External Library An external library can be compiled from C or C++ code and linked into a shared library. Uppaal uses C symbol name mangling, so C++ compiler needs to be instructed to export \u0026quot;C\u0026quot; names, whereas C compiler does it by default.\nThe following C/C++ code implements the library functions used for the example above.\nexternal.h:\n#ifndef LIBRARY_EXTERNAL_H #define LIBRARY_EXTERNAL_H #ifdef __cplusplus extern \u0026#34;C\u0026#34; { // tells C++ compiler to use C symbol name mangling (C compiler ignores) #endif // __cplusplus int get_number(); void set_number(int n); int get_sqrt(int n); bool is_the_world_safe(); #ifdef __cplusplus } // end of \u0026#34;C\u0026#34; symbol name mangling #endif // __cplusplus #endif // LIBRARY_EXTERNAL_H external.cpp:\n#include \u0026#34;external.h\u0026#34; #include \u0026lt;cmath\u0026gt; static int number = 42; // internal state, be careful #ifdef __cplusplus extern \u0026#34;C\u0026#34; { // tells C++ compiler to use C symbol name mangling (C compiler ignores) #endif // __cplusplus int get_number() { // is not free from side-effects, when set_number is used return number; } void set_number(int n) { // the state needs to be synchronized with the model state number = n; } int get_sqrt(int n) { return std::sqrt(n); } bool is_the_world_safe() { return true; } #ifdef __cplusplus } // end of \u0026#34;C\u0026#34; symbol name mangling #endif // __cplusplus Execute the following shell commands to compile the source external.cpp into object file external.o and then link external.o into a shared library libexternal.so:\ng++ -std=c++17 -Wpedantic -Wall -Wextra -fPIC -g -Og -o external.o -c external.cpp gcc -shared -o libexternal.so external.o For optimized builds replace -g Og with -DNDEBUG -O3 in the above command and strip the details with strip libexternal.so.\nFor more library examples please visit uppaal-libs repository.\nDebugging Inspect the library file using file /home/user/lib/libexternal.so:\nlibexternal.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, ... Inspect the dynamic library dependencies ldd /home/user/lib/libexternal.so:\nstatically linked This means that the library is linked with everything it needs and is self-contained, it does not require any additional libraries. Alternatively, one may see a list of required libraries and where the library loader (ld-linux.so) can (not) find them.\nInspect the exported dynamic symbols of the library using objdump -T /home/user/lib/libexternal.so:\nlibexternal.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 w D *UND* 0000000000000000 __cxa_finalize 0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable 0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 w D *UND* 0000000000000000 __gmon_start__ 0000000000001120 g DF .text 0000000000000006 is_the_word_safe 0000000000001100 g DF .text 000000000000000a get_number 0000000000004008 g DO .data 0000000000000004 number 0000000000001110 g DF .text 000000000000000a set_number Similarly using nm -D /home/user/lib/libexternal.so:\nw __cxa_finalize 0000000000001100 T get_number w __gmon_start__ 0000000000001120 T is_the_word_safe w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000000000004008 D number 0000000000001110 T set_number (GNU compiler exports all symbols by default, hence number can be part of the exported symbol listing)\nOne can also inspect the library loading among all OS kernel calls, for example strace verifyta external.xml:\n... read(3, \u0026#34;\u0026lt;?xml version=\\\u0026#34;1.0\\\u0026#34; encoding=\\\u0026#34;ut\u0026#34;..., 4096) = 1332 getcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/lib/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = 4 read(4, \u0026#34;\\177ELF\\2\\1\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0\u0026gt;\\0\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\u0026#34;..., 832) = 832 newfstatat(4, \u0026#34;\u0026#34;, {st_mode=S_IFREG|0750, st_size=13920, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f30277e5000 mmap(0x7f30277e6000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f30277e6000 mmap(0x7f30277e7000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f30277e7000 mmap(0x7f30277e8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f30277e8000 close(4) = 0 mprotect(0x7f30277e8000, 4096, PROT_READ) = 0 read(3, \u0026#34;\u0026#34;, 4096) = 0 close(3) = 0 ... Here, one can see verifyta requesting for current directory (getcwd), and then opening /home/user/libexternal.so file (openat).\nAlternatively, one may find errors when some library is missing or a path is wrong:\ngetcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/wrong/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Errors when some symbol is not found (wrong function name):\ngetcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/lib/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = 4 read(4, \u0026#34;\\177ELF\\2\\1\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0\u0026gt;\\0\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\u0026#34;..., 832) = 832 newfstatat(4, \u0026#34;\u0026#34;, {st_mode=S_IFREG|0750, st_size=15264, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 16408, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f988f7d5000 mmap(0x7f988f7d6000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f988f7d6000 mmap(0x7f988f7d7000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f988f7d7000 mmap(0x7f988f7d8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f988f7d8000 close(4) = 0 mprotect(0x7f988f7d8000, 4096, PROT_READ) = 0 futex(0x7f988f6791f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 read(3, \u0026#34;\u0026#34;, 4096) = 0 close(3) = 0 write(2, \u0026#34;external.xml\u0026#34;, 12external.xml) = 12 write(2, \u0026#34;:\u0026#34;, 1:) = 1 write(2, \u0026#34;/nta/declaration\u0026#34;, 16/nta/declaration) = 16 write(2, \u0026#34;:\u0026#34;, 1:) = 1 write(2, \u0026#34;5\u0026#34;, 15) = 1 write(2, \u0026#34;: [\u0026#34;, 3: [) = 3 write(2, \u0026#34;error\u0026#34;, 5error) = 5 write(2, \u0026#34;] \u0026#34;, 2] ) = 2 write(2, \u0026#34;/home/user/lib/libexternal.so: \u0026#34;..., 68/home/user/lib/libexternal.so: undefined symbol: is_the_word_safe.) = 68 If the library implementation crashes, then one may try and debug it by loading verifyta with the specified model into a debugger or Integrated Development Environmnet (IDE) like Netbeans or Clion.\nIn order to step through the library calls, make sure that the library is compiled and linked with debug information (using -g -Og compiler arguments).\nAlternatively, we strongly suggest to use unit tests to call your library and inspect the behavior in the debugger or IDE, for example:\nexternal_test.cpp\n#include \u0026#34;external.h\u0026#34; #include \u0026lt;cassert\u0026gt; int main() { int seven = get_sqrt(50); assert(seven == 7); int two = get_sqrt(-4); assert(two == 2); } Compile external_test.cpp into external_test against libexternal.so in /home/user/lib and run:\ng++ -std=c++17 -Wpedantic -Wall -Wextra -g external_test.cpp -L/home/user/lib -lexternal -o external_test LD_LIBRARY_PATH=/home/user/lib ./external_test The test above may produce the following output:\nexternal_test: external_test.cpp:9: int main(): Assertion `two == 2\u0026#39; failed. Aborted (core dumped) Which means that the assertion two == 2 on line 9 of external_test.cpp is false.\nThe test above can be (re-)run using gdb debugger:\nLD_LIBRARY_PATH=/home/user/lib gdb ./external_test Reading symbols from ./external_test... (gdb) r Starting program: /tmp/uppaal-lib/external_test [Thread debugging using libthread_db enabled] Using host libthread_db library \u0026#34;/lib/x86_64-linux-gnu/libthread_db.so.1\u0026#34;. external_test: external_test.cpp:8: int main(): Assertion `two == 2\u0026#39; failed. Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=\u0026lt;optimized out\u0026gt;, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=\u0026lt;optimized out\u0026gt;, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff7d61d2f in __pthread_kill_internal (signo=6, threadid=\u0026lt;optimized out\u0026gt;) at ./nptl/pthread_kill.c:78 #2 0x00007ffff7d12ef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7cfd472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007ffff7cfd395 in __assert_fail_base (fmt=0x7ffff7e71a70 \u0026#34;%s%s%s:%u: %s%sAssertion `%s\u0026#39; failed.\\n%n\u0026#34;, assertion=assertion@entry=0x55555555602c \u0026#34;two == 2\u0026#34;, file=file@entry=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=line@entry=8, function=function@entry=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:92 #5 0x00007ffff7d0bdf2 in __GI___assert_fail (assertion=0x55555555602c \u0026#34;two == 2\u0026#34;, file=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=9, function=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:101 #6 0x00005555555551c7 in main () at external_test.cpp:8 (gdb) up #1 0x00007ffff7d61d2f in __pthread_kill_internal (signo=6, threadid=\u0026lt;optimized out\u0026gt;) at ./nptl/pthread_kill.c:78 78 in ./nptl/pthread_kill.c (gdb) #2 0x00007ffff7d12ef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 26 ../sysdeps/posix/raise.c: No such file or directory. (gdb) #3 0x00007ffff7cfd472 in __GI_abort () at ./stdlib/abort.c:79 79 ./stdlib/abort.c: No such file or directory. (gdb) #4 0x00007ffff7cfd395 in __assert_fail_base (fmt=0x7ffff7e71a70 \u0026#34;%s%s%s:%u: %s%sAssertion `%s\u0026#39; failed.\\n%n\u0026#34;, assertion=assertion@entry=0x55555555602c \u0026#34;two == 2\u0026#34;, file=file@entry=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=line@entry=8, function=function@entry=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:92 92 ./assert/assert.c: No such file or directory. (gdb) #5 0x00007ffff7d0bdf2 in __GI___assert_fail (assertion=0x55555555602c \u0026#34;two == 2\u0026#34;, file=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=8, function=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:101 101 in ./assert/assert.c (gdb) #6 0x00005555555551c7 in main () at external_test.cpp:9 9 assert(two == 2); (gdb) p two $1 = -2147483648 (gdb) In the log above, one can see that the binary is loaded from external_test.\nThe program is run by command r, then a crash is observed due to failed assertion two == 2.\nA call stack trace is printed using command bt, in particular it contains main () from our source file external_test.cpp.\nThen the debugger is instructed to go up in the call stack multiple times by issuing a command up and then blank command (simply enter, which repeats the last command).\nThen at the main function call, the code line assert(two == 2); is highlighted.\nAnd finally the value of variable two is printed using command p two. The value is -2147483648 which is not as expected, hence the assertion failed.\nIt is also possible to attach gdb to an already running process (like verifyta or Uppaal engine server), set break points and watches.\n"},{"uri":"/language-reference/system-description/system-definition/gantt-chart/","title":"Gantt Chart","tags":[],"description":"","content":"A Gantt chart, commonly used in project management, is a bar chart that shows activities displayed against time. On the left of the chart is a list of the activities and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of the bar reflect the start date, duration and end date of the activity.\nIn UPPAAL Gantt Charts are used to automatic visualize traces in Concrete Simulator. One needs to specify the list of activities and for each activity, what the different colored parts of the bar should reflect.\nThe Gantt Chart specification is placed after the system definition. The syntax is defined by the following grammar:\nGanttDecl ::= \u0026#39;gantt {\u0026#39; GanttDef \u0026#39;}\u0026#39; GanttDef ::= \u0026#39;\u0026#39; | GanttDef NonTypeId GanttArgs \u0026#39;:\u0026#39; GanttExprList \u0026#39;;\u0026#39; GanttArgs ::= \u0026#39;\u0026#39; | \u0026#39;(\u0026#39; GanttDeclSelect \u0026#39;)\u0026#39; GanttDeclSelect ::= [Id] \u0026#39;:\u0026#39; [Type] | GanttDeclSelect \u0026#39;,\u0026#39; Id \u0026#39;:\u0026#39; Type GanttExprList ::= GanttExpr | GanttExprList \u0026#39;,\u0026#39; GanttExpr GanttExpr ::= [Expression] \u0026#39;-\u0026gt;\u0026#39; [Expression] | \u0026#39;for (\u0026#39; GanttEntrySelect \u0026#39;)\u0026#39; [Expression] \u0026#39;-\u0026gt;\u0026#39; [Expression] GanttEntrySelect ::= Id \u0026#39;:\u0026#39; Type | GanttEntrySelect \u0026#39;,\u0026#39; Id \u0026#39;:\u0026#39; Type The first part of GanttDef (the one before the colon) specifies the list of activities. The second part (the one after the colon) specifies for each activity, what the bar should reflect. An instance of GanttExpr consists of two expressions. The one before -\u0026gt; is evaluated to a boolean value. If it is evaluated to true, the expression after -\u0026gt; will be evaluated to an integer. Note that this integer is not necessarily a constant. The integer will be map to a color (e.g. 0 will be map to red and 1 to green), which is the color of the bar when the expression is evaluated to true. GanttDeclSelect and for (...) are to be considered as syntax shortcuts rather than constructs.\nExamples Sample color definitions:\nconst int C_RED = 0; const int C_GREEN = 1; const int C_BLUE = 2; const int C_PURPLE = 3; const int C_ORANGE = 5; const int C_YELLOW = 6; const int C_CYAN = 9; gantt { Red: true -\u0026gt; C_RED; Colors(i:int[0,32]): true -\u0026gt; i; } Scheduling gantt { Task(i : pid_t): Task(i).Ready -\u0026gt; 1, Task(i).Running -\u0026gt; 2, Task(i).Blocked -\u0026gt; 3, Task(i).Error -\u0026gt; 0, for(j : sid_t) Task(i).sema[j] -\u0026gt; 6; Scheduler: len==0 -\u0026gt; 0, len\u0026gt;0 -\u0026gt; 1; } Train Gate gantt { Xxxx: Train(0).Cross -\u0026gt; 0, Train(1).Cross -\u0026gt; 1, Train(2).Cross -\u0026gt; 2; Gate: true -\u0026gt; Gate.len; } Once declared, the Gantt chart is rendered in Concrete Simulator when enabled in the menu View \u0026gt; Gantt Chart.\n"},{"uri":"/toolsandapi/javaapi/","title":"Java API","tags":[],"description":"","content":"UPPAAL models can be created, loaded, saved, simulated and checked using libs/model.jar library. There is also javadoc included libs/model-javadoc.jar.\nA demonstrating example is included in the demo/ModelDemo.java file.\n"},{"uri":"/language-reference/system-description/parameters/","title":"Parameters","tags":[],"description":"","content":"Templates and functions are parameterised. The syntax for parameters is defined by the grammar for Parameters:\nParameters ::= [ Parameter (\u0026#39;,\u0026#39; Parameter)* ] Parameter ::= [Type] [ \u0026#39;\u0026amp;\u0026#39; ] [ID] [ArrayDecl]* In contrast to global and local declarations, the parameter list should not be terminated by a semicolon.\nCall by Reference and Call by Value Parameters can be declared to have either call-by-value or call-by-reference semantics. The syntax is taken from C++, where the identifier of a call-by-reference parameter is prefixed with an ampersand in the parameter declaration. Call-by-value parameters are not prefixed with an ampersand.\nClocks and channels must always be reference parameters.\nNote: Array parameters must be prefixed with an ampersand to be passed by reference, this does not follow the C semantics.\nExamples P(clock \u0026amp;x, bool bit) process template P has two parameters: the clock x and the boolean variable bit. Q(clock \u0026amp;x, clock \u0026amp;y, int i1, int \u0026amp;i2, chan \u0026amp;a, chan \u0026amp;b) process template Q has six parameters: two clocks, two integer variables (with default range), and two channels. All parameters except i1 are reference parameters. "},{"uri":"/gui-reference/concrete-simulator/process/","title":"Process Panel","tags":[],"description":"","content":"The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.\nClicking inside a process box with the right mouse button opens a pop-up menu with the following items:\nZoom In: increases the zoom of the process, Zoom Out: decreases the zoom of the process, Hide: hides the process, Export: opens a file dialog for saving the process in encapsulated postscript format. "},{"uri":"/language-reference/query-semantics/smc_queries/","title":"Semantics of the Statistical Queries","tags":[],"description":"","content":"UPPAAL can estimate the probability of expression values statistically. There are four types of statistical properties: quantitative, qualitative, comparison and probable value estimation.\nSee also Syntax of Statistical Queries.\nSimulation \u0026#39;simulate\u0026#39; \u0026#39;[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; [ \u0026#39;:\u0026#39; [ SATRUNS \u0026#39;:\u0026#39; ] Expression ] The simulation query collects the valuation of the specified list of expressions over the time, cost or action-transitions of the simulated run. The simulation runs can be filtered by a state expression after the colon (\u0026rsquo;:\u0026rsquo;) and the number of satisfying runs can be limited by positive integer using SMCBounds and SATRUNS. If the filtering expression is provided then the result also includes a probability confidence interval similar to Probability Estimation below.\nProbability Estimation (Quantitative Model Checking) \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; Quantitative query estimates the probability of a path expression being true given that the predicate in probability brackets is true. Intuitively the model exploration is bounded by an expression in the brackets: it can be limited by setting the bound on absolute model time, a clock value, or the number of steps (discrete transitions).\nThe result is an estimated probability confidence interval (CI), where the level of significance (probability that CI does not include the actual probability) is controlled by α and the width is controlled by ε in the statistical parameters. In addition the and a number of histograms over the values of the variable specified in the probability brackets. Note that histograms omit runs that do not satisfy the property.\nThe number of runs can be specified by the optional RUNS argument in the SMCBounds. If the argument is absent, then the number of runs is determined by a sequential CI estimation algorithm.\nSee also: CI Estimation\nHypothesis Testing (Qualitative Model Checking) \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; (\u0026#39;\u0026lt;=\u0026#39;|\u0026#39;\u0026gt;=\u0026#39;) ProbNumber Hypothesis testing checks whether the probability of a property is less or greater than specified bound. The query is more efficient than probability estimation as it is one sided and requires fewer simulations to attain the same level of significance.\nProbability Comparison \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; **\u0026#39;\u0026gt;=\u0026#39;** \u0026#39;Pr[\u0026#39; ( Variable | \u0026#39;#\u0026#39; ) \u0026#39;\u0026lt;=\u0026#39; CONST \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; Compares two probabilities indirectly without estimating them.\nValue Estimation \u0026#39;E[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; (\u0026#39;min:\u0026#39;|\u0026#39;max:\u0026#39; Expression \u0026#39;)\u0026#39; Estimates the value of an expression by running a given number of simulations.\nFull Weighted MITL MITLQuery = \u0026#39;Pr\u0026#39; MITLExpression MITLExpression = BExpr | (MITLExpression \u0026amp;\u0026amp; MITLExpression) | (MITLExpression || MITLExpression) | (MITLExpression \u0026#39;U\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (MITLExpression \u0026#39;R\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;X\u0026#39; MITLExpression) | (\u0026#39;\u0026lt;\u0026gt;\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;[]\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression); BExpr describes a Boolean expression over clocks, variables, and locations. See rail road diagram of entire MITLExpression syntax:\nThe exact evaluation of the probability that a run satisfies a given weighted MITL formula.\nExamples Pr[\u0026lt;=100] (\u0026lt;\u0026gt; Train.Cross) estimates the probability of the process Train reaching the location Cross within 100 model time units. The tool will produce a number of histograms over model time, like probability density distribution of Train.Cross becoming true over model time, thus allowing to inspect what the most likely moment in time is when the train arrives at crossing. Pr[cost\u0026lt;=1000] (\u0026lt;\u0026gt; Plane.Landing) estimates the probability of the process Plane reaching the location Landing within 1000 cost units where clock variable cost has various rates in different locations. The tool will produce a number of histograms over the cost values, like a probability density distribution of Plane.Landing becoming true over cost, thus allowing to inspect what the most likely cost is when the plane lands. "},{"uri":"/gui-reference/symbolic-simulator/simulation-control/","title":"Simulation Control","tags":[],"description":"","content":"The simulation control is the left panel of the simulator. It is used to control the simulation and to select the (symbolic) state or transition to be visualized in the other two panels of the simulator. The control panel is divided in two parts:\nThe upper part is used for performing step-by-step simulation. A list view displays the enabled transitions, with the currently selected transition highlighted. Pressing the Next-button causes the simulated system to take the selected transition. The Reset-button is used to reset the simulated system to its initial state.\nThe lower part of the control panel has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.\nThe six buttons below the trace view have the following semantics:\nPrev: highlights the element immediately preceding the current selection (if any) in the trace. Next: highlights the element immediately following the current selection (if any) in the trace. Replay: replays the trace starting from the currently selected element. Open: opens a file dialog for loading a trace from file. Save: opens a file dialog for saving the current trace on file. The valid file extension is \u0026ldquo;xtr\u0026rdquo;. When no file extension is provided, it will be automatically appended. Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions. The slider at the bottom of the control panel is used to control the speed used when traces are replayed and when random simulation is performed.\nKeyboard Shortcuts Key Shortcut to Z Move selection up in the enabled transitions list view. X Move selection down in the enabled transitions list view. Q Correspond to the button Prev. A Correspond to the button Next. P Correspond to the button Replay. R Correspond to the button Random. F Highlights the first element in the trace. L Highlights the last element in the trace. Toggle selection of an enabled transition. Follow the selected enabled transition. "},{"uri":"/language-reference/query-syntax/strategy_queries/","title":"Syntax of Strategy Queries","tags":[],"description":"","content":"Strategy Queries Strategy queries allow store, load, reuse and refine the strategies by assigning names to them.\nAssignQuery ::= \u0026#39;strategy\u0026#39; StrategyName \u0026#39;=\u0026#39; AssignableQuery AssignableQuery ::= ControlQuery | LearningQuery | \u0026#39;loadStrategy\u0026#39; Features \u0026#39;(\u0026#39; Path \u0026#39;)\u0026#39; NonAssignableQuery ::= SymbolicQuery | SMCQuery | \u0026#39;saveStrategy\u0026#39; \u0026#39;(\u0026#39; Path \u0026#39;,\u0026#39; StrategyName \u0026#39;)\u0026#39; StrategyName indicates the name of a strategy. Path is a double-quoted (using \u0026quot;) character sequence (string) denoting a file path on the same computer as the used engine (server or verifyta).\nNote that the backslash (\\) character in (Windows) paths needs to be either escaped with another backslash or replaced with the forwardslash (/), i.e. \\ should be replaced with either \\\\ or /. See rail road diagram of AssignableQuery in Query overview.\nExamples strategy Safe = A[] safe computes a safety/permissive strategy over the timed game model and stores it under the name Safe. A[] good under Safe checks that the predicate good is always satisfied when the player/controller sticks to actions permitted by Safe strategy. E\u0026lt;\u0026gt; goal under Safe checks that the goal state predicate is eventually satisfied when the player/controller uses Safe strategy. strategy SafeCheap = minE(cost)[\u0026lt;=10] {i,j} -\u0026gt; {d,f} : \u0026lt;\u0026gt; t\u0026gt;=10 under Safe refines Safe strategy into SafeCheap by minimizing the expected value of cost expression. saveStrategy(\u0026quot;folder/file.json\u0026quot;, Safe) writes Safe strategy to the file with path folder/file.json. strategy Safe = loadStrategy{i,j}-\u0026gt;{d,f}(\u0026quot;folder/file.json\u0026quot;) reads the strategy from the file with path folder/file.json and stores it under the name Safe. "},{"uri":"/gui-reference/system-editor/","title":"System Editor","tags":[],"description":"","content":"The system editor is used to create and edit the system to be analysed. A system description is defined by a set of process templates (possibly with local declarations), global declarations, and a system definition.\nIn this help section we describe how to use the left panel of the editor, called the navigation tree, how to draw automata with the editor, and where to place declarations. The system description language used in UPPAAL is described in the Language Reference section.\n"},{"uri":"/toolsandapi/","title":"Tools & API","tags":[],"description":"","content":"Chapter 1 Tools \u0026amp; API "},{"uri":"/gui-reference/symbolic-simulator/variables/","title":"Variables Panel","tags":[],"description":"","content":"The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.\nThe data variable values are always shown as integers. The clock values are shown symbolically as a conjunction of clock guards of lower and upper bounds on individual clocks or differences between pairs of clocks (see Expressions section for more information on clock guards). The possible clock values of the associated state (or transition) are all possible solutions to the conjunction of all clock constraints. The symbols \u0026ldquo;[\u0026rdquo; and \u0026ldquo;]\u0026rdquo; are used for closed intervals and \u0026ldquo;(\u0026rdquo; and \u0026ldquo;)\u0026rdquo; for open intervals in the usual way.\nIf the selected element in the simulation control panel is a state, the variables panel shows the symbolic values of the state (in normal black color). If the selected element is a transition, the shown symbolic values are those of the immediately preceding state satisfying the guard(s) of the transition (shown in blue color).\nNote: variables can be hidden and displayed using the \u0026ldquo;Variables\u0026hellip;\u0026rdquo; item in the View menu. The representation of the clock constraints can also be changed from this menu, using the \u0026ldquo;Full DBM\u0026rdquo; item. When \u0026ldquo;Full DBM\u0026rdquo; is checked a constraint is shown for each pair of clocks, otherwise a minimum set of constraints is shown. The minimum set of constraints is such that all constraints that are in the full DBM but not in the minimum set can be derived from constraints in the minimum set.\n"},{"uri":"/gui-reference/menu-bar/view/","title":"View Menu","tags":[],"description":"","content":"The view menu is used to modify the appearance of the system currently shown in the system editor and the simulator. The items are:\nZoom: shows a sub menu with fixed zoom values, zoom to fit, and itemes for zooming in, out, or to normal size. A change in the zoom value affects the templates the editor or the processes in the simulator (if one of the tools is active).\nLabels: shows a sub menu from which one can select which type of labels should be shown in the drawing area. Even when hidden, all labels can be seen in the tooltip of locations and edges.\nShow Grid: the drawing grid is shown when this item is checked.\nSnap to Grid: makes new drawing objects (such as locations, nails, and labels) align to the snap grid. The size of the snap grid is related to the size of the drawing grid.\nNote: the Snap to Grid option can be used even if the drawing grid is not shown.\nCoarser: increases the distance between the lines in the drawing grid.\nTighter: decreases the distance between the lines in the drawing grid.\nMark Visited highlights the locations and edges traversed by a trace in the simulator process panel.\nShow Coverage shows graphs of location and edge coverage dynamics over the simulated trace in a popup window. The Mark Visited option above enables this menu item.\nReload Simulator: uploads the system currently loaded in the editor, to the simulator and the verifier.\nProcesses: displays a dialog window for hiding and showing processes in the process panel of the simulator.\nVariables: shows a dialog window for hiding and showing variables in the variables panel of the simulator.\nFull DBM: shows all constraints on the clocks in the variables panel of the simulator. If not selected a minimal number of constraints will be shown.\n"},{"uri":"/language-reference/query-semantics/smc_queries/ci_estimation/","title":"Confidence Intervals","tags":[],"description":"","content":"Probability estimation query Pr[\u0026hellip;](\u0026lt;\u0026gt; q) yields a confidence interval (CI) for the probability of the state expression q being true with the confidence level of 1-α. For example, it could be [0.45, 0.55] (95% CI), or could be written as 0.5 ± 0.05 (95% CI), where ε=0.05 and α=0.05.\nThe frequentist interpretation of CI is that there exists a true probability that the state expression q is true and it is included in that confidence interval, but there is a risk α of making an error (the true probability being outside the confidence interval).\nChernoff-Hoeffding bound N=ln(2/α)/(2ε2) provides an intuition that the number of required samples (runs) N is inversely proportional to ε2 and proportional to the ln(1/α). This result assumes that the measurements are sampled from a continuous interval [0,1] which makes it overly conservative. For example, for α=0.05 and ε=0.05 it requires 738 runs irrespective of the actual probability. However, if the samples are constrained to either 0 or 1 and we observe a repetitive sequence of 30 successes we could conclude much earlier with [0.9,1] (95% CI) just by using a statistical rule of three.\nInstead, UPPAAL uses Clopper-Pearson exact method for binomial distribution which samples from {0,1} and provides more precise bounds with fewer runs, especially when the probability is close to 0 or 1.\nIf the number of runs is not specified in the query, then the probability estimation uses Clopper-Pearson algorithm sequentially to determine when to stop generating the simulation runs thus allowing earlier termination. Therefore the number of runs is sensitive to α, ε and also the estimated probability itself. The α and ε parameters are controlled in the statistical parameters of engine options.\nThe following plots show the number of samples (runs) required to estimate the confidence interval using the exact method sequentially for a given α, ε and the true probability (estimating P\u0026gt;0.5 is symmetric to estimating 1-P): For example, for the default parameter values ε=0.05 and α=0.05 the sequential algorithm requires 411 — the highest number of samples (runs) — when the probability is close to 0.5, where the uncertainty is the highest. Whereas the algorithm cannot distinguish the true probabilities ≤ ε (0.05) and thus could terminate much earlier: after 72 runs. Note that the uncertainty of the required runs is the largest when the true probability is close to either 0 or 1.\nThe following plot shows the number of samples (runs) required when the width of the interval is halved to ε=0.025: The following plot shows the number of samples (runs) required when the width of the interval is even more narrow ε=0.01: The following series of plots demonstrates how the estimated confidence interval converges to the true probability P value as more samples are produced:\nNote that occasionally the confidence intervals may overstep and thus exclude the true probability value, which should not happen more often than the specified level of significance α.\nThe following sequence of plots show how the width of the confidence intervals converges as more samples are produced:\nNote that in case of extreme probability value (close to 0 or 1, e.g. P=0.01), repeated observations are more likely and thus they may create false confidence that the probability is extreme (i.e. 0 or 1), but then a single differing observation may disturb the interval size greately and therefore more samples are required than just single sided interval.\nSeveral sequential CI estimation algorithms for binomial proportion are described in the literature below.\nFixed-Width Sequential Confidence Intervals for a Proportion, Jesse Frey. The American Statistician Volume 64, 2010 - Issue 3. doi:10.1198/tast.2010.09140\nExact Group Sequential Methods for Estimating a Binomial Proportion, Zhengjia Chen and Xinjia Chen. Journal of Probability and Statistics, 2013, special issue \u0026ldquo;Adaptive and Sequential Methods for Clinical Trials\u0026rdquo;. doi:10.1155/2013/603297\n"},{"uri":"/extensions/","title":"Extensions","tags":[],"description":"","content":"Chapter 4 Extensions CORA ECDAR UPPAAL Tiga UPPAAL TRON "},{"uri":"/gui-reference/concrete-simulator/sequence-chart/","title":"Message Sequence Chart","tags":[],"description":"","content":"The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).\nIn the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.\n"},{"uri":"/gui-reference/symbolic-simulator/process/","title":"Process Panel","tags":[],"description":"","content":"The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.\nClicking inside a process box with the right mouse button opens a pop-up menu with the following items:\nZoom In: increases the zoom of the process, Zoom Out: decreases the zoom of the process, Hide: hides the process, Export: opens a file dialog for saving the process in encapsulated postscript format. Note: several items in the View menu affect the processes in the process panel. For example, the \u0026ldquo;Processes\u0026hellip;\u0026rdquo; item may be used to hide and show processes.\n"},{"uri":"/language-reference/reserved-keywords/","title":"Reserved Keywords","tags":[],"description":"","content":"The reserved keywords that should not be used as identifier names when defining systems are: chan, clock, double, bool, int, commit, const, urgent, broadcast, init, process, state, invariant, location, guard, sync, assign, system, trans, deadlock, and, or, not, imply, true, false, for, forall, exists, while, do, if, else, return, typedef, struct, rate, before_update, after_update, meta, priority, progress, scalar, select, void, default, string, minE, maxE, Pr.\nThe following keywords are reserved for future use: switch, case, continue, break, enum.\n"},{"uri":"/toolsandapi/socketserver/","title":"Socketserver","tags":[],"description":"","content":"To start a remote server, use the socketserver binary (included for Linux, SunOS and MacOS). To use a remote server, see the section on command line options for the GUI.\nThe socketserver can be executed from the command line using one of the following commands:\nsocketserver [-p] [-s]\nsocketserver -h\nThe available command line options are:\n-h Prints a brief description of the command line options. -p Set port in server mode (default is 2350). -s Set filename of server binary to P2. The socketserver will load the server from the directory where it was invoked, and act as a proxy.\n"},{"uri":"/gui-reference/symbolic-simulator/","title":"Symbolic Simulator","tags":[],"description":"","content":"The simulator is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. In this sense, it provides an inexpensive mean of fault detection prior to verification by the model-checker. The simulator is also used to visualise executions (i.e. symbolic traces) generated by the verifier. Please see the Symbolic Traces section for a brief introduction of the concept.\nThe simulator consist of four panels: the leftmost called simulation control, the middle called variables, the upper right called processes, and the lower right called message sequence chart.\n"},{"uri":"/language-reference/system-description/system-definition/","title":"System Definition","tags":[],"description":"","content":"In the system definition, a system model is defined. Such a model consists of one or more concurrent processes, local and global variables, and channels.\nGlobal variables, channels and functions can be defined in the system definition using the grammar for declarations. Such declarations have a global scope. However, they are not directly accessible by any template, as they are declared after the templates. They are most useful when giving actual arguments to the formal parameters of templates. The declarations in the system definition and in the top-level declarations section are part of the system model.\nThe processes of the system model are defined in the form of a system declaration line, using the grammar for System given below. The system line contains a list of templates to be instantiated into processes. Processes can be prioritised as described in the section on priorities.\nSystem ::= \u0026#39;system\u0026#39; ID ((\u0026#39;,\u0026#39; | \u0026#39;\u0026lt;\u0026#39;) ID)* \u0026#39;;\u0026#39; Templates without parameters are instantiated into exactly one process with the same name as the template. Parameterised templates give rise to one process per combination of arguments, i.e., UPPAAL automatically binds any free template parameters. Any such parameter must be either a call-by-value bounded integer and or a call-by-value scalar. Individual processes can be referenced in expressions using the grammar for Process given below. Notice that this is already covered by the grammar for expressions.\nProcess ::= ID \u0026#39;(\u0026#39; [Arguments] \u0026#39;)\u0026#39; It is often desirable to manually bind some or all formal parameters of a template to actual arguments. This can be done by partial instantiation of templates.\nAny progress measures for the model or Gantt chart are defined after the system line.\nExample In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess P() { state s...; ... } process Q(int[0,3] a) { state t...; ... } system P, Q; This defines a system consisting of five processes named P, Q(0), Q(1), Q(2) and Q(3). Automatic binding of template parameters is very useful in models in which a large number of almost identical processes must be defined, e.g., the nodes of a network in a model of a communication protocol. In order to express that, e.g., all Q processes must be in location s, an expression like forall (i : int[0,3]) Q(i).s suffices.\n"},{"uri":"/gui-reference/menu-bar/tools/","title":"Tools Menu","tags":[],"description":"","content":"The tools menu contains a set of tools useful in the system edtior. The items are:\nCheck Syntax: checks if syntax and types are correct in the edited system. Any found errors and warnings are listed in the lower part of the drawing area of the system editor, and (when applicable) underlinded in the automata. Convert Syntax: assists in convering a system complying with the syntax used in UPPAAL 3.4 to the current syntax. Align to Grid: makes all existing objects of the current template align to the specified drawing grid. Plot Composer: creates a new Plot Composer window to superimpose multiple results from statistical model checking in the Verifier. "},{"uri":"/gui-reference/concrete-simulator/","title":"Concrete Simulator","tags":[],"description":"","content":"The concrete simulator is similar to the symbolic simulation in the sense that it is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. The difference is that the simulation is based on concrete traces, i.e. one can choose a specific time to fire a transition. The tool helps to see at which time a transition can be fired.\nThe concrete simulator consists of the following panels:\nSimulation Control Variables Panel Process Panel Message Sequence Chart Gantt Chart Panel "},{"uri":"/toolsandapi/file-formats/","title":"File Formats","tags":[],"description":"","content":"UPPAAL supports three file formats for models: XML, XTA and TA. XML and XTA files can be loaded and stored via the Open Project, Open System, Save System, and Save System As menus. When saving a file, the file type is determined by the file name extension used. Each format is explained in more details below.\nNotice that the above mentioned file formats are mostly independent from the type of changes made to the syntax between UPPAAL 3.4 and UPPAAL 4.0.\nIn additon to the file formats for models, UPPAAL uses clear text query files for storing queries and the XTR file format for storing traces.\nXML The newest format is XML based and files in this format have the ending .xml. This format supports all features of UPPAAL. Elements like templates, locations, edges and labels are described using tags. This format was introduced in the GUI in version 3.2. As of version 3.4, the XML format is also supported by the verification engine. The GUI uses this format as its native file format. The addition of colors and notes on labels and edges, and the select expresssion on edges in UPPAAL 4.0 has resulted in the addition of a color attribute and two new label types. If these features are not used, the XML files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.\nThe level of abstraction in the format is chosen so that the format is independent of the actual syntax of declarations, invariants, guards, etc. Thus all labels are simply treated as strings without structure. In a GUI, this is very important, since the user might enter arbitrary text into the label fields and the file format must be able to cope with this situation. Before the introduction of the XML format, the XTA format was used. With this format it was not possible to save syntactically incorrect systems, i.e., if the user made a mistake in the syntax of a label it was not possible to save this systems.\nXTA The XTA format was introduced in version 3.0. This format can only reliably store syntactically correct systems. Anonymous locations are not supported by this format (UPPAAL automatically assigns a unique name to anonymous locations when saved to an XTA file). Graphical information (coordinates) about the objects are stored in a separate UGI file, although this is transparent to the user. XTA files use the ending .xta and UGI files the ending .ugi.\nIn UPPAAL 4.0, the XTA format was extended with support for the select expression on edges. The UGI format was extended with support for the color attributes. If these features are not used, the XTA files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.\nTA The TA format is a subset of the XTA format and does not support the template concept nor does it contain any graphical information about the system. UPPAAL can no longer save files in this format, although TA files can still be read.\nQuery files Query files use a clear-text format listing all queries inleaved with comments. The format dates back to UPPAAL 2. Files in this format have the file ending .q.\nTrace files Traces can be stored using the XTR format and files in this format have the file ending .xtr. The format was introduced in UPPAAL 3.0.\nXTR files are intimately linked to the model from which they were generated. Any change (other than layout and white space changes) in the model may render the trace file unreadable. Even reordering some variable declarations will break the link.\nOur parser library, libutap, contains a small utility called tracer, which can read XTR files and translate them to a human readable format. The library and the utility are released under the LGPL license and may thus be used as a starting point for writing custom trace analysis tools. More information about the library can be found on the UPPAAL web page.\n"},{"uri":"/gui-reference/concrete-simulator/gantt-chart/","title":"Gantt Chart Panel","tags":[],"description":"","content":"The Gantt Chart panel is the middle rightmost panel of the simulator. It displays another view of the generated trace according to the Gantt Chart specification given in system definition.\nIn the Gantt Chart view, the horizontal axis represents the time span, and in the vertical axis the list of activities (usually some of the system processes) defined in the Gantt chart specification are listed. A vertical line is used to represent the current time (which corresponds to the one displayed in the Simulation Trace-combo box). Horizontal bars of varying lengths and colors represent when the different expressions in the Gantt chart specification are satisfied according to the current state of the trace.\nIf the mouse is placed over a Gantt bar, information about the intervals when the corresponding expressions are satisfied are shown.\n"},{"uri":"/gui-reference/symbolic-simulator/sequence-charts/","title":"Message Sequence Chart","tags":[],"description":"","content":"The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).\nIn the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.\n"},{"uri":"/gui-reference/menu-bar/options/","title":"Options Menu","tags":[],"description":"","content":"The options menu contains settings to control the behavior of the model-checker.\nSearch Order This option influences the order in which the state space is explored.\nBreadth first Search the state space in breadth first search order. This is typically the most efficient option when the complete state space must be searched. When generating shortest or fastest traces, this is likely the best setting. Depth first Search the state space in depth first search order. If a counter example or witnessing trace is expected to exist, this setting is usually better than the breadth first setting. It is not recommended to use this search order when generating shortest or fastest traces. Random depth first Search the state space in randomised depth first search order. If a counter example or witnessing trace is expected to exist, this is usually the best setting. Due to the randomisation, traces may vary from run to run. It is not recommended to use this search order when generating shortest or fastest traces. State Space Reduction When searching the state space, UPPAAL does not necessarily have to store all states in memory in order to guarantee termination. This option influences how aggressively UPPAAL tries to avoid storing states. There is normally a tradeoff between space and speed.\nNone Store all states. Conservative Avoid storing committed states. Aggressive Avoid storing more than one state per cycle. State Space Representation This option determines how the state space should be represented in the model checker.\nSome representations are approximative in the sence that either a larger or smaller state space than the real one is generated. When an approximative representation is used, UPPAAL may conclude that a query is maybe satisfied, i.e., UPPAAL cannot make a decisive conclusions given the representation selected.\nDifference Bound Matrices (DBM) DBMs are often fast, but for models with many clocks they require a lot of memory. Compact Data Structure A more compact, but slower representation than DBMs. In particular for models with many clocks, this setting will often significantly reduce memory consumption. Even for models with no or few clocks, this option enables other memory saving techniques at the expense of speed. Under Approximation Uses bit-state hashing to represent the state space. This results in an under approximation, however the degree of approximation can be adjusted by adjusting the size of the hash table: Large hash tables result in a larger part of the state space being searched. The hash table size can be selected with the hash table size option. Over Approximation Uses convex-hull approximation of zones. This results in an over approximation of the state space. For models without clocks, this setting has no effect. Note that if a model contains stopwatches (invariant expressions like x'==0 where x is a clock), then the resulting analysis is overapproximate even if DBM or Compact Data Structure options are selected (DBM cannot represent additional constraints required by stopwatches). In such case, UPPAAL may also report that a reachability propery is maybe satisfied, meaning that the found counter-example trace may be spurious (i.e. not realizable).\nDiagnostic Trace This option controls if a counter-example or witnessing trace (if there is one) should be generated during verification. The trace is loaded into the simulator after verification. Enabling trace generation has two side effects:\nOnly one property at a time can be verified. Symmetry reduction is disabled. The possible settings for trace generation are:\nNone Do not generated any diagnostic trace. Some Generate a diagnostic trace. Shortest Generate a shortest trace, i.e. a trace with the smallest number of transitions. Fastest Generate a fastest trace, i.e. a trace with the shortest accumulated time delay. Extrapolation The range of clocks is unbounded, i.e., clocks can obtain arbitrarily large real values. To guarantee termination, UPPAAL uses an abstraction techniques called extrapolation. The extrapolated state space is finite. UPPAAL implements a number of extrapolation techniques that differ in the size of the extrapolated state space. Not all extrapolation techniques preserve all properties for all kinds of models. UPPAAL automatically selects the coarsets extrapolation, which still preserves the property being analysed.\nSometimes it may be of benefit to use a coarser (and faster) extrapolation that the one selected by UPPAAL. By doing so, the analysis will use an over-approximation of the state space. Listed from finest to coarsets, the choices are: None, Difference, Local, and Lower/Upper.\nAutomatic Selects the coarsest extrapolation preserving the property being analysed. If in doubt, use this setting. None Do not use extrapolation. Termination is no longer guaranteed. Since performing the extrapolation is relatively expensive, this may be of use if you know that the symbolic state space is finite. Difference Used whenever the model or the query contain difference constraints over clocks, e.g., x - y \u0026lt; 3. Local Used whenever the query contains either the deadlock keyword or involves a liveness property (except if the model or the query contain difference constraints). Lower/Upper Used whenever a reachability analysis is performed, except when the deadlock keyword is used or when the model or the query contain difference constraints. Hash table size Adjusts the amount of memory used to represent the state space when using bit-state hashing. This option has no effect unless under approximation is selected.\nReuse When selected, instructs the verifier to (whenever possible) reuse the generated portion of the state space when several properties of the same system are checked.\nStatistical Parameters Lower probabilistic deviation (-δ) Used in hypothesis testing (qualitative model-checking) to specify the lower bound of indifference region from the specified probability. Upper probabilistic deviation (+δ) Used in hypothesis testing (qualitative model-checking) to specify the upper bound of indifference region from the specified probability. Probability of false positives (α) Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) \u0026lt;= 0.5) and probability estimation (quantitative model-checking queries like Pr[...](...)) to specify the level of significance (probability of Type I error). Probability of false negatives (β) Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) \u0026lt;= 0.5) to specify the level of significance (probability of Type II error). Probability uncertainty (ε) Used in probability estimation (qualitative model-checking) to constrain the size of the confidence interval in a form of p ± ε (1-α CI). Ratio lower bound (u0) Used in comparison of two probabilities. Ratio upper bound (u1) Used in comparison of two probabilities. Histogram bucket width Specifies the width of each column in the histogram. By default it is set to zero meaning that the width is determined by ratio of entire histogram width divided by a bucket count. Histogram bucket count Specifies the number of columns in the histogram. By default it is set to zero meaning that the count is determined by taking a square root of a total number of samples and dividing by four. More Information The compact data structure and the options for state space reduction are described in the following paper:\nEfficient Verification of Real-Time Systems: Compact Data Structure and State Space Reduction, Kim G. Larsen, Fredrik Larsson, Paul Pettersson and Wang Yi. In Proceedings of the 18th IEEE Real-Time Systems Symposium, pages 14-24. San Francisco, California, USA, 3-5 December 1997.\n"},{"uri":"/language-reference/system-description/priorities/","title":"Priorities","tags":[],"description":"","content":"Given some priority order on the transitions, the intuition is that, at a given time-point, a transition is enabled only if no higher priority transition is enabled (see also Semantics.) We say that the higher priority transition blocks the lower priority transition.\nPriorities can be assigned to the channels and processes of a system. The priority orders defined in the system are translated into a priority order on tau-transitions and synchronizing transitions. Delay transitions are still non-deterministic (unless urgent channels are used.)\nPriorities on Channels Priorities on Processes Priorities on both Channels and Processes Priorities on Channels ChanPriority ::= \u0026#39;chan\u0026#39; \u0026#39;priority\u0026#39; (ChanExpr | \u0026#39;default\u0026#39;) ((\u0026#39;,\u0026#39; | \u0026#39;\u0026lt;\u0026#39;) (ChanExpr | \u0026#39;default\u0026#39;))* \u0026#39;;\u0026#39; ChanExpr ::= ID | ChanExpr \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; A channel priority declaration can be inserted anywhere in the global declarations section of a system (only one per system). The priority declaration consist of a list of channels, where the \u0026lsquo;\u0026lt;\u0026rsquo; separator defines a higher priority level for channels listed on its right side. The default priority level is used for all channels that are not mentioned, including tau transitions.\nNote: the channels listed in the priority declaration must be declared earlier.\nExample chan a,b,c,d[2],e[2]; chan priority a,d[0] \u0026lt; default \u0026lt; b,e; The example assigns the lowest priority to channels a and d[0], and the highest priority to channels b, e[0] and e[1]. The default priority level is assigned to channels c and d[1].\nPriorities on Processes Process priorities are specified on the system line, using the separator \u0026lsquo;\u0026lt;\u0026rsquo; to define a higher priority for processes to its right. If an instance of a template set is listed, all processes in the set will have the same priority.\nExample system A \u0026lt; B,C \u0026lt; D; Resolving Synchronization In a synchronisation the process priorities are ambigous, because more than one process is involved in such a transition.\nWhen several processes synchronize, the priority of the transition is given by the highest priority of the processes. This applies to both standard synchronization and broadcast.\nPriorities on both Channels and Processes In a system with priorities on both processes and channels, priorities are resolved by comparing priorities on channels first. If they are the same, the process priorities are compared.\n"},{"uri":"/gui-reference/menu-bar/help/","title":"Help Menu","tags":[],"description":"","content":"The help menu has two items: Help which opens a separate window showing the help pages, and About which opens a window showing the version number and information about the copyrights of UPPAAL.\n"},{"uri":"/toolsandapi/latex/","title":"Latex","tags":[],"description":"","content":"UPPAAL web site includes links to uppaal.sty file — style for typesetting documents in LaTeX.\nUPPAAL Latex "},{"uri":"/language-reference/system-description/scope-rules/","title":"Scope Rules","tags":[],"description":"","content":"The scope rules determine which element a name refers to in a given context. The context is either local (to a process template), or global (in a system description).\nIn a local context, the names are always referring to local declarations or formal parameters (if the name is locally defined), otherwise to a globally declared name.\nIn the global context, a name is always referring to a global declaration.\nNote: There is only one name space in each context. This means that in each context all declared clocks, integer variables, constants, locations, and formal paramters must have unique names. However, local names may shadow globally declared names.\n"},{"uri":"/language-reference/system-description/semantics/","title":"Semantics","tags":[],"description":"","content":"In the following we give a pseudo-formal semantics for UPPAAL. The semantics defines a timed transition system (S, s0, →) describing the behaviour of a network of extended timed automata. The set of states S is defined as {(L, v) | v ⊨ Inv(L)}, where L is a location vector, v is a function (called a valuation) mapping integer variables and clocks to their values, and Inv is a function mapping locations and location vectors to invariants. The initial state s0 is the state where all processes are in the initial location, all variables have their initial value, and all clocks are zero. The transition relation, →, contains two kinds of transitions: delay transitions and action transitions. We will describe each type below.\nGiven a valuation v and an expression e, we say that v satisfies e if e evaluates to non-zero for the given valuation v.\nInvalid Evaluations If during a successor computation any expression evaluation is invalid (consult the section on expressions for further details about invalid evaluations), the verification is aborted.\nDelay Transitions Delay transitions model the passing of time without changing the current location. We have a delay transition (L, v) −d→ (L, v\u0026rsquo;), where d is a non-negative real, if and only if:\nv\u0026rsquo; = v+d, where v+d is obtained by incrementing all clocks with d. for all 0 ≤ d\u0026rsquo; ≤ d: v+d\u0026rsquo; ⊨ Inv(L) L contains neither committed nor urgent locations for all locations ℓ in L and for all locations ℓ\u0026rsquo; (not necessarily in L), if there is an edge from ℓ to ℓ\u0026rsquo; then either: this edge does not synchronise over an urgent channel, or this edge does synchronise over an urgent channel, but for all 0 ≤ d\u0026rsquo; ≤ d we have that v+d\u0026rsquo; does not satisfy the guard of the edge. Action Transitions For action transtions, the synchronisation label of edges is important. Since UPPAAL supports arrays of channels, we have that the label contains an expression evaluating to a channel. The concrete channel depends on the current valuation. To avoid cluttering the semantics we make the simplifying assumption that each synchronisation label refers to a channel directly.\nPriorities increase the determinism of a system by letting a high priority action transition block a lower priority action transition. Note that delay transitions can never be blocked, and no action transition can be blocked by a delay transition.\nFor action transitions, there are three cases: Internal transitions, binary synchronisations and broadcast synchronisations. Each will be described in the following.\nInternal Transitions We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there is an edge e=(ℓ,ℓ\u0026rsquo;) such that:\nthere is no synchronisation label on e v satisfies the guard of e L\u0026rsquo; = L[ℓ\u0026rsquo;/ℓ] v\u0026rsquo; is obtained from v by executing the update label given on e v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either ℓ is committed or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Binary Synchronisations We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there are two edges e1=(ℓ1,ℓ1\u0026rsquo;) and e2=(ℓ2,ℓ2\u0026rsquo;) in two different processes such that:\ne1 has a synchronisation label c! and e2 has a synchronisation label c?, where c is a binary channel. v satisfies the guards of e1 and e2. L\u0026rsquo; = L[ℓ1\u0026rsquo;/ℓ1, ℓ2\u0026rsquo;/ℓ2] v\u0026rsquo; is obtained from v by first executing the update label given on e1 and then the update label given on e2. v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either ℓ1 or ℓ2 or both locations are committed, or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Broadcast Synchronisations Assume an order p1, p2, … pn of processes given by the order of the processes in the system declaration statement. We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there is an edge e=(ℓ,ℓ\u0026rsquo;) and m edges ei=(ℓi,ℓi\u0026rsquo;) for 1≤i≤m such that:\nEdges e, e1, e2, …, em are in different processes. e1, e2, …, em are ordered according to the process ordering p1, p2,… pn. e has a synchronisation label c! and e1, e2, …, em have synchronisation labels c?, where c is a broadcast channel. v satisfies the guards of e, e1, e2, … em. For all locations ℓ in L not a source of one of the edges e, e1, e2, … em, all edges from ℓ either do not have a synchronisation label c? or v does not satisfy the guard on the edge. L\u0026rsquo; = L[ℓ\u0026rsquo;/ℓ, ℓ1\u0026rsquo;/ℓ1, ℓ2\u0026rsquo;/ℓ2, … ℓm\u0026rsquo;/ℓm] v\u0026rsquo; is obtained from v by first executing the update label given on e and then the update labels given on ei for increasing order of i. v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either one or more of the locations ℓ, ℓ1, ℓ2, … ℓm are committed, or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Probabilistic Transitions In statistical model checking the concrete delay and transition are determined as follows:\nEach process chooses a delay based on its current location: If the current location invariant has a time bound, then the concrete delay is taken according uniform distribution up to that bound. Otherwise (the time invariant is absent) the delay is chosen by exponential distribution using the rate λ specified on the current location. The probability density function of delay d∈[0;∞) is F(d)=λe−λd, where e=2.718281828… and the concrete delay is generated by −ln(u)/λ where u is a uniform random number from (0;1] interval. The process with the shortest delay is chosen. If there are several such processes then a random one of these is chosen (according to uniform distribution). The shortest delay is executed and continuous variables are updated. The chosen process attempts to take a transition: Compute all enabled internal and sending edge-transitions. Pick the concrete edge according to uniform distribution. If the edge has probabilistic branches, then the probability of taking a branch i is determined by the ratio wi/W, where wi is the weight of the branch i and W is the sum of all branch weights: W=Σjwj. Statistical model checking has the following assumptions about the model:\nInput enableness (non-blocking inputs): Sending cannot be blocked, i.e. the channel is either broadcast or there is always one process with an enabled receiving edge-transition. Input determinism: There is exactly one enabled receiving edge-transition at a time. For binary synchronizations there is at most one receiving process at a time. For more details about probabilistic semantics of priced timed automata please see:\nStatistical Model Checking for Networks of Priced Timed Automata, Alexandre David, Kim G. Larsen, Axel Legay, Marius Mikučionis, Danny Bøgsted Poulsen, Jonas van Vliet and Zheng Wang. In Proceedings of the 9th International Conference on Formal Modeling and Analysis of Timed Systems (FORMATS), Aalborg, Denmark, September 2011.\n"},{"uri":"/gui-reference/symbolic-simulator/symbolic-traces/","title":"Symbolic Traces","tags":[],"description":"","content":"Since clocks range over the non-negative reals, timed automata can have infinitely many states (not to be confused with locations) and infinitely many traces. The simulator cannot visualize all these concrete traces. Instead it shows an infinite set of traces - a so called symbolic trace. Each symbolic state of a symbolic trace is a set of states and their delay successors described by a number of constraints on the clocks. In a given symbolic state, the active locations and the values of discrete variables are the same for all states.\nSymbolic traces shown in the simulator are backward stable, but not forward stable:\n**Forward stable** Given two symbolic states A and B on a symbolic trace such that A is before B, every state in A can reach a state in B. **Backward stable** Given two symbolic states A and B on a symbolic trace such that A is before B, every state in B can be reached by a state in A. In particular, care must be taken when interpreting a counter example produced by the model checker: Not every state in the symbolic states along a symbolic trace will necessarily lead to an error state, although all states in the last symbolic state are indeed reachable from the initial state.\nNote: verifyta can be used to produce forward stable traces.\n"},{"uri":"/gui-reference/verifier/","title":"Verifier","tags":[],"description":"","content":"The verifier is to check safety and liveness properties by on-the-fly exploration of the state-space of a system in terms of symbolic states represented by constraints. The verification tool in UPPAAL also provides a requirement specification editor for specifying and documenting the system requirements.\nIn this help section we describe how to operate the verification tool, in terms of how to specify and verify requirements. The requirement specification language and the verification options are described in separate sections.\n"},{"uri":"/gui-reference/yggdrasil/","title":"Test Cases (Yggdrasil)","tags":[],"description":"","content":"Test Cases (Yggdrasil) tab contains an offline test-case generation tool with a purpose of increasing edge coverage. It generates traces from the model, and translates them into test cases based on test code entered into the model on edges and locations next to comments.\nThe main features of the Test Cases generator are:\nThe generated test code is backend agnostic, meaning that it is user-defined and independent of specific test execution engines. Three modes for test case generation: Test purpose mode: Generates a test case specified by a reachability query An auto-depth mode: Generates tests automatically aiming at achieving edge/location coverage Single-step mode: Generates an individual test case per uncoverd edge. Visualization of coverage Determinism Test generator expects a deadlock free and mostly deterministic model.\nDeadlocks can be checked against in the Verifier tab using A[] not deadlock query.\nThere are no checks or reinforcements made for determinism. Non-deterministic implementation requirements (behavior not controlled by a test execution harness) may yield test-cases which cannot be executed in a controlled manner. For example, test execution harness might not be able to force the implementation under test to respond in a specific way assumed by a test case if the implementation is allowed to respond in multiple ways non-deterministically. The environment assumption model (edges controlled by the test execution harness) is encouraged to be non-deterministic to facilitate a more focused and flexible control when selecting test cases.\nBasic operation The buttons Add will generate traces based on the verification options selected in the Options menu where the search order and diagnostic trace options are overridden by the corresponding drop-down list selection. Unless intimately familiar with the search algorithms of Uppaal, leave the options at their default settings.\nThe traces are added and shown in the Traces list below on the left. Selecting a trace will show the statistics for this trace in the Trace statistics on the right. The Total Coverage button will show the combined statistics of all the traces added so far. Double clicking a trace loads the trace in the Simulator tab, where the execution scenario can be examined in detail. Simulator colors the covered locations and edges in blue when Mark Visited option is selected under the View menu.\nTest cases are exported to a specified directory specified by clicking Save Test Cases button at the bottom. Previously stored test cases are overwritten by new test ones.\nNote: the traces and statistics are lost when the model is reloaded. Traces and statistics are not saved with the model. Only the test cases can be saved.\nSuggested methodology: Test Cases can be generated in several ways, depending on the actual project, but it is designed to support the method outlined below:\nTest purposes very often represent mandatory critical observations that must be observed on the system under test. First, Add the test cases representing the test purposes. These test are mandated anyway, and will cover some parts of the model, but this coverage is typically insufficient. Generate tests that improves the (edge/location) coverage of the model (but does not guarantee so). Second, Add the test cases using the auto-depth mode to improve the coverage. The coverage achieved by the second step can be completed by adding an individual test-case for each of these uncovered edges or locations. Hence, third, Add the test cases using the single-step mode. "},{"uri":"/gui-reference/yggdrasil/tutorial/","title":"Tutorial","tags":[],"description":"","content":"This tutorial shows how to use the Uppaal Test Generator (Yggdrasil) to generate test scripts step-by-step. It assumes that you are familar with the basic syntax and semantics of Uppaal automata, the basic query language, and is able to use the model-editor.\nAt the end of the tutorial you will be able to generate simple executable test cases.\nThe features for generating offline test cases are presented terms of two simple example systems: An On/Off system and an Up/Down counter. The behavior of these systems are generic, but could, respectively, represent a lamp with on/off capabilities and a dimmer lamp, which can be turned up or down.\nBoth examples include a model, decorated with test-code, a (supposedly) correct implementation of the system, and a implementation mutant representing an implementation mistake. The system and mutant are implemented in Java so they should be platform independent. The generated test cases are output in Java and is, when compiled, executable on these implementations. Execution scripts are included for Windows and Linux.\nThe necessary files are provided as part of the Uppaal distribution in the directory demo/testcases/.\nThe tutorial proceeds in three steps:\nBasic Test Cases Generation. Here you will learn the basic steps involved in annotating the model with test code, and generating simple test cases. Test cases with model-variables. Here you will learn how to insert the values of model variables into the test code, and how to generate a covering test suite. Generating testcases using queries (test purposes). Here you will learn to generate test cases based on test purpose queries. The concepts of Test Cases generation is explained in the Test Cases section.\nFor comments or questions please contact Brian Nielsen bnielsen@cs.aau.dk or Marius Mikucionis marius@cs.aau.dk.\n"},{"uri":"/","title":"","tags":[],"description":"","content":"UPPAAL Help UPPAAL is a tool for modeling, validation and verification of real-time systems. It is appropriate for systems that can be modeled as a collection of non-deterministic processes with finite control structure and real-valued clocks (i.e. timed automata), communicating through channels and (or) shared data structures. Typical application areas include real-time controllers, communication protocols, and other systems in which timing aspects are critical.\nThe UPPAAL tool consists of three main parts:\na graphical user interface (GUI), a verification server, and a command line tool. The GUI is used for modelling, symbolic simulation, concrete simulation, and verification. For both simulation and verification, the GUI uses the verification server. In simulation, the server is used to compute successor states. See also the section on setting up a remote server. The command line tool is a stand-alone verifier, appropriate for e.g. batch verifications.\nMore information can be found at the UPPAAL web site: http://www.uppaal.org.\n"},{"uri":"/preview-build/","title":"","tags":[],"description":"","content":"Preview Build UPPAAL 5.0.0 beta2 since UPPAAL 5.0.0 beta1 Fixed symbolic trace as concrete trace output to pass the regression suite by Fix version check serialization issue on startup Fix issue where fatal engine errors are lost when parsing BasicResponse Fixed version date parsing to be more robust Updated JetBrainMono fonts Added bold italic highlighting for /// comments Update old dtd version to fit model files UPPAAL 5.0.0 beta1 since UPPAAL 4.1.20 Stratego 11 Graceful cancellation and other result output fixes Cleanup demo examples Fix ant release date and applied format validation to release dates Fix issue where plots would seemingly go backwards in time Swap result and query Fixed font and drawing anti-aliasing in the verification dialog Removed splashscreen as startup seems to be fast enough Fix issue where the last delay transition of a concrete witness trace would be omitted Fixed issues with advanced line break Recover concrete trace output on verifyta Add parsing for saving plot settings in concrete simulator "},{"uri":"/categories/","title":"Categories","tags":[],"description":"","content":""},{"uri":"/extensions/cora/","title":"CORA","tags":[],"description":"","content":"Language Guide UPPAAL CORA is based on the newest internal development version of UPPAAL. On one hand this means that it contains all the new and exciting features of the next version of UPPAAL, but on the other it also means that it contains many new and untried features, that might change before the final release of UPPAAL. This page describes the new language features compared to the UPPAAL 4.0 series.\nCost Annotation In LPTA, an implicit continuous monotonic variable called cost is defined. The rate at which this variable grows can be specified in the location invariant as:\ncost\u0026rsquo; == INTEXPR\nwhere INTEXPR is an integer expression. If specified in multible locations, the actual cost rate is the sum of the cost rate specified in the current location of each process. The cost can be incremented on edges using the increment operator +=.\nHere is an example of the aircraft landing problem: xta, q.\nRemaining Cost Estimation The performance of UPPAAL CORA can be improved dramatically by annotating the model with an admissible estimate of the remaining cost to reach the goal condition. Admissible means that the estimate is not bigger than the actual cost of reaching the goal, i.e., the estimate provides a lower bound on the remaining cost. The estimate is specified by declaring a meta integer variable named remaining. Specifying a good value for remaining is crucial for good performance.\nIn previous versions of UPPAAL, remaining had to be a lower bound on the remaining cost from the state and all its delay successors, but this is no longer required. Now remaining must simply be a lower bound on the remaining cost. When computing a successor, UPPAAL automatically adjusts the value of remaining. Thus even when you do not recompute remaining, it will still be a lower bound of the remaining cost. You will probably be able to come up with a better lower bound on the remaining cost, so you should try compute a remaining cost yourself on each edge transition.\nCommand Line Options Below we describe the new options supported by the command line interface of UPPAAL (verifyta). Most of these options are also available from the options menu in the graphical frontend.\nGuiding A number of different search orders are supported. These can be selected with the -o option:\n-o0 Breadth first. -o1 Depth first. -o2 Random depth first. -o3 Smallest heur first. -o4 Best first. -o5 Best depth first. The first two are well known from previous releases of UPPAAL. Random depth first search is similar to depth first search, but it randomises the order in which the successors of a state are searched. Smallest heur first requires the presence of an integer variable named heur in the model. The state with the smallest value of this variable is always explored next. In most cases, this variable should be a meta variable. Best first and best depth first are used for optimal reachability, see the next topic.\nOptimal Reachability UPPAAL CORA has support for finding optimal schedules. Optimality is defined in terms of a cost variable, see the Language Guide for details. The optimal trace can be found by using the -t3 option. With this option, UPPAAL CORA keeps searching until a trace to a goal state with the smallest value for the cost variable has been found. Alternatively you can use the -E option to find the optimal cost without generating the trace.\nUPPAAL CORA automatically enables the -o4 option (best first) when using the -t3 option. This can be changed by manually using a different -o option after the -t3 option. In the best first search order, the state with the smallest value of the cost variable is searched next. An alternative is to use best depth first. This search order performs a depth first search, but always searches the state with the lowest cost first. If a remaining cost estimate annotation is provided, the interpretation of the best first and best depth first is changed to search the state with the smallest sum of the cost variable and the remaining variable next.\nExamples The jugs example has been updated to the new syntax. You can download it here: jugs2.ta, jugs2.q. You can find the optimal solution like this:\nverifyta -E jugs2.ta jugs2.q\nLimitations UPPAAL CORA has a number of limitations. These limitations are not fundamental, but are a result of using new internal data structures with a currently limited feature set. Over time, these limitations will be resolved.\nNo extrapolation, hence termination is not guaranteed unless you guarantee that either: The system is acyclic. All clocks are bound by invariants. Simple reachability only: No liveness check No deadlock check Limited use of guiding: Support for (cost + remaining) sorting is implemented (best first search) Support for heuristic variable is implemented, but the expression cannot refer to the cost variable. "},{"uri":"/extensions/ecdar/","title":"ECDAR","tags":[],"description":"","content":"Language To define timed I/O automata, timed game automata of TIGA with the following constraints are used:\nInvariants may not be strict. Inputs must use controllable edges. Outputs must use uncontrollable edges. All channels must be declared broadcast. The system is implicitly input enabled due to broadcast communication but for refinement checking purposes, the relevant inputs must be explicit in the model. In the case of parallel composition of several components, a given output must be exclusive to one component. For implementations, outputs must be urgent. For implementations, every state must have independent time progress, i.e., progress must be ensured by either an output or infinite delay. Tau transitions (no output or input) are forbidden. Global variables are forbidden. The grammar for specifying property is given by:\nProperty := \u0026#39;consistency:\u0026#39; System | \u0026#39;refinement:\u0026#39; System \u0026#39;\u0026lt;=\u0026#39; System | \u0026#39;specification:\u0026#39; System | \u0026#39;implementation:\u0026#39; System System := ID | \u0026#39;(\u0026#39; System Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Composition Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Conjunction Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Quotient Expr \u0026#39;)\u0026#39; Composition := System \u0026#39;||\u0026#39; System | Composition \u0026#39;||\u0026#39; System Conjunction := System \u0026#39;\u0026amp;\u0026amp;\u0026#39; System | Conjunction \u0026#39;\u0026amp;\u0026amp;\u0026#39; System Quotient := System \u0026#39;\\\u0026#39; System Expr := /* nothing */ | \u0026#39;:\u0026#39; tctl In particular the grammar can generate expressions of the type refinement: (A || B) \u0026lt;= (C : A[] not C.unsafe). As a reminder the tctl formulas supported are\nA[ p U q ]\nFor all path p must be satisfied until q with the twist (due to the game setting) that p must still hold when q holds. A\u0026lt;\u0026gt; q\nEquivalent to A[ true U q ]. A[ p W q ]\nThe weak until variant. A[] p\nEquivalent to A[ p W false ]. A[] (p \u0026amp;\u0026amp; A\u0026lt;\u0026gt; q)\nThis is the Büchi objective formula with safety. for all path p must always hold and q must always be reachable from all states. A[] A\u0026lt;\u0026gt; q\nEquivalent to A[] (true \u0026amp;\u0026amp; A\u0026lt;\u0026gt; q). The formulas involving a Büchi objective can be used to constrain the behaviours to be non-zeno by adding an observer automata that visits a state when time elapses.\u0026lt;/e\u0026lt;=i)\u0026gt;\nKnown Issues When checking for refinement, inputs that are part of the alphabet of the processes must be put explicitly in the model for all locations of that process. The graphical simulator determinizes the strategy and limits the game even though the underlying strategy is more permissive. When a sub-formula is inconsistent there is no strategy. If you want a strategy you need to ask for a consistency check on that sub-formula. If you use the quotient, you must add two locations to the processes, one Universal and one Inconsistent. The universal one must accept all inputs of that process and generate all outputs. This must match the signature of the component. The inconsistent location must be urgent without any transition at all. It is not possible to simulate the quotient in the simulator. This is a limitation inherent to the problem because this operator generates new states and transitions that do not have references in the original model, thus the graphical simulator will be lost. We suspect that it is possible to write models that may fool ECDAR by giving wrong answers. This may happen due to some issues with extrapolation. Please deactivate extrapolations and make sure that your model is bounded if you experience this. "},{"uri":"/tags/","title":"Tags","tags":[],"description":"","content":""},{"uri":"/extensions/tiga/","title":"UPPAAL Tiga","tags":[],"description":"","content":"Manual The manual (updated 9/8/07) is available separately from the distribution. You can access it from here.\nKnown Issues Extrapolation option -n 4. This option should not be used, it would give wrong results. It is possible to get the GUI choose randomly wrong points w.r.t. the strategy occasionally. The generated C-code makes sense only for models with winning non-cooperative strategies. "},{"uri":"/extensions/tron/","title":"UPPAAL TRON","tags":[],"description":"","content":"Requirements TRON requires Unix environment and GNU C++ compiler (g++) or Microsoft Visual Studio or Sun Java 1.5 for creating custom adapters. It has been built on Debian GNU/Linux SID (unstable) and also for Windows in Cygwin environment using g++ from MingGW so it\u0026rsquo;s very likely to work with C-library adapters built there. There\u0026rsquo;s a small example C-library adapter built by Microsoft compiler, however currently it is only useful to connect to real IUTs in real-time, the virtual-time framework won\u0026rsquo;t work in Windows, unless through TCP/IP socket adapter. Here is the dependency list with Debian package names in parenthesis:\nJava 2 Standard Development Kit 1.5 (AKA J2SDK 5.0) from http://java.sun.com/. Used by: TRON Tracer GUI, smart-lamp. Earlier Java versions won\u0026rsquo;t work. Dot/Graphviz (graphviz) from http://www.graphviz.org/. Used by: TRON Tracer GUI. R (r-base) from http://www.r-project.org/. Used by: latency. GhostView (gv) from http://wwwthep.physik.uni-mainz.de/~plass/gv/. Used by: latency. Install them all on Debian: apt-get install g++ libstdc++6 graphviz r-base gv\nStatus of the Project Now Uppaal TRON version 1.4 Beta 1 is available. The tool is still in early development and experimental phase, but now anyone can checkout and taste the early fruits on his/her own. The current version is based on the latest Uppaal 4.1. Current availability and limitations:\nSystem specification accepted in Uppaal xta and xml format. The interface is specified separately in adapter library code. Supported main Uppaal features: clocks, data variables, paired channel synchronizations, urgent locations. The use of arrays, broadcast channel, and committed locations are experimental and not tested. Input and output actions through channel handshake synchronization (no buffering or value passing). User supplied adapter loading via dynamic library interface. Adapter development framework (C++), interfaces are not completely stabilized yet. Examples of tool applications against C++ programs as IUT. Use Uppaal to create and edit models. TRON Tracer GUI demonstrates the main concepts: system model partitioning, interactive traces in testing, system emulation and monitoring. Graphical user interface is mounted on generic trace-interpreter-adapter (special IUT adapter library) and serves as generic example of how to connect/link to TRON. Stripped binary executable form of Uppaal TRON. No source code provided due to licensing restrictions. Binary is dynamically linked in order to provide efficient connectivity with user-supplied adapter. The tool is prepared on the following platforms: Windows 2000 Professional, GNU Compiler Collection 3.4.5 Linux 2.6.18 on Intel PC, GNU Compiler Collection 4.1.2\nLatest builds for Sun Solaris could also be provided upon request. It is important that the machine architecture should match and GCC-2 should not be mixed with GCC-3. The same holds for GCC-4. Please report your experiences. User Manual You may want to read an early draft of user-manual (still under development, comments are welcome).\nTesting Runtime Command Line Options TRON binary is based on verifyta utility from Uppaal, hence there are a few options available to tune the Uppaal engine too. I will explain only TRON specific ones and some of verifyta that might effect testing. The following is printed on screen when TRON is run in command line:\n./tron -h Usage: tron [options] -I adapter model.xml [-- parameters to adapter] Options: -A Use convex-hull approximation. [-D filename](#D) specify a file for driver log (default /dev/null). [-F future](#F) The amount of future in mtu to be precomputed (default 0), To disable precomputation set it to -1 (not recommended). [-H n](#H) Set the hash table size for bit state hashing to 2**n (default = 27) [-I filename](#I) dynamic C-library with adapter to an implementation, or: TraceAdapter -- interact via textual stdin/stdout; SocketAdapter -- remote TCP/IP socket adapter. [-P delay](#P) short,long: try random delay from one of intervals (mtu), eager: delay as little as possible for chosen transition, lazy: delay as much as possible for chosen transition, random: delay within bounds specified by model (default). [-Q log](#Q) use logical (simulated) clock instead of host clock. or specify port number for simulated clock: -Q 6521 [-S filename](#S) Append the verdict, I/O and duration to file (default /dev/null) -U Unpack reduced constraint systems before relation test. -V Print version information and exit. [-X integer](#X) Value to initialize random number generator (default time) -h Print this message. [-i ](#i) Print a signal flow diagram of the system and exit: dot: outputs dot graph, expects formated standard input: \"input\" (channel)* \"output\" (channel)* gui: non-partitioned flow information for TRON GUI; [-o filename](#o) Redirect output to file instead of stdout, see also -v -s \u003c0|1|2\u003e Select search order. 0: Breadth first (default) 1: Depth first 2: Random depth first [-u inpDelay,inpRes,outDelay,outRes](#u) -u inpRes,outRes Observation uncertainty intervals in microseconds: inpDelay: the least delay that takes to deliver input, inpRes: possible additional delay for delivering input, outDelay: the least delay that takes to observe output, outRes: possible additional delay for observing output. [-v \u003c0+1+2+4+8+16\u003e](#v) Specify verbosity of the output. For -o test logging verbosity bit-flags: = 0: only verdict, disable trace output (default), \u0026 1: progress indicator for interactive experiments, \u0026 2: test events applied in the UPPAAL engine, \u0026 4: available input and delay choices for simulation, \u0026 8: backup state set and prepare for final diagnostics, \u002616: dumps current state set on each update. [For -i partitioning: 0-none, 1-errors, 2-warnings, 3-diagnostics](#iv). [-w integer](#w) Specify additional number of time units to attempt to violate invariants. Works under assumption that invariants are not used in Environment. -q Do not display the copyright message. Environment variables: UPPAAL_DISABLE_SWEEPLINE disable sweepline method UPPAAL_DISABLE_OPTIMISER disable peephole optimiser UPPAAL_OLD_SYNTAX use version 3.4 syntax The value of these variables does not matter. Defining them is enough to activate the feature in question. Here is a more detailed description of testing specific options:\n-I filename specifies the adapter to connect to IUT. It is either the name of a built-in adapter (such as TraceAdapter and SocketAdapter) or the filename of dynamically loaded C-library. See Building Test Adapter on how to make one.\n-D filename specifies where the output of the Driver (component that time-stamps input and output events) should be redirected to. The EBNF of the output is the following:\nDriverLog ::= ( line **EOL** )* line ::= timestamp | event timestamp ::= **\"delay\"** integer event ::= channelname **\"(\"** paramlist **\")\"** paramlist ::= | integer ( **\",\"** integer )* The timestamp line means that the system has delayed until the specified absolute time moment in microseconds counting from the beginning of testing. The event line means an input or an output event observation at the last delay timestamp in the driver. The specific input or output nature is specified by channel name and the bounded variable integer values.\n-S filename specifies where the verdict information should be saved (usually used for gathering Statistics of many TRON runs). If specified, each line of the file will consist of five elements: 1) integer for random seed used (see -X) 2) verdict 3) number of inputs 4) number of outputs 5) time used in model time units.\n-v \u0026lt;0+1+2+4+8+16\u0026gt; specifies what testing information should be visible on the output by bit-flags:\n1 progress indicator, useful in interactive command-line when no other testing information is specified; 2 events applied in Uppaal engine (mainly for debugging); 4 choices considered when emulating the environment; 8 makes a copy of the current state set before applying delay and output events, this enables some diagnostic information when test verdict is failed or inconclusive but also costs a bit of additional memory; 16 shows the current reachable state set before each update.The numbers above should be added and final integer result used in -v option. For example, for progress indicator (1) and diagnostic information (8) one should use -v 9 as 1+8=9. -o filename redirects the testing information (specified by -v) to the file rather than standard output stream.\n-H n specifies the size of hash table in Uppaal engine for detecting loops in passed list states (as in verifyta), the size in testing can be much smaller as the TRON considers only the current reachable state set which is much smaller than the whole state space of the system (as in verification process);\n-F future specifies the future input event horizon for environment emulation in model time units, the further horizon the more TRON should pre-compute into the future when choosing input event; the value should be as large as possible for richer input choices but small enough for TRON to be able to compute respond within 1 model time unit; the default is 1 model time unit (disabling it with 0 is not recommended);\n-P delay constrains the choice of delay by the following heuristics:\nrandom the choice is based on available delays in the model and concrete delay is chosen by pseudo-random number generator; if delays are not bounded by invariant TRON may choose very large delays and hence appear idle for very long time; lazy the choice is based on available delays in the model and concrete delay is taken by choosing the longest possible; TRON may delay for very long if constraints (invariants) allow it; eager the choice is based on available delays in the model and concrete delay is taken by choosing the shortest delay possible; short,long are integers and specify the longest delay choice for short and long delay. The concrete delay is then chosen randomly based on the model and longest possible delay. The choice of a short or a long delay is random; -w integer prolongs the model delay by specified number of model time units possibly breaking the invariants in the model; it was created as a workaround for proper IUT and environment invariant separation to be able to test the IUT invariants under assumption that the environment model did not contain any invariants; today correct partitioning (see Test Interface Specification) of the system model is recommended instead of this option;\n-u inpDelay,inpRes,outDelay,outRes see Observation Uncertainties for explanation.\n-Q log specifies that virtual time framework should be used rather than host machine\u0026rsquo;s clock, string log can also be replaced by an integer meaning the port number for external virtual clock users, see Virtual Time for more details;\n-X integer specifies the value of random seed for the random number generator which drives the environment emulation choices; it could be useful to attempt to replicate an identical test run although it is very hard to ensure the same flow of time and event interleaving;\n-i \u0026lt;dot|gui\u0026gt; generates the signal flow of the system model in graphviz format; when specified, TRON expects the input/output interface to be fed into standard input stream in the following EBNF format:\nTIS ::= inputs outputs precision timeout inputs ::= **\"input\"** channels **\";\"** outputs ::= **\"output\"** channels **\";\"** precision ::= **\"precision\"** integer **\";\"** timeout ::= **\"timeout\"** integer **\";\"** channels ::= | channel ( **\",\"** channel )* **\";\"** channel ::= channelname **\"(\"** variables **\")\"** variables ::= | variablename ( **\",\"** variablename)* See also Test Interface Specification. When -i is specified, -v option has a different special meaning:\n-v \u0026lt;0|1|2|3\u0026gt; specifies what information is produced in partitioning (-i) mode: 0 \u0026ndash; silent, no errors are shown, 1 - only errors are shown, 2 - warnings are shown, 3 - errors, warnings and rules being applied are shown. See also Test Interface Specification.\nInterpreting Messages Here is the beginning of output from smart lamp demo:\n1. UPPAAL TRON 1.4 Beta 2 using UPPAAL 4.1.0 (rev. 2765), October 2006 2. Compiled with g++-4.1.2 -Wall -DNDEBUG -O2 -DBOOST_DISABLE_THREADS 3. Copyright (c) 1995 - 2006, Uppsala University and Aalborg University. 4. All rights reserved. 5. Options for the UPPAAL engine: 6. Search order is breadth first 7. Using no space optimisation 8. State space representation uses minimal constraint systems 9. Observation uncertainties: 0, 0, 0, 0 (microseconds). 10. Future precomputation: closure(300 mtu). 11. Input delay extended by: 0 12. OS scheduler: non-real-time. 13. socket connect: Connection refused 14. (* 9 tries left *) 15. Environment processes: user. 16. Timeunit: 10000us 17. Timeout: 1000000mtu 18. Inputs: grasp(), release() 19. Outputs: level(adapLevel) Lines 1-2 specify the version and the build environment of TRON binary, might be important when building the C-library adapter. Lines 3-4 contain copyright information. Lines 5-11 show the state of Uppaal engine and TRON options. Line 12 says that TRON is using non-real-time process scheduler which is used for all virtual time runs. In real time mode TRON will attempt to gain high priority and select real-time round-robin scheduler if possible (available and enough permissions given), which would minimize the scheduling disturbances from other processes. Lines 13-14 show that TRON attempted socket connection (to IUT) but failed and it will retry doing so for 9 times with 2 second intervals. Lines 15-19 show the model partitioning and testing interface information: environment consists of just user process (user invariants will be considered when offering input), model time unit is interpreted as 10000 microseconds, and 1000000 model time units are allocated for testing.\nThe messages are typical from TRON standard output stream when bit-flag 2 is selected in -v option:\n1. TEST: delay to [245.. on 1 2. TEST: grasp()@1225896-1225940 at [245..246) on 1 3. TEST: level(0)@1771740 at [353..356) on 5 4. TEST: level(1)@2752912 at [549..552) on 3 5. TEST: level(2)@3777576 at [755..756) on 3 6. TEST: level(3)@4798399 at [959..960) on 3 7. TEST: delay to [1153.. on 3 8. TEST: delay to [1159.. on 3 9. TEST: release()@5798049-5798094 at [1159..1162) pre\u003e 10. TEST: delay to [1169.. on 13 11. TEST: delay to [1175.. on 13 Lines 20, 26-27, 29-30 mean that TRON has chosen a delay and nothing happened until it has expired, for example line 20 says that TRON is applying a delay on a current state set to the moment of 245 model time units on a single (1) state in a set, the upper bound of a delay is open and bounded only by future horizon (see -F). Line 21 says that TRON is applying the input event on channel grasp it has just executed at time interval 1225896-1225940 microseconds which is mapped to model time interval [245..246) in Uppaal constraint encoding. The encoding [245..246) means a model time interval (122,123) as 245/2=122.5 (remainder shows that the constraint is strict, i.e. \u0026gt;122, and the point 122mtu is not included) and 246/2=123 which is strict as \u0026ldquo;)\u0026rdquo; in the log. The same mapping and encoding procedure applies to outputs on lines 22-25 which show that output events on channel level have variable values attached (0, 1, 2 and 3). The output is time-stamped right after it is registered in the driver. The inputs are time-stamped with two time-stamps: just before offering an input and right after the input is offered, to reflect an over-approximation and uncertainty on when exactly it was actually delivered at (remote) IUT.\nVerdict Assignment and Diagnostics At the end of testing TRON will issue a verdict, which is either PASSED, INCONCLUSIVE or FAILED. PASSED means that the timeout for testing has expired and no faulty behavior has been detected. Test may fail with verdict FAILED if IUT exposes the behavior which could not be mapped in the model of IUT, i.e. if IUT reported wrong output at wrong time (too early or too late) or IUT did not respond at all when it was required to respond with some output. In case of INCONCLUSIVE verdict, TRON is either 1) confused with the output observed from IUT, cannot map this output to the model of environment and hence does not know how to continue testing or 2) late for delivering an input in time as required by the model of environment. The second option can be very frequent on heavily loaded machines, broken schedulers (Windows tend to issue spurious timeouts even if timeout did not expire) while testing in real time using the host machine\u0026rsquo;s clock. Also it is still not clear how to handle situations when TRON and IUT rely on different clocks which drift away from each other, hence we rely on assumption that TRON is operating on a correct (reference) clock.\nTRON can also provide additional information on why the test ended up with verdict FAILED or INCONCLUSIVE if the bit-flag 8 is specified on -v option. The following is a typical output of such diagnostic information:\n1. Short post-mortem analysis based on last good stateSet(3): 2. 1) 3. ( interface.touching switch.idle dimmer.PassiveUp user.busy graspAdapter._id26 ... ) 4. interface.x\u003e47, dimmer.x\u003e260, user.z\u003e52, graspAdapter.x\u003e52, ... 5. on=1 iutLevel=5 OL=7 adapLevel=5 user.L=5 6. 2) 7. ( interface.holding switch.idle dimmer._id10 user.busy graspAdapter._id26 ... ) 8. interface.x\u003e=50, user.z\u003e52, graspAdapter.x\u003e52, releaseAdapter.x\u003e162, ... 9. on=1 iutLevel=7 OL=7 adapLevel=5 user.L=5 10. 3) 11. ( interface.holding switch.idle dimmer.Up user.busy graspAdapter._id26 ... ) 12. interface.x\u003e=50, user.z\u003e52, graspAdapter.x\u003e52, releaseAdapter.x\u003e162, #t\u003e5937, ... 13. on=1 iutLevel=7 OL=7 adapLevel=7 user.L=5 14. Options for input : (empty) 15. Options for output : level@[11875..11894) 16. Options for internal: starthold@[11875..13770), setLevel@[11875..11890) 17. Options for delay : ..13770) 18. Last time-window : [11987..11990) 19. Could not delay any more (to the last time-window). 20. Output expected: level(7)@0-0[11875..11894) 21. TEST FAILED: IUT failed to produce output in time 22. Time elapsed: 5993 tu = 59.939325s 23. Time left: 994007 tu = 9940.060675s 24. Random seed: 1163420344 25. AdapterConnection died: socket closed upon read Line 31 says the following analysis is based only on the last good state (might be inaccurate if fault happened much earlier than observed) consisting of 3 symbolic states. Lines 32-43 enumerate the symbolic states (it can be very long, this is a shortened version of it), for example line 32 specifies the symbolic state number 1, line 33 says in which control locations the processes are, line 34 enumerates clock constraints and line 35 enumerates values of integer variables. Lines 44-47 reiterates what options TRON was facing just before test has terminated: line 44 says that there could be no inputs offered, line 45 says that according to model the output level is expected at model time interval (5937,5947) (as 11875/2=5937.5 and 11894/2=5947 in Uppaal encoding), line 46 enumerates internal transitions available in the model, line 47 specifies the longest possible delay until 6885mtu without observable input/output. Line 48 says that TRON was trying to compute the reachable symbolic state set for the interval (5993,5995), but according to line 49 it could not, as the resulting symbolic state set contained no states. Line 50 notes that there was level(7) output expected at (5937,5947) therefore the conclusion in line 51 is that IUT failed to produce output (in required time). Lines 52-53 show how long test was running and how much left to testing timeout in model time units and seconds. Line 54 shows the random seed used to start the pseudo-random number generator (see -X option). Line 55 contains spurious exception upon disposing SocketAdapter which can be safely ignored.\nAs of version 1.4 be aware of bug 369 in diagnosis.\nAdaptation In this section we are going to show the adaptation process for TRON framework. We are going to use the smart lamp light controller example to highlight the supported features and to show how to use them.\nModel Specification TRON supports abstract requirement models in a sense that implementation under test (IUT) does not necessarily have to follow the structure of the model. User should use Uppaal to specify requirements by creating a timed automata model of the whole (closed) system, i.e. the model should contain requirements for the IUT and also the assumptions about its environment (user). The processes in Uppaal timed automata network communicate via channels. Every channel synchronization is an instantaneous event in the system, taking zero time as any other transition. So the simplest closed system suitable for testing using TRON consists of at least two communicating processes: IUT process and environment process. In this simple system the input event is fired whenever environment process shouts at some channel and IUT receives the channel synchronization, the output happens in the same manner but opposite direction.\nThe model of environment can be as simple as one process containing one location with a synchronized transition loop for each input/output channel synchronization. Such environment would test the most of IUT features/requirements as it is fully permissive, however this might be too expensive and unrealistic, especially if environment assumptions can be stated more precisely, e.g. modeling some case of system usage. It is important that environment is input enabled, i.e. it is able to consume any possible output produced by IUT, otherwise TRON will issue verdict \u0026ldquo;inconclusive\u0026rdquo; in case the received output event cannot be applied to environment.\nIn a more complex system the IUT (and environment) requirements may be modelled by many processes. In this case the system is partitioned into two sets of processes: the processes modelling the requirements for IUT (model of IUT) typically mimicking what the IUT should do and the processes for the environment assumptions (model of environment) mimicking what the tester should do. The IUT (environment) processes may communicate among themselves by channel synchronizations too, but such communication is treated as internal and not observable. The channel synchronization is treated as observable input/output event if and only if it is between the environment and IUT processes.\nAs noted before, the channel synchronization is an instantaneous event in timed automata network, hence the communication between the environment and the IUT is also treated as instantaneous. However real-time black-box testing is also a kind of remote testing, where the inputs/outputs are fed at one time instance and received slightly later as there is at least small communication delay. Even the slightest delay of electronic signal running short distance at a speed of light is significant as it might imply a different input and output event interleaving and hence a different outcome. The communication delay is especially significant on soft-real-time operating systems (such as Windows and Linux) where the process scheduling is a major contributor but is hardly predictable (Linux scheduler tries hard to be at most 10ms late and 2.6 branch usually fits into 1ms delay under low load conditions, see Latency Experiments). Currently TRON time-stamps the input and output events when they arrive/leave TRON process, hence the model of IUT should also include the processes of adapter proxying and slightly delaying the actual input and output to reflect such communication reality. The model of adapter also helps to make sure that the model of IUT is input enabled, i.e. IUT cannot refuse to accept the offered input, which might be important in testing features that are triggered only by that particular input (and time). TRON will not try to offer an input if the model of IUT is not able to consume it.\nThe model of the system should be validated in the Uppaal symbolic simulator to make sure the model reflects an intended system behavior and the verifier should be used to check at least that model does not contain deadlocks (\u0026ldquo;A[] not deadlock\u0026rdquo; must be satisfied). In extreme cases where system state space is too large and cannot be verified (e.g. adapter processes involve queueing of input/output events and hence blowup the state space), a more abstract version of the model should be verified. TRON might issue verdict \u0026ldquo;inconclusive\u0026rdquo; or \u0026ldquo;failed\u0026rdquo; if it runs into deadlock situation and/or give unreliable \u0026ldquo;last good state set\u0026rdquo; diagnostic information if deadlock is present but was avoided by taking other transitions.\nExample. Consider the smart lamp demo with the following model of the system: LightContr.xml (you are encouraged to load it into Uppaal). I will use the signal flow diagram LightContr.png to demonstrate how processes in this system communicate (see Test Interface Specification to produce signal flows of your own). The legend of this signal flow diagram is as follows: ellipse means process, rectangle means integer variable, diamond means channel, arrows indicate the flow of signal, i.e. process transmit on given channel if arrow is from ellipse to diamond, process receives on given channel if arrow is from diamond to ellipse, variable is being written by process if arrow points from ellipse to rectangle and variable is being read if arrow is from rectangle to ellipse. The labels on arrows indicate the channel synchronization when variable is accessed, dash means silent (internal) access without channel synchronization. TRON uses the observable input/output channel (double diamonds) declaration (see Test Interface Specification) to partition the system into the model of environment (light green items) and the model of IUT (light blue items). In this example, environment consists of user process communicating through input channels grasp and release and output channel level. The requirements for IUT are modeled by interface, dimmer and switch processes. The communication delay is modeled by levelAdapter, releaseAdapter and graspAdapter processes.\nTest Interface Specification Test interface is a set of observable input and output channels possibly with integer variables values bound to channel. Observable input and output channels define how the system model is partitioned into the model of IUT and the model of environment. The correct system partitioning is important in order to ensure correct verdict computation by using relativized timed input/output conformance relation (which means identifying and special treatment of IUT invariants which might interact with environment model as invariants are global in Uppaal semantics). The idea of correct partitioning is a complete and consistent separation of environment model and IUT model by inspecting the following control rules:\nChannels, that are not declared as inputs/outputs, are non-observable called internal. Internal channel belongs to environment (IUT) if it is used by environment (IUT) process (respectively). Model is inconsistent and cannot be partitioned if the internal channel is used by both environment and IUT. Process belongs to environment (IUT) if it uses the internal environment (IUT) channel (respectively). Variable belongs to environment (IUT) if it is accessed by environment (IUT) process without observable input/output channel synchronization. Variable is not cathegorized (can be either) if accessed consistently only during observable input/output channel synchronization. Process belongs to environment (IUT) if accesses environment (IUT) variable (respectively) without observable channel synchronization. It might be tricky to get complete and consistent (all processes are assigned to either IUT or environment) partitioning. Currently the adapter API is the only way to specify the test interface. The easiest way to experiment with test interface and partitioning is by generating signal flow diagram of the system. The signal flow diagram in graphviz format can be obtained from TRON standard output with -i dot option on specific Uppaal model and entering the test interface information via standard input in the following tiny EBNF grammar (terminals are quoted in bold, this grammar is also used in TraceAdapter):\nTIS ::= inputs outputs precision timeout inputs ::= **\"input\"** channels **\";\"** outputs ::= **\"output\"** channels **\";\"** precision ::= **\"precision\"** integer **\";\"** timeout ::= **\"timeout\"** integer **\";\"** channels ::= | channel ( **\",\"** channel )* **\";\"** channel ::= channelname **\"(\"** variables **\")\"** variables ::= | variablename ( **\",\"** variablename )* Here, the precision specifies the duration of one model time unit (mtu) in microseconds and timeout specifies how many model time units is allocated for testing. Upon success TRON will terminate with verdict \u0026ldquo;passed\u0026rdquo; when precision × timeout microseconds elapse and no fault is found.\nExample. The following command lines produce signal flow in graphviz format which is further laid-out onto the PNG picture format by dot utility, the third line does it all in one:\ntron -i dot [LightContr.xml](LightContr.xml) \u003c [LightContr.trn](LightContr.trn) \u003e [LightContr.dot](LightContr.dot) dot -Tpng -o [LightContr.png](LightContr.png) [LightContr.dot](LightContr.dot) tron -i dot [LightContr.xml](LightContr.xml) \u003c [LightContr.trn](LightContr.trn) | dot -Tpng -o [LightContr.png](LightContr.png) Note that TRON also adds a few constraints for the graph layout in dot file, in particular it specifies landscape A4 paper, which is handy for -Teps option but might not be good for some larger models.\nIf partitioning is not complete (some process, variable or channel is assigned to neither IUT nor environment) or inconsistent (according to rules some item is assigned to both IUT and environment) then TRON will write complains and warnings to the standard error stream. The verbosity of partitioning messages is controlled by -v option: -v 0 \u0026ndash; none, -v 1 \u0026ndash; errors, -v 2 \u0026ndash; warnings, -v 3 \u0026ndash; diagnostics. The diagnostic messages will show how TRON is trying to partition the processes, variables and channels by iteratively applying the control rules. It is also recommended to check the separation in the output stream from TRON once the test interface is specified during testing.\nCurrently (as of version 1.4 Beta 2) the variable usage in C-code functions is not analyzed, hence partitioning might work incorrectly. Also observable broadcast channels should be used with caution (IUT/environment cannot send and receive at the same time on observable broadcast channel). The source code for signal flow static analysis and partitioning will probably be available in the next release of UTAP library.\nObservation Uncertainties TRON is applying observable input and output events by the following algorithm: 1) time-stamp the event with the host machine clock, 2) convert to a model time representation in floating point number form 3) find the closest integers to the given floating point number 4) apply input/output event to the model state space as if it happened between the closest integers time points. Observation uncertainty is a tweak for such time-stamping scheme, which expands and shifts the time-stamping interval: the output event is expanded to the direction of past (as if it happened earlier than observed), the input event is expanded to the direction of future (as if it will happen later than it is actually sent). The observation uncertainty was an early idea to reduce state space explosion due to adapter models and still be able to handle the communication and scheduling latency.\nThe observation time uncertainty can be specified by -u option, see the output of tron -h. The parameters inpDelay and outDelay control how many microseconds the event time window is shifted and parameters inpRes and outRes specify how many microseconds the window is be expanded, which potentially might touch or cover a next time unit(s). Current implementation (1.4 Beta 2) does not treat the time-stamp shifts correctly as it is required to create a hole in a state space between possible outputs in the past and possible inputs, hence requires a more complicated state exploration algorithm. Values other than 0 for inpDelay and outDelay are not recommended. The values for inpRes and outRes should reflect the scheduling and communication latency, e.g. allow about 3000-4000 microseconds on Linux-2.6 (may vary on different machines).\nObservation uncertainty is relevant only in testing in real world time and is irrelevant in virtual time.\nBuilding Test Adapter Normally, when TRON process is launched for testing the following happens:\nTRON parses and sets the command line options TRON looks for Uppaal timed automata model and loads it. TRON looks for adapter specified and attempts to create it via constructor call by passing a reporter object handle. Adapter constructor establishes connection to IUT (possibly launching another IUT process/thread, or simply connecting to remote IUT process). Adapter constructor configures the testing interface by declaring observable input/output channels, binding needed variables, sets the precision and the timeout for testing and returns the adapter handle to TRON. TRON statically analyzes the model and partitions the system into IUT and environment. TRON calls adapter.start() routine to indicate that no problems were found, adapter should finish any initializations and testing begins from the moment thread returns to TRON. Further input and output communication is asynchronous in a sense that IUT should use its own thread to report outputs to the reporter (which in turn will time-stamp and queue it) and TRON will call the method to register input (IUT is expected to add input to its input queue, notify its thread and return as soon as possible). Caution: adapter interface may deadlock if the same input-offering-thread (from TRON) is used by adapter to report the output from IUT. It is also important to release the lock on input queue (if any) in IUT adapter when reporting outputs to allow TRON to offer input while the output is being reported. After test is finished (via timeout or failure), TRON calls the adapter destructor to disconnect from IUT, cleanup and release all the resources. Currently there are a few different adapter examples available as reference implementations, depending on platform and adapter method the actual action names may differ:\nTextual communication via standard I/O adapter (virtual time recommended). See source code using TraceAdapter in tracer directory under GNU environment (requires bash, GNU make, use Cygwin if on Windows). TraceAdapter uses the ANTLR lexer and parser to read the standard input stream (see how \u0026ldquo;make testsuite\u0026rdquo; example works for example traces accepted by TraceAdapter, it\u0026rsquo;s even possible for human to interact with TRON). TCP/IP socket adapter for remote IUTs (both: virtual and real time). See Java source code of smart-lamp using SocketAdapter in java directory, java-doc. Remote adapter implementation in C/C++ can also be provided upon a request. Microsoft Visual C library adapter example (currently only real time). See source code of mouse button example in MSVC directory. GNU C library adapter example on Unix (both: virtual and real time). See source code of mouse button example in button directory. Virtual Time Much of real-time control software concerns mainly correct timing and functional behavior and time spent on computation is negligible or predictable. TRON\u0026rsquo;s virtual time framework offers a possibility to test a real-time application in laboratory conditions where time flow is controlled, i.e. time is allowed to flow when all processes are explicitly waiting and is stopped when at least process is busy computing. Virtual time framework has an advantage that otherwise inherent latencies (OS scheduling, communication) are removed.\nThe idea is based on a concept of monitor, where mutex locking and unlocking wrap a negligible amount of atomic computations and temporary mutex release by waiting on conditional variable reflects the process\u0026rsquo; intent to delay and wait for a specific condition.\nBy default TRON assumes host machine\u0026rsquo;s real time clock and virtual time clock can be turned on by option -Q log which also opens a server socket on port 6521 to serve any remote request for virtual clock. User can also change the port number to 1234 by using option -Q 1234 instead, just make sure that remote IUT will also use the same port number. Reference Java client implementation of remote virtual time clock can be found in java/tron/VirtualThread.java file.\nPOSIX C Example POSIX (Portable Operating System Interface for uniX) way of creating a monitors is by using pthread_mutex_lock, pthread_mutex_unlock, pthread_cond_wait and pthread_cond_timedwait functions (see their manual pages e.g. on your Linux distribution). TRON binary (on Linux) exports the following substitute functions which call the OS\u0026rsquo;s POSIX layer when testing in real time and uses virtual TRON\u0026rsquo;s clock when testing in virtual time:\ntron_thread_create instead of pthread_create tron_mutex_init instead of pthread_mutex_init tron_mutex_destroy instead of pthread_mutex_destroy tron_mutex_lock instead of pthread_mutex_lock tron_mutex_unlock instead of pthread_mutex_unlock tron_cond_init instead of pthread_cond_init tron_cond_destroy instead of pthread_cond_destroy tron_cond_wait instead of pthread_cond_wait tron_cond_timedwait instead of pthread_cond_timedwait tron_cond_signal instead of pthread_cond_signal tron_cond_broadcast instead of pthread_cond_broadcast tron_gettime instead of gettimeofday There are also functions to temporarily remove the current running thread from virtual time accounting and put it back to the pool of virtual time threads: tron_thread_deactivate and tron_thread_activate. These functions are not normally used, and exist only to simplify design of remote adapters like SocketAdapter.\nJava Example Example in java directory provides tron.VirtualLock class for controlling the state of (potentially remote) lock and creating tron.VirtualCondition variables. TRON\u0026rsquo;s monitor paradigm is very similar to Java\u0026rsquo;s synchronized methods, except that all participating threads should be created via tron.VirtualThread object, locking, unlocking, waits and notifications (signals) should be done explicitly on corresponding VirtualLock and VirtualCondition objects. See java-doc for more.\n"}] \ No newline at end of file +[{"uri":"/gui-reference/yggdrasil/tutorial/basic-test-generation/","title":"Basic Test Generation","tags":[],"description":"","content":" Create the models Open the On/Off System model \u0026ldquo;onoff/onoff.xml\u0026rdquo; file in Uppaal. The system contains two templates entitled System and User. The System represents the system or device (e.g. lamp) under test. The User models the possible user interactions with the system.\nThe system can be either On or Off, with channels on and off changing between them. The user can non-deterministically press on or off.\nSystem template User template Add Test Cases specific model annotations First, some Test Cases specific declarations muse be made; these are required for the generator to use depth-first reachability and single step techniques for test-case generation. These variables must not be altered in the model. Hence, these two variables must be declared in the global Declarations section:\nint __reach__ = 0; int __single__ = 0; Add test pre-fix and post-fix code Second, there are two blocks of comments in the System declarations section of the model. The contents of a multi-line comment starting with TEST_PREFIX or TEST_POSTFIX are ejected as prefix code (before the actual test case behavior) or postfix code (after actual test case behavior) for each test case.\nIn this example each test case is a Java class with a main method; executing this Java class constitutes running the test case. Therefore the prefix and postfix code is the wrapper code to setup this Java class.\n/** TEST_PREFIX package app; import app.App; class Test extends App { public static void main(String[] args) { */ /** TEST_POSTFIX } } */ The test case class extends the App class we are testing. If you use a specific unit test framework, these lines should be changed to match its requiements. Each step in the test case will execute some methods on this class.\nBy default, test cases will be named and sequentially numbered like testcase0.code. If desired, the filename and file extension can be changed by the following special comments in the System declarations section. For now, stay with the defaults.\n/** TEST_FILENAME test- */ /** TEST_FILEEXT .txt */ Add test step code annotations The system model must be decorated with test code. Double clicking the edge labeled on? and selecting the Test Code tab reveals an area for entering test code. In this model the test code should be set_on();. This will execute the method set_on() on the application whenever this edge is taken in a test case. Similarly, set_off(); is added to the edge labeled off?.\nFor locations, test code can be entered in two areas, Enter and Exit. This test code is added to the test case when the trace reaches the location or leaves it, respectively.\nAdding edge test code Adding location test code Generating the test cases To generate test cases go to the Test Cases tab. You may need to enable the tab in the GUI first.\nEnable Test Cases Tab Test Cases Tab Select which techniques for test case generation to use. For now only select the auto-depth search mode with a depth of 20, and click add.\nClicking add should generate a single trace. Each trace generated will have a line in the list similar to Trace coverage: 4/4. This shows that the trace covered four out of four edges. Further information about which locations and edges are/are not covered are shown in the Statistics panel to the right. Here, all of the 3 locations and 4 edges are trivially covered.\nBy double clicking the trace and selecting the Simulator tab, the trace can be examined. Unsurprisingly, the trace simply runs in circles with alternating on/off presses.\nNext output the test cases to the file by clicking Save Test Cases. Select the output folder for test cases. Make this point to the onoff folder in this tutorial. Inspecting the test case code Pressing the Save Test Cases button in the Test Cases tab will generate a file called testcase0.code in the selected output folder. If several traces have been generated, several files will be generated with sequential numbering.\nEach of these will be a Java class with the sequence of method invocations induce by the generated trace. A snippet is shown below.\n1: package app; 2: import app.App; 3: 4: class Test extends App { 5: 6: public static void main(String[] args) { 7: 8: expect_off(); 9: 10: set_on(); 11: 12: expect_on(); 13: 14: set_off(); 15: \u0026lt;... snip ... \u0026gt; 93: 94: } 95: } The test case starts with the prefix code on lines 1-6. Line 8 is the first step of the trace. This is expect_off(); since the initial location is Off. The first transition is the one labeled on?, the test code for this transition is set_on();. This is entered in the trace at line 10. The trace then enters location On and expect_on(); is in the test case at line 12. The test case continues in this fashion. The trace ends with the postfix code on lines 94-95. Exectuting the test cases Running the test.sh (or test.bat on Windows) will compile and run the test cases one at a time. It will output the name of each file as it executes them. No output from the test case signifies successful execution.\nonoff$ ./test.sh testcase0.code onoff$ Running the testMutant.sh (or testMutant.bat on Windows) will compile and run the test cases on the mutant (intentionally wrong) implementation. This should result in an exception being thrown, signifying a test error.\nonoff$ ./testMutant.sh testcase0.code Exception in thread \"main\" java.lang.AssertionError at app.App.expect_on(App.java:17) at app.Test.main(Test.java:15) onoff$ The implementation code can be examined in the onoff/app folder. See file onoff/app/AppC.java for the correct implementation and onoff/app/AppM.java for the mutant.\nIn order to transfer this to you own applications, you will have to decorate the model with test code such that the output from the generator constitutes an executable test case in whatever test execution framework you use.\n"},{"uri":"/language-reference/system-description/declarations/","title":"Declarations","tags":[],"description":"","content":"Declarations are either global or local (to a template) and can contain declarations of clocks, bounded integers, channels (although local channels are useless), arrays, records, and types. The syntax is described by the grammar for Declarations:\nDeclarations ::= (VariableDecl | TypeDecl | [Function] | [ChanPriority])* VariableDecl ::= [Type] VariableID (\u0026#39;,\u0026#39; VariableID)* \u0026#39;;\u0026#39; VariableID ::= ID [ArrayDecl]* [ \u0026#39;=\u0026#39; Initialiser ] Initialiser ::= [Expression] | \u0026#39;{\u0026#39; Initialiser (\u0026#39;,\u0026#39; Initialiser)* \u0026#39;}\u0026#39; TypeDecls ::= \u0026#39;typedef\u0026#39; Type ID ArrayDecl* (\u0026#39;,\u0026#39; ID ArrayDecl*)* \u0026#39;;\u0026#39; The global declarations may also contain at most one channel priority declaration.\nExamples const int a = 1; constant a with value 1 of type integer. bool b[8], c[4]; two boolean arrays b and c, with 8 and 4 elements respectively. int[0,100] a=5; an integer variable with the range [0, 100] initialised to 5. int a[2][3] = { { 1, 2, 3 }, { 4, 5, 6} }; a multidimensional integer array with default range and an initialiser. clock x, y; two clock variables x and y. chan d; a channel variable. urgent chan e; an urgent channel variable which forces the transition to be taken as soon as it is enabled. struct { int a; bool b; } s1 = { 2, true }; an instantiation of the structure from above where the members a and b are set to 2 and true. meta int swap; int a; int b; Update: swap = a; a = b; b = swap; a meta variable swap is used to swap the contents of two integers a and b. The value of a meta variable is stored outside the state space (hence saves some state memory), but its value is valid only during one transition (e.g. transfering value between synchronizing processes). Currently struct can\u0026rsquo;t contain members of type double or clock.\nType Declarations The typedef keyword is used to name types.\nExample The following declares a record type S containing an integer a and a boolean b members:\ntypedef struct { int a; bool b; } S; "},{"uri":"/gui-reference/menu-bar/file/","title":"File Menu","tags":[],"description":"","content":"The leftmost menu of the menu bar is the file menu. It is mainly used to open and save (part of) system descriptions or requirement specifications created in UPPAAL. The available items are:\nNew System: re-initiates the editor with an empty system. Open System: loads an existing system from file. The corresponding requirement specification (i.e. same file name but with the suffix .q) is loaded into the verifier, if it exists. Save System: saves the system in the editor to file. Save System As: saves the system in the editor to a specified file. Import Template: imports template(s) from an existing system description. A dialog window is shown which allows a subset of the available templates to be imported. Export Template: exports the currently edited template in Encapsulated Postscript format to file. New Queries: re-initiates the requirement specification editor with an empty file. Open Queries: loads an existing set of requirement specifications from file. Save Queries: saves the requirement specifications in the editor to file. Save Queries As: saves the requirement specifications in the editor to a specified file name. Exit: exits UPPAAL. "},{"uri":"/gui-reference/yggdrasil/traces/","title":"Generating Traces","tags":[],"description":"","content":"Traces are generated using three purposes: queries, depth search, and individual edges.\nIn the Verifier tab the existential queries (E\u0026lt;\u0026gt;) can be used to specify a desired functionality to be tested and hence can be selected as a test purpose for test case generation. All or specific queries can be selected and the resulting trace is added to be used as a test case.\nThe second option uses heuristics of random depth first search of the specified number of steps with a hope of increasing the coverage. The resulting trace is used as a test case. The search process is repeated until the newly generated trace does not contribute new coverage over the previous traces. In order to use this method a global integer variable named __reach__ must be declared, initialized to zero and should not be used anywhere in the model. The number of steps depends on the model (size and depth of the model) and application domain (how long test cases are acceptable). If depth is configured too small there is a risk that many edges wil not be covered. If depth is configured very high, needlessly long test cases will be generated.\nThe third option attempts to cover the remaining edges which are not covered by the previously generated traces. This method submits a separate reachability query for each uncovered edge. Large models may have many edges, and therefore many queries may take a long time to execute. Even worse: some edges might be unreachable at all and thus require exhaustive search which may consume a lot of time and memory. In order to use this method a global integer variable named __single__ must be declared, initialized to zero and should not be used throughout the model.\n"},{"uri":"/gui-reference/","title":"GUI Reference","tags":[],"description":"","content":"Chapter 1 GUI Reference Discover the UPPAAL gui.\n"},{"uri":"/language-reference/expressions/identifiers/","title":"Identifiers","tags":[],"description":"","content":"The valid identifier names are described by the following regular expression: [a-zA-Z_]([a-zA-Z0-9_])*\nExamples a, B, c2, d2 valid identifier names. 1, 2a, 3B, 4c5 invalid identifier names. "},{"uri":"/language-reference/system-description/templates/locations/","title":"Locations","tags":[],"description":"","content":"Locations of a timed automaton are graphically represented as circles. If a timed automaton is considered as a directed graph, then locations represent the vertices of this graph. Locations are connected by edges.\nNames Locations can have an optional name. Besides serving as an identifier allowing you to refer to the location from the requirement specification language, named locations are useful when documenting the model. The name must be a valid identifier and location names share the name space with variables, types, templates, etc.\nInvariants Locations are labelled with invariants. Invariants are expressions and thus follow the abstract syntax of expressions. However, the type checker restricts the set of possible expressions allowed in invariants.\nAn invariant must be a conjunction of simple conditions on clocks, differences between clocks, and boolean expressions not involving clocks. The bound must be given by an integer expression. Furthermore lower bounds on clocks are disallowed. It is important to understand that invariants influence the behaviour of the system \u0026ndash; they are distinctly different from specifying safety properties in the requirements specification language. States which violate the invariants are undefined; by definition, such states do not exist. This influences the interpretation of urgent channels and broadcast channels. Please see the section on synchronisations for a detailed discussion of this topic.\nIn addition, stop-watches are supported and they are declared with invariants. Clock rate expressions are specified and they are part of the conjunction in the invariant. Furthermore, the forall construct is accepted in invariants to ease use of arrays.\nStatistical model checker supports any integer expression as a clock rate which allows modeling costs.\nRate of Exponential The rate of exponential is a ratio expression which specifies the rate of exponential probability distribution. The rate expression can be a simple integer expression or two integer expressions separated by a colon like r:q where the rate is determined as ratio r/q.\nThe rate of exponential is used in a statistical model checking. If the location does not have an invariant over time, then it is assumed that the probability of leaving the location is distributed according to the exponential distribution: Pr(leaving after t)=1−e−λt, where e=2.718281828…, t is time and λ is the fixed rate. Probability density of the exponential distribution is λe−λt and thus intuitively λ means the probability density of leaving at time zero, i.e. as soon as some edge is enabled. The smaller the rate is specified, the longer the delay is preferred.\nThe generation of exact delay relies on pseudo random number generator and on 32-bit architectures the longest possible delay is rather limited: ln(231)/λ ≈ 21.49/λ.\nExamples The following are valid invariants. Here x and y are clocks and i is an integer array.\nx \u0026lt;= 2 x is less than or equal to 2. x \u0026lt; y x is (strictly) less than y. forall(i:int[0,2]) x[i] \u0026lt;= 3 The clocks x[0], x[1] and x[2] of the clock array x are less or equal to 3. forall(i:int[0,2]) y[i]' == b[i] The clock rates y[0]', y[1]', and y[2]' are set to, respectively, b[0], b[1] and b[2]. Note that for symbolic queries the only valid values are 0 and 1. Setting the rate to 0 effectively stops a clock (makes it a stop-watch). In statistical model checking the rate is allowed to be any floating point value. hybrid clock can be interpreted as a continuous cost and abstracted away in symbolic queries while maintaining concrete values in statistical queries. Initial locations Each template must have exactly one initial location. The initial location is marked by a double circle.\nUrgent locations Urgent locations freeze time; i.e. time is not allowed to pass when a process is in an urgent location.\nSemantically, urgent locations are equivalent to:\nadding an extra clock, say x, that is reset on every incomming edge, and adding an invariant x \u0026lt;= 0 to the location. Committed locations Like urgent locations, committed locations also freeze time. Furthermore, if any process is in a committed location, the next transition must involve an edge from one of the committed locations.\nCommitted locations are useful for creating atomic sequences and for encoding synchronization between more than two components. Notice that if several processes are in a committed location at the same time, then they will interleave.\n"},{"uri":"/gui-reference/menu-bar/","title":"Menu Bar","tags":[],"description":"","content":"The menu bar is located in the upper part of the main window or at the top of the screen. It contains the following menu items:\nFile Menu Edit Menu View Menu Tools Menu Options Menu Help Menu "},{"uri":"/gui-reference/system-editor/navigation-tree/","title":"Navigation Tree","tags":[],"description":"","content":"The navigation tree is shown in the left panel of the system editor. It is used for accessing the various components of a system description. A node in the tree can be double clicked to view (or hide) the sub tree of the node. The root of the navigation tree is named Project.\nThe sub node Declarations is used for declarations of global scope. They can be referred to directly in template declarations.\nEach process template of the system description is represented by a node placed under the root node of the navigation tree. When this node is selected (i.e. clicked) the automaton becomes available for editing in the right panel of the system editor. Each template has a sub node named Declarations that is used for typing in local declarations and documentation comments.\nThe remaining sub node of the root, named System declarations is used for further declarations, process assignments, and the system declaration.\nNote: the navigation tree can be opened in a separate window using the \u0026ldquo;Drag out\u0026rdquo; button. The window returns to its original position when it is closed.\n"},{"uri":"/language-reference/query-semantics/symb_queries/","title":"Semantics of the Symbolic Queries","tags":[],"description":"","content":"In the following we give a pseudo-formal semantics for the requirement specification language of UPPAAL. We assume the existence of a timed transition system (S, s0, →) as defined in the semantics of UPPAAL timed automata. In the following, p and q are state properties for which we define the following temporal properties:\nSee also Syntax of Symbolic Queries.\nPossibly The property E\u0026lt;\u0026gt; p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → \u0026hellip; → sn, where s0 is the initial state and sn satisfies p.\nInvariantly The property A[] p evaluates to true if (and only if) every reachable state satisfy p.\nAn invariantly property A[] p can be expressed as the possibly property not E\u0026lt;\u0026gt; not p.\nPotentially always The property E[] p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → \u0026hellip; → si → \u0026hellip; for which p holds in all states si and which either:\nis infinite, or ends in a state (Ln, vn) such that either for all d: (Ln, vn+d) satisfies p and Inv(Ln), or there is no outgoing transition from (Ln, vn) Eventually The property A\u0026lt;\u0026gt; p evaluates to true if (and only if) all possible transition sequences eventually reaches a state satisfying p.\nAn eventually property A\u0026lt;\u0026gt; p can be expressed as the potentially property not E[] not p.\nLeads To The syntax p --\u0026gt; q denotes a leads to property meaning that whenever p holds eventually q will hold as well. Since UPPAAL uses timed automata as the input model, this has to be interpreted not only over action transitions but also over delay transitions.\nA leads to property p --\u0026gt; q can be expressed as the property A[] (p imply A\u0026lt;\u0026gt; q).\nState Properties Any side-effect free expression is a valid state property. In addition it is possible to test whether a process is in a particular location and whether a state is a deadlock. State proprerties are evaluated for the initial state and after each transition. This means for example that a property A[] i != 1 might be satisfied even if the value of i becomes 1 momentarily during the evaluation of initializers or update-expressions on edges.\nLocations Expressions on the form P.ℓ, where P is a process and ℓ is a location, evaluate to true in a state (L, v) if and only if P.ℓ is in L.\nDeadlocks The state property deadlock evaluates to true for a state (L, v) if and only if for all d ≥ 0 there is no action successor of (L, v + d).\nProperty Equivalences The UPPAAL requirement specification language supports five types of properties, which can be reduced to two types as illustrated by the following table.\nName Property Equivalent to Possibly E\u0026lt;\u0026gt; p Invariantly A[] p not E\u0026lt;\u0026gt; not p Potentially always E[] p Eventually A\u0026lt;\u0026gt; p not E[] not p Leads to p --\u0026gt; q A[] (p imply A\u0026lt;\u0026gt; q) "},{"uri":"/gui-reference/concrete-simulator/simulation-control/","title":"Simulation Control","tags":[],"description":"","content":"The simulation control is the left panel of the simulator. It is used to control the simulation and to select the state or transition to be visualized in the others panels of the simulator. The control panel is divided in two parts:\nThe upper part is used for performing step-by-step simulation. The Transition chooser area is a clickable area where vertical axis displays the active transitions at this location and horizontal axis displays the time at which the transition will be fired. The time interval where a transition is enabled and the time interval where a transition is selectable are colored in different way. The time interval in which a transition can be fired (where the transition is selectable) is delimited by markers: one small circle at the beginning and one at the end of the interval (full if it is close, empty if it is open). When the mouse move to a selectable area, the color of the interval become brighter. By clicking one can select a specific transition and a specific time for firing the transition. The selected transition will be highlighted. The time selected is displayed in the Delay-combo box. One can also specified directly the time in the Delay-combo, once the transition has been selected. If one click in a non-selectable zone of a transition, the tool chooses the closest valid time. The Reset Delay-button is used to reset the delay to zero. Pressing the Take transition-button causes the simulated system to fire the selected transition at the specified time. The Reset-button is used to reset the simulated system to its initial state.\nThe lower part of the control panel, the Simulation Trace area, has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.\nThe Simulation Trace area contains a combo box that displays the current time (according to the hightlighted state in the trace) and the following buttons:\nFirst: highlights the first element in the trace. Last: highlights the last element in the trace. Prev: highlights the element immediately preceding the current selection (if any) in the trace. Next: highlights the element immediately following the current selection (if any) in the trace. Play: replays the trace starting from the currently selected element. Open: opens a file dialog for loading a trace from file. Save: opens a file dialog for saving the current trace on file. The valid file extension is \u0026ldquo;uctr\u0026rdquo;. When no file extension is provided, it will be automatically appended. Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions at random time. The slider is used to control the speed used when traces are replayed and when random simulation is performed.\nKeyboard Shortcuts Key Shortcut to Q Correspond to the button Prev. A Correspond to the button Next. P Correspond to the button Replay. R Correspond to the button Random. F Correspond to the button First. L Correspond to the button Last. "},{"uri":"/gui-reference/verifier/specifying/","title":"Specifying Requirements","tags":[],"description":"","content":"An overview of the system requirements (called queries below and in the GUI) is shown in the panel named Overview of the verifier. The toggle button Comments/Queries is used to control if the queries or the comments are to be shown in the overview.\nQueries are selected and de-selected using the mouse alone, or in combination with the Shift or the Control key of the keyboard (use the Shift key to (de-)select a range of entries and the Control key to (de-)select single entries). The first selected requirement and its comment is always shown in the two editor fields named Query and Comment, where they may be edited.\nNew entries are added using the button named Insert. A new entry is inserted before the first selected entry, or appended after the last entry if no entry is selected.\nThe button named Remove is used for deleting selected entries in the overview. Nothing is deleted if no entries are selected.\n"},{"uri":"/language-reference/query-syntax/symbolic_queries/","title":"Syntax of Symbolic Queries","tags":[],"description":"","content":"Symbolic Queries Symbolic queries are performed using symbolic operations based on symbolic semantics of timed automata and correspond to a mathematically rigorous proof.\nSymbolicQuery ::= \u0026#39;A[]\u0026#39; Expression Subjection | \u0026#39;E\u0026lt;\u0026gt;\u0026#39; Expression Subjection | \u0026#39;E[]\u0026#39; Expression Subjection | \u0026#39;A\u0026lt;\u0026gt;\u0026#39; Expression Subjection | Expression --\u0026gt; Expression Subjection | \u0026#39;sup\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;sup\u0026#39; \u0026#39;{\u0026#39; Expression \u0026#39;}\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;inf\u0026#39; \u0026#39;:\u0026#39; List Subjection | \u0026#39;inf\u0026#39; \u0026#39;{\u0026#39; Expression \u0026#39;}\u0026#39; \u0026#39;:\u0026#39; List Subjection List ::= Expression | Expression \u0026#39;,\u0026#39; List Subjection ::= // empty for no subjection | under StrategyName Subjection indicates whether the query should be subjected to a strategy. For sup properties, expression may not contain clock constraints and must evaluate to either an integer or a clock.\nSee rail road diagram for the entire SymbolicQuery syntax.\nSee also: Semantics of the Symbolic Queries\nExamples A[] 1\u0026lt;2 invariantly 1\u0026lt;2. E\u0026lt;\u0026gt; p1.cs and p2.cs true if the system can reach a state where both process p1 and p2 are in their locations cs. A[] p1.cs imply not p2.cs invariantly process p1 in location cs implies that process p2 is not in location cs. A[] not deadlock invariantly the process is not deadlocked. sup: Train(1).x, Train(2).x computes the suprema of Train(1).x and Train(2).x expressions (maximal values in case of integers, upper bounds, strict or not, for clocks). sup{Train(1).Crossing}: Train(1).x computes the supremum of Train(1).x but only when Train(1) is in Crossing. inf{Gate.Occ}: Gate.len similarly to sup, infquery computes infimum of the given expression Gate.len while process Gate is in Occ location. When a clock infimum is needed, the state predicate should be used, otherwise the result is trivially \u0026gt;=0. "},{"uri":"/language-reference/system-description/","title":"System Description","tags":[],"description":"","content":"A system model in UPPAAL consists of a network of processes described as extended timed automata. The description of a model consist of three parts: its global and local declarations, the automata templates, and the system definition.\n"},{"uri":"/language-reference/system-description/system-definition/template-instantiation/","title":"Template Instantiation","tags":[],"description":"","content":"New templates can be defined from existing templates using the grammar for Instantiation. The new template has the same automaton structure and the same local variables as the template it is defined from. However, arguments are provided for any formal parameters of the template, thus changing the interface of the template.\nInstantiation ::= ID [ \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; ] \u0026#39;=\u0026#39; ID \u0026#39;(\u0026#39; [Arguments] \u0026#39;)\u0026#39; \u0026#39;;\u0026#39; Template instantiation is most often used to bind formal parameters to actual arguments. The resulting template is later instantiated into a process by listing it in the system line.\nThe new template can itself be parameterised. This provides the opportunity to make a partial instantiation of a template, where some formal parameters are bound while others remain free. Examples of typical uses are listed below.\nFor more examples, see the example systems included in the UPPAAL distribution.\nExamples Renaming P1 = Q(); P2 = Q(); system P1, P2; Q is a template without any formal parameters. P1 and P2 become templates identical to Q. This is used to make several instances of Q with different names. Notice that P1=Q() is a shorthand of P1()=Q().\nBinding parameters In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess R(int \u0026amp;i, const int j) { ... } int x; S = R(x, 1); system S; Here we bind the formal parameters of R, i and j, to x and 1 respectively. S becomes a template without any parameters. When listed in the system line, S is instantiated into a process with the same name.\nPartial instantiation In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess P(int \u0026amp;x, int y, const int n, const int m) { ... } int v, u; const struct { int a, b, c; } data[2] = { { 1, 2, 3 }, { 4, 5, 6 } }; Q(int \u0026amp;x, const int i) = P(x, data[i].a, data[i].b, 2 * data[i].c); Q1 = Q(v, 0); Q2 = Q(u, 1); system Q1, Q2; Here P is a template with four formal parameters integer parameters. The first must be passed by reference, the remaining by value. Q is a template with two formal integer parameters. The first must be passed by reference, the second by value. Q1 is equivalent to P(v, data[0].a, data[0].b, 2 * data[0].c.\nThis is very convenient when defining many instances of the same template with almost the same arguments. It is also useful to bind some formal parameters and leave others free. When the resulting template is listed in the system line, UPPAAL will create a process for each possible combination of arguments to the free parameters.\n"},{"uri":"/language-reference/system-description/declarations/types/","title":"Types","tags":[],"description":"","content":"There are 6 predefined types: int, bool, clock, chan, double and string. Array and record types can be defined over all types except string.\nType ::= Prefix TypeId Prefix ::= \u0026#39;urgent\u0026#39; | \u0026#39;broadcast\u0026#39; | \u0026#39;meta\u0026#39; | \u0026#39;const\u0026#39; TypeId ::= ID | \u0026#39;int\u0026#39; | \u0026#39;clock\u0026#39; | \u0026#39;chan\u0026#39; | \u0026#39;bool\u0026#39; | \u0026#39;double\u0026#39; | \u0026#39;string\u0026#39; | \u0026#39;int\u0026#39; \u0026#39;[\u0026#39; [Expression] \u0026#39;,\u0026#39; [Expression] \u0026#39;]\u0026#39; | \u0026#39;scalar\u0026#39; \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; | \u0026#39;struct\u0026#39; \u0026#39;{\u0026#39; FieldDecl (FieldDecl)* \u0026#39;}\u0026#39; FieldDecl ::= Type ID ArrayDecl* (\u0026#39;,\u0026#39; ID ArrayDecl*)* \u0026#39;;\u0026#39; ArrayDecl ::= \u0026#39;[\u0026#39; [Expression] \u0026#39;]\u0026#39; | \u0026#39;[\u0026#39; Type \u0026#39;]\u0026#39; The default range of an integer is [-32768, 32767]. Any assignment out of range will cause the verification to abort.\nVariables of type bool can have the values false and true, which are equivalent to the the integer values 0 and 1. Like in C, any non-zero integer value evalutes to true and 0 evaluates to false.\nChannels can be declared as urgent and/or broadcast channels. See the section on synchronisations for information on urgent and broadcast channels.\nFloating-point variables of the double-type behave like C-double. Doubles values are not supported in the symbolic verification and simulation engine and are simply ignored, which can lead to unexpected results.\nVariables of string type must be declared constant. The primary use of string variables is in combination with External Functions\nConstants Integers, booleans, doubles strings, and arrays and records over integers and booleans can be marked constant by prefixing the type with the keyword const.\nMeta variables Integers, booleans, doubles, and arrays and records over integers and booleans can be marked as meta variables by prefixing the type with the keyword meta.\nMeta variables are stored outside of the state vector and are semantically not considered part of the state. I.e. two states that only differ in meta variables are considered to be equal.\nArrays The size of an array is specified either as an integer or as a bounded integer type or scalar set type. In the first case the array will be 0-indexed. In the latter case, the index will be of the given type. The following declares a scalar set s_t of size 3 and an integer array a of size 3 indexed by the scalar:\ntypedef scalar[3] s_t; int a[s_t]; Record Variables Record types are specified by using the struct keyword, following the C notation. For example, the record s below consist of the two fields a and b:\nstruct { int a; int b; } s; Scalars Scalars in UPPAAL are integer like elements with a limitted number of operations: Assignment and identity testing. Only scalars from the same scalar set can be compared.\nThe limitted number of operations means that scalars are unordered (or that all orders are equivalent in the sense that the model cannot distinguish between any of the them). UPPAAL applies symmetry reduction to any model using scalars. Symmetry reduction can lead to dramatic reductions of the state space of the model. resulting in faster verification and less memory being used.\nNotice that symmetry reduction is not applied if diagnostic trace generation is enabled or when A\u0026lt;\u0026gt;, E[] or --\u0026gt; properties are verified.\nScalar sets are treated as types. New scalar sets are constructed with the scalar[n] type constructor, where n is an integer indicating the size of the scalar set. Scalars of different scalar sets are incomparable. Use typedef to name a scalar set such that is can be used several times, e.g.\ntypedef scalar[3] mySet; mySet s; int a[mySet]; Here mySet is a scalar set of size 3, s is a variable whos value belongs to the scalar set mySet and a is an array of integers indexed by the scalar set mySet. Thus a[s] = 2 is a valid expression.\nCharacter Strings or Textual Type UPPAAL supports text constants via const string type for calling External Functions and refering to file system paths.\nFor example:\nconst string text = \u0026#34;message\u0026#34;; "},{"uri":"/toolsandapi/uppaal/","title":"UPPAAL","tags":[],"description":"","content":"UPPAAL can be executed from the command line using the following command on unix:\nuppaal [OPTION] \u0026hellip; [FILENAME]\nOn windows, the following command can be used (for instance, using \u0026ldquo;Run\u0026rdquo; from the Start Menu):\njava -jar \\path\\uppaal.jar [OPTION] \u0026hellip; [FILENAME]\nwhere path is the complete path to the uppaal.jar file (it might also be necessary to specify the complete path to the java executable).\nThe optional filename refers to a model to be loaded at startup.\nThe available command line options are:\n--antialias on|off (default on) turns antialiasing on or off in the automata rendering. --engineName The name of verification server (default is server on Unix and server.exe on Windows) to be used by the GUI. --enginePath The path to the verification server (e.g. bin-Windows) to be used by the GUI. --help Displays a summary of options. --serverHost Host name of remote machine running verification server. --serverPort Port number used by verification server on remote machine. --export templateName filename.ext Export the named template to a graphics file. The graphics format is determined by the filename extension, and EPS will be used instead if format is not recognized. Use system keyword to export all templates where the filenames will be taken from the template name. --psColors on|off Selects whether to export automata in color or greyscale EPS. "},{"uri":"/gui-reference/yggdrasil/tutorial/using-variables/","title":"Using Model Variables","tags":[],"description":"","content":"This tutorial assumes you have understood basic test case generation.\nThe model: Up/Down system Open the updown/updown.xml file in Uppaal.\nThe system contains two templates: System and User.\nThe system can be either On, Max, or Off, with channels up and down changing between them. The user can non-deterministically press up or down.\nSystem template User template Add model annotations and test pre- and post-fix code Global variable declarations and prefix/postfix code is the same as for the on/off model.\nAdd test step code annotations accessing model variables The system model is decorated with slightly different test code.\nThe location Off is still decorated with expect_off();, similarly the location Max is decorated with expect_max();. The state On is different, since here we want to verify the value of the variable val as well as the location. This is done by entering the value of val into the test case using the code expect_on($(System.val));. This will execute the expect_on with the value of val as parameter. Since val is local to the process System the name is entered as System.val. Generating the test cases Like the basic case, to generate test cases go to the Test Cases tab.Select which techniques for test case generation to use. For now only select Depth auto mode and a depth of 20. Click Add to generate the test cases. Inspecting the coverage The test generation will normally generate 2-3 test case traces (depending on randomization). Here 3 traces were generated. Each trace generated will have a line in the list similar to Trace coverage: 5/8. This shows that the trace covered five out of eight edges. Selecting a specific trace will show furter coverage statistics about that trace, i.e., which locations/edges are traversed how many times. Here, the System\u0026rsquo;s edge from location On to On has been traversed 6 times, whereas the edge from On to Off is traversed 0 times, revealing that it is not covered by this trace.\nBy double clicking the trace and then selecting the Simulator tab, the trace can be further examined. By selecting Mark Visited in the View menu, all covered edges will be colored blue in the simulator.\nThe total coverage achieved by the previous steps can be viewed by clicking the Total Coverage button which updates the trace statistics with the combined coverage. Due to the randomness of the model and the test case generation algorithm it is unlikely to get 100% coverage. Here, 1 location and 3 edges are left uncovered.\nCompleting coverage using the Single Step method This coverage can be increased by using the Single step method. This method searches for traces for uncovered edges. Adding these, should result in a number of test trace being added (here one, thus four in total) giving 8/8 in total coverage, thereby achieving the desired high coverage; here complete edge- and location-coverage.\nInspecting the test case code Save the test cases using the Save Test Cases button; select the output folder for test case to be the updown folder in this tutorial. This will produce a test-case file named testcase0.code in the selected output folder. If several traces have been generated, several files will be generated with sequential numbering.\nEach of these will be a Java class with the sequence of method invocations induce by the generated trace. A snippet is shown below.\n1: package app; 2: import app.App; 3: 4: class Test extends App { 5: 6: public static void main(String[] args) { 7: 8: 9: expect_off(); 10: 11: up(); 12: 13: expect_on(1); 14: 15: up(); 16: 17: expect_on(2); 18: 19: up(); 20: 21: expect_on(3); 22: 23: down(); 24: 25: expect_on(2); 26: 27: up(); \u0026lt;... snip ...\u0026gt; 94: } 95: } The overall composition of the test case is the same as in the first part of the tutorial The difference can be seen on lines 13, 17, 21, and 25. Here it is seen that the value of val is entered into the trace. It can be seen that the value increases after up(); and decreases after down();. Running the test.sh (or test.bat on Windows) will compile and run the test cases one at a time. It will output the name of each file as it executes them. No output from the test case signifies successful execution.\nupdown$ ./test.sh testcase0.code testcase1.code testcase2.code testcase3.code updown$ Running the testMutant.sh (or testMutant.bat on Windows) will compile and run the test cases on the mutant implementation. This should result in an exception being thrown when executing test case number 3, signifying a test error.\nupdown$ ./testMutant.sh testcase0.code testcase1.code testcase2.code testcase3.code Exception in thread \"main\" java.lang.AssertionError at app.App.expect_on(App.java:17) at app.Test.main(Test.java:15) updown$ The implementation can be examined in the updown/app folder. See updown/app/AppC.java for the correct implementation and updown/app/AppM.java for the mutant.\n"},{"uri":"/gui-reference/yggdrasil/tutorial/using-queries/","title":"Using Queries","tags":[],"description":"","content":"This tutorial assumes you have understood using variables.\nThe system model This tutorial uses the same Up/Down model as in the section using variables. Open the updown/updown.xml file in Uppaal.\nEditing the Queries Sometimes it is desirable to generate test cases for specific purposes. This can be done by creating a verification query for the purpose, and use that to generate a test trace.\nIn the Verifier tab you can enter queries. The Test Cases generator is able to search for traces satisfying reachability queries (that is queries which start with E\u0026lt;\u0026gt;. The query entered in this tutorial should be E\u0026lt;\u0026gt; System.Max, which asks the verifier to find a trace where the System process is in the location Max.\nGenerating test traces from queries To generate test cases go to the Test Cases tab and activate the Query mode, and hit Add.\nThis will generate a trace from the query file that leads to the Max location. You can inspect in the trace statistics that that location is infact now covered. By default, a test trace will be generated per query for all queries in the query file. In the drop-down selector you can chosse a specific query to generate and add.\nFurther, you can double click the trace and go to the Simulator tab and verify that this trace does indeed lead to the Max location. From the Off location this requires doing up ten successive times. Generating tests using the combined methodology As recommended, start by adding test cases for the test purposes (queries), then optimize coverage by the auto-depth mode, and finally single-step mode. This results in the three sections listed the test traces output panel.\n"},{"uri":"/language-reference/query-syntax/controller_synthesis/","title":"Syntax of Controller Synthesis","tags":[],"description":"","content":"Controller Synthesis Queries Controller synthesis queries are decided using symbolic techniques over Timed Game (TIGA) automata, where the discrete actions are either controllable (controller\u0026rsquo;s actions, solid edges) or uncontrollable (environment actions, dashed edges). The result is either a strategy solving the game objective or that the strategy does not exist.\nControlQuery ::= ControlSpecifier Goal Subjection | CollaborativeControlSpecifier Goal Subjection | PartialControlSpecifier Goal Subjection | TimeEfficientGameSpecifier Goal ControlSpecifier ::= \u0026#39;control:\u0026#39; CollaborativeControlSpecifier ::= \u0026#39;E\u0026lt;\u0026gt;\u0026#39; \u0026#39;control:\u0026#39; PartialControlSpecifier ::= \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; \u0026#39;control:\u0026#39; TimeEfficientGameQuery ::= \u0026#39;control_t*\u0026#39; \u0026#39;(\u0026#39; GameTimeLimitExpression \u0026#39;,\u0026#39; LocalGameTimeLimitExpression \u0026#39;):\u0026#39; | \u0026#39;control_t*\u0026#39; \u0026#39;(\u0026#39; u \u0026#39;):\u0026#39; | \u0026#39;control_t*:\u0026#39; Goal ::= \u0026#39;A\u0026lt;\u0026gt;\u0026#39; WinExpression | \u0026#39;A[\u0026#39; NotLoseExpression \u0026#39;U\u0026#39; WinExpression \u0026#39;]\u0026#39; | \u0026#39;A[\u0026#39; NotLoseExpression \u0026#39;W\u0026#39; WinExpression \u0026#39;]\u0026#39; | \u0026#39;A[]\u0026#39; NotLoseExpression WinExpression ::= Expression NotLoseExpression ::= Expression GameTimeLimitExpression ::= Expression LocalGameTimeLimitExpression ::= Expression Subjection ::= // empty for no subjection | under StrategyName GameTimeLimitExpression describes a time limit within the game must be won. This expression is only evaluated once at the beginning, thus should not depend on the current state. LocalGameTimeLimitExpression describes an additional time limit such that the game can be won within GameTimeLimitExpression - LocalGameTimeLimitExpression time units. This expression is evaluated in each state, and can therefore depend on state or clock constraints. Must be side-effect free. See rail road diagram for the entire ControlQuery syntax.\nExamples control: E\u0026lt;\u0026gt; goal compute a strategy where goal state predicate is eventually true no matter what the oponent/environment chooses to do. The resulting strategy is deterministic in a sense that for a given state the strategy proposes one action for the player/controller (while the oponent/environment may still choose from multiple actions). control: A[] safe compute a strategy where safe state predicate is always true no matter what the opponent/environment chooses to do. The strategy is permissive in a sense that for a given state the strategy may propose multiple actions for the player/controller. Such permissive strategy can be thought of as a union of all strategies satisfying the predicate, therefore it does not have any notion of progress and may include infinite loops. A[ safe U goal ] computes a safety strategy but only up until the goal is reached. A[ safe W goal ] (weakly until the goal) either a safety strategy is found or a safety strategy holds until the goal is reached. See also Strategy Queries below on how to store and query the properties of the computed strategies.\n"},{"uri":"/language-reference/query-syntax/","title":"Query Syntax","tags":[],"description":"","content":"This section describes a BNF-grammar for the requirement specification language used in the verifier of UPPAAL.\nSymbolic Queries Controller Synthesis Statistical Queries Learning Queries Strategy Queries See also rail road diagram for the entire Query syntax.\n"},{"uri":"/gui-reference/system-editor/drawing/","title":"Drawing","tags":[],"description":"","content":"The rightmost panel of the system editor is used for drawing automata. There are currently four drawing tools named Select, Location, Edge, and Nail represented by the buttons in the tool bar.\nSelect tool: The select tool is used to select, move, modify and delete elements. Elements can be selected by clicking on them or by dragging a rubber band arround one or more elements. Elements can be added or removed from a selection by holding down the control key while clicking on the element. The current selection can be moved by dragging them with the mouse. Double clicking an element brings up the editor for that element. Right clicking an element brings up a pop-up menu from which properties of the element can be changed. It is possible to change the source and target of an edge by moving the mouse to the beginning or end of an edge until a small circle appears. Drag this circle to a new location in order to change the source or target of the edge. Location tool: The location tool is used to add new locations. Simply click with the left mouse button in order to add a new location. Branch tool: The branch tool is used to create probabilistic branches. Simply click with the left mouse button in order to add a new branch point, then choose edge tool to create connecting edges. Edge tool: The edge tool is used to add new edges between locations. Start the edge by clicking on the source location, then click in order to place nails and finally click the target location. The operation can be cancelled by pressing the right mouse button. Nail tool: The nail tool is used to add new nails to an edge. Simply click and drag anywhere on an edge to add and place a new nail. For users with a three button mouse, the middle mouse button can be used to create new elements. The editor automatically chooses the correct tool: Clicking on an empty spot creates a new location, clicking on a location creates a new edge and clicking on an edge creates a new nail. With this feature it is possible to use the functionallity of all four tools without having to select the tools directly.\nColors The display color of individual locations and edges can be changed from the pop-up menu for these elements. UPPAAL does not assign any semantic meaning to the colors of locations and edges.\nComments Comments can be added to locations and edges. Double click the location or edge to bring up the editor for that element. The editor has a Comments tab for adding comments. UPPAAL does not assign any semantic meaning to the comments.\nComments are shown as document elements on the canvas. These elements can be resized by distributing the content of the comments over multiple lines.\nWhen shown in the tooltip of an element, comments are interpreted as HTML, i.e. tags like \u0026lt;p\u0026gt; and \u0026lt;b\u0026gt; may be used for formating.\nTooltips A tooltip is shown when hovering the mouse over an automaton element. The tooltip contains useful information such as syntax errors.\n"},{"uri":"/language-reference/system-description/templates/edges/","title":"Edges","tags":[],"description":"","content":"Locations are connected by edges. Edges are annotated with selections, guards, synchronisations and updates. Edges may also have branches of possible destinations with their own updates and probabilistic weights.\nSelections Selections non-deterministically bind a given identifier to a value in a given range. The other three labels of an edge are within the scope of this binding. Guards An edge is enabled in a state if and only if the guard evaluates to true. Synchronisation Processes can synchronize over channels. Edges labelled with complementary actions over a common channel synchronise. Updates When an edge is traversed, the update expression of the edge is evaluated. The side effect of this expression changes the state of the system. Weights Edges emanating from a branchpoint can be assigned a probabilistic weight. The probability such edge-transition is proportional to the edge weight and inversely proportional to the sum of weights over all edges leaving that branchpoint. Selections SelectList ::= ID \u0026#39;:\u0026#39; Type | SelectList \u0026#39;,\u0026#39; ID \u0026#39;:\u0026#39; Type For each ID in SelectList, bind ID non-deterministically to a value of type Type domain. The identifiers are available as variables within the other labels of this edge (guard, synchronization, or update). The supported types are bounded integers and scalar sets. Note: The identifiers will shadow any variables with the same name.\nExample Select: i : int[0,3]\nSynchronization: a[i]?\nUpdate: receive_a(i)\nThis edge will non-deterministically bind i to an integer in the range 0 to 3, inclusive. The value i is then used both as an array index when deciding what channel to synchronize on, and as an argument in the subsequent call to the function receive_a.\nGuards Guards follow the abstract syntax of expressions. However, the type checker restricts the set of possible expressions allowed in guards: A guard must be a conjunction of simple conditions on clocks, differences between clocks, and boolean expressions not involving clocks. The bound must be given by an integer expression.\nExamples x \u0026gt;= 1 \u0026amp;\u0026amp; x \u0026lt;= 2 x is in the interval [1,2]. x \u0026lt; y x is (strictly) less than y. (i[0]+1) != (i[1]*10) Value at position 0 in an integer array i plus one is not equal to value at position 1 times 10 (i must be an integer array since we use arithmetic operations on its elements). Synchronisations Channels are used to synchronise processes. This is done by annotating edges in the model with synchronisation labels. Synchronisation labels are syntactically very simple. They are of the form e? or e!, where e is a side effect free expression evaluating to a channel.\nThe intuition is that two processes can synchronise on enabled edges annotated with complementary synchronisation labels, i.e. two edges in different processes can synchronise if the guards of both edges are satisfied, and they have synchronisation labels e1? and e2! respectively, where e1 and e2 evaluate to the same channel.\nWhen two processes synchronise, both edges are fired at the same time, i.e. the current location of both processes is changed. The update expression on an edge synchronizing on e1! is executed before the update expression on an edge synchronizing on e2?. This is similar to the kind of synchronisation used in CCS or to rendezvous synchronisation in SPIN.\nUrgent channels are similar to regular channels, except that it is not possible to delay in the source state if it is possible to trigger a synchronisation over an urgent channel. Notice that clock guards are not allowed on edges synchronising over urgent channels.\nBroadcast channels allow 1-to-many synchronisations. The intuition is that an edge with synchronisation label e! emits a broadcast on the channel e and that any enabled edge with synchronisation label e? will synchronise with the emitting process. I.e. an edge with an emit-synchronisation on a broadcast channel can always fire (provided that the guard is satisfied), no matter if any receiving edges are enabled. But those receiving edges, which are enabled will synchronise. Notice that clock guards are not allowed on edges receiving on a broadcast channel. The update on the emitting edge is executed first. The update on the receiving edges are executed left-to-right in the order the processes are given in the system definition.\nNotice that for both urgent and broadcast channels it is important to understand when an edge is enabled. An edge is enabled if the guard is satisfied. Depending on the invariants, the target state might be undefined. This does not change the fact that the edges are enabled! E.g. when two edges in two different processes synchronise via a broadcast channel, and the invariant of the target location of the receiving edge is violated, then this state is not defined. It is not the case that the emitting edge can be fired by itself since the receiving edge is enabled and thus must synchronise. Please see the section about the semantics for further details.\nUpdates An update is a comma separated list of expressions. These expressions will typically have side effects. Assignments to clocks are limited to the regular = assignment operator and only integer expressions are allowed on the right hand side of such assignments. The syntax of updates is defined by the grammar for Update:\nUpdate ::= [Expression (\u0026#39;,\u0026#39; Expression)*] Note: Assignments are evaluated sequentially (not concurrently). On synchronizing edges, the assignments on the !-side (the emitting side) are evaluated before the ?-side (the receiving side).\nThe regular assignment operator, =, can be used for assigning values to integer, boolean, record and clock variables. The other assignment operators are limitted to integer and boolean variables and work as in C, e.g. i += 2 is equivalent to i = i + 2 except that any side effect of evaluating i is only executed once in the first case whereas it is executed twice in the latter case.\nPlease remember that any integers are bounded. Any attempt to assign a value outside the declared range to an integer, will cause an error and the verification will be aborted.\nExamples x = 0 clock (or integer variable) x is reset. j = ( i[1]\u0026gt;i[2] ? i[1] : i[2] ) integer j is assigned the maximum value of array elements i[1] and i[2]. This is equivalent to j = i[1] \u0026gt;? i[2], except that one of the sub-expressions is evaluated twice in the example (once in the condition, and again in either the true case or the false case). x = 1, y = 2 * x integer variable x is set to 1 and y to 2 (as assignments are interpreted sequentially). Weights The weight over branch is a constant non-negative integer expressions denoting the probabilistic likely-hood of the branch being executed. The probability of a particular branch is determined as a ratio of its weight over the sum of weights of all branches emanating from the same branch node.\nThe weights are used in probabilistic and statistical model checking.\nExample Select: i : int[0,3]\nUpdate: gen_data(i)\nWeight: w[i]\n"},{"uri":"/gui-reference/menu-bar/edit/","title":"Edit Menu","tags":[],"description":"","content":"The Edit menu offers a set of commands supported in the system editor. The items are:\nUndo: reverses the most recent editing action. This function is only available in the editor. Redo: re-applies the editing action that has most recently been reversed by the Undo action. This function is only available in the editor. Cut: removes the selected text and places it in the clipboard. There must be an active text selection. Copy: places a copy of the selected text in the clipboard. There must be an active text selection. Paste: places text in the clipboard at the cursor location in the currently active editor. There must be text in the clipboard, and an editor must be active. Delete: delete selected text. There must be an active text selection. Insert Template: adds a new empty template to the system description. Remove Template: removes the currently selected template from the system description. There must be a template selected. "},{"uri":"/language-reference/system-description/declarations/functions/","title":"Functions","tags":[],"description":"","content":"Functions can be declared alongside other declarations. The syntax for functions is defined by the grammar for Function:\nFunction ::= [Type] [ID] \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; Block Block ::= \u0026#39;{\u0026#39; LocalDeclaration* Statement* \u0026#39;}\u0026#39; LocalDeclation ::= TypeDeclaration | VariableDeclaration Statement ::= Block | \u0026#39;;\u0026#39; | [Expression] \u0026#39;;\u0026#39; | ForLoop | Iteration | WhileLoop | DoWhileLoop | IfStatement | ReturnStatement ForLoop\t::= \u0026#39;for\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;;\u0026#39; [Expression] \u0026#39;;\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement Iteration ::= \u0026#39;for\u0026#39; \u0026#39;(\u0026#39; [ID] \u0026#39;:\u0026#39; [Type] \u0026#39;)\u0026#39; Statement WhileLoop ::= \u0026#39;while\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement DoWhile ::= \u0026#39;do\u0026#39; Statement \u0026#39;while\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; \u0026#39;;\u0026#39; IfStatment ::= \u0026#39;if\u0026#39; \u0026#39;(\u0026#39; [Expression] \u0026#39;)\u0026#39; Statement [ \u0026#39;else\u0026#39; Statement ] ReturnStatement ::= \u0026#39;return\u0026#39; [ [Expression] ] \u0026#39;;\u0026#39; See rail road diagram for the entire Function declaration.\nFunctions The declarations inside functions include only variable and type declarations. Nested function declarations and recursion are not supported.\nIteration The keyword for has two uses: the first is a C/C++/Java like for-loop, and the second is a Java like iterator or ranged-loop in C++. The second is primarily used to iterate over arrays indexed by scalars.\nA statement for (ID : Type) Statement will execute Statement once for each value ID of the domain of type Type. The scope of ID is bound to the Statement, and Type must be a bounded integer or a scalar set.\nSee also rail road diagrams for the entire ForStatement and WhileStatement.\nExamples add The following function returns the sum of two integers. The arguments are call by value.\nint add(int a, int b) { return a + b; } swap The following procedure swaps the values of two call-by-reference integer parameters.\nvoid swap(int \u0026amp;a, int \u0026amp;b) { int c = a; a = b; b = c; } initialize The following procedure initializes an array such that each element contains its index in the array. Notice that the an array parameter is a call-by-value parameter unless an ampersand is used in the declaration. This is different from C++ syntax, where the parameter could be considered an array of references to integer.\nvoid initialize(int\u0026amp; a[10]) { for (i : int[0,9]) { a[i] = i; } } Special Functions The following are the signatures of special functions which can be declared to be called on special verification events:\nvoid __ON_CONSTRUCT__(); void __ON_DESTRUCT__(); void __ON_BEGIN__(); void __ON_END__(); __ON_CONSTRUCT__ Called after the system (or a process) representation is constructed when specified in global declarations (or a template local declarations respectively). Useful to initialize meta variables and external libraries. __ON_DESTRUCT__ Called before the system (or a process) representation is destroyed when specified in global declarations (or a template local declarations respectively). Useful to release resources in external libraries. __ON_BEGIN__ Called before a query is started. Useful to initialize variables and external libraries. __ON_END__ Called after a query is finished. Useful to release resources in external libraries. One can also declare a statement to be executed before a transition is taken and after:\nbefore_update { old_value = variable } after_update { new_value = variable } "},{"uri":"/language-reference/","title":"Language Reference","tags":[],"description":"","content":"Chapter 2 UPPAAL Language Reference "},{"uri":"/language-reference/system-description/system-definition/progress-measures/","title":"Progress Measures","tags":[],"description":"","content":"A progress measure is an expression that defines progress in the model. It should be weakly monotonically increasing, although occasional decreasses are acceptable. E.g. sequence numbers used in communication protocols might be used to define a progress measure, provided that the sequence number does not overflow to often.\nIf progress measures are defined, UPPAAL uses the generalized sweepline method to reduce the memory usage. However to be efficient, the domain of a progress measure should not be too large - otherwise performance might degrade significantly.\nProgress measures are placed after the system definition. The syntax is defined by the grammar for ProgressDecl:\nProgressDecl ::= \u0026#39;progress\u0026#39; \u0026#39;{\u0026#39; ( [Expression] \u0026#39;;\u0026#39; )* \u0026#39;}\u0026#39; Examples int i, j, k; ... progress { i; j + k; } For the above to be a useful progress measure, i and j + k should increase weakly monotonically.\n"},{"uri":"/language-reference/query-semantics/","title":"Query Semantics","tags":[],"description":"","content":"Semantics of requirement specification language used in the verifier of UPPAAL.\nSymbolic Queries Statistical Queries Confidence Interval Estimation "},{"uri":"/gui-reference/yggdrasil/test-code/","title":"Specifying Test Code","tags":[],"description":"","content":"Traces are translated into executable test cases based on test code entered into the model. The test code is entered as verbatim text, so any language or execution back-end can be used. Test code can be entered in five areas: Prefix code, location enter code, location exit code, edge code, and postfix code. Each test case starts with the prefix code, continues with test code along the locations and edges of the trace and ends with the postfix code.\nThe prefix (and the postfix) code is entered as a comment after the system definition section using a special multi-line comment starting with the word TEST_PREFIX (and TEST_POSTFIX respectively).\nEach location in the transition system has two areas for test code. Double clicking a location in the editor will bring up a window with a test code tab. The location enter code is added to the test case when this location is entered, and the location exit code is added when the location is left.\nSimilarly double clicking an an edge will bring up a window with a single test code field. This code is added to the test case when the transition containing this edge is traversed.\nFor location and edge test code the value of variables can be entered into the test case. This is done using $(var) for global variables or $(Process.var) for process-local variables. Dollar signs can be escaped with backslash like $ and backslash can be escaped with backslash like \\. For location enter code the value is read after the transition into the state has been taken. For location exit code the value is read before the transition out of the state is taken. For edge code the value is read before taking the transition.\nThe test case file name and extension can be configured using special comments too: TEST_FILENAME and TEST_FILEEXT. These comments must be on one line. Generic name \u0026ldquo;testcase\u0026rdquo; and \u0026ldquo;.code\u0026rdquo; are used if these settings are not set.\nExample test case generation settings in the system declarations after the system definition:\n/** TEST_FILENAME test- */ /** TEST_FILEEXT .java */ /** TEST_PREFIX public class Test { public static int main(String[] args){ */ /** TEST_POSTFIX } } */ Note the double star in the special multiline comment start, single space characters in the TEST_FILE* options and no other characters on the comment begin and end lines in the TEST*FIX options._\n"},{"uri":"/language-reference/query-syntax/statistical_queries/","title":"Syntax of Statistical Queries","tags":[],"description":"","content":"Statistical Queries Statistical queries are decided using concrete semantics of stochastic hybrid automata over a number of bounded concrete simulation runs and correspond to empirical measurements of the system performance. The results are of statistical estimate nature and may vary across different executions based on uncertainties specified in Statistical parameters.\nSMCQuery ::= Simulate Subjection | Probability Subjection | ProbUntil Subjection | Probability ( \u0026#39;\u0026lt;=\u0026#39; | \u0026#39;\u0026gt;=\u0026#39; ) PROB Subjection | Probability Subjection \u0026#39;\u0026gt;=\u0026#39; Probability Subjection | Estimate Subjection Simulate ::= \u0026#39;simulate\u0026#39; \u0026#39;[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; [ \u0026#39;:\u0026#39; [ SATRUNS \u0026#39;:\u0026#39; ] Expression ] Probability ::= \u0026#39;Pr\u0026#39; MITLExpression | \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; PathType Expression \u0026#39;)\u0026#39; ProbUntil ::= \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; Expression \u0026#39;U\u0026#39; Expression \u0026#39;)\u0026#39; Estimate ::= \u0026#39;E[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; (\u0026#39;min:\u0026#39; | \u0026#39;max:\u0026#39;) Expression \u0026#39;)\u0026#39; SMCBounds ::= BoundType [ ; RUNS ] BoundType ::= ( | Clock | \u0026#39;#\u0026#39; ) \u0026#39;\u0026lt;=\u0026#39; BOUND PathType ::= ( \u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39; ) Subjection ::= // empty for no subjection | under StrategyName BOUND is a non-negative integer constant denoting an upper bound over the absolute global time (when a variable is not specified), specific Clock (cost) variable or a number of action-transitions (#). RUNS is an optional positive integer constant denoting the maximum number of runs. If the number of runs is not specified, then it is decided based on Statistical parameters and the particular estimation algorithm. SATRUNS is an optional positive integer constant denoting the maximum number of runs that satisfy the state expression. PROB is a floating point number from interval [0; 1] denoting a probability bound. \u0026rsquo;#\u0026rsquo; means a number of simulation steps \u0026ndash; discrete edge-transitions \u0026ndash; in the run. \u0026lsquo;min:\u0026rsquo; means the minimum value over a run of the proceeding expression. \u0026lsquo;max:\u0026rsquo; means the maximum value over a run of the proceeding expression. All expressions are state predicates and must be side effect free. It is possible to test whether a certain process is in a given location using expressions on the form process.location.\nSee rail road diagram for the entire SMCQuery syntax.\nSee also: Semantics of the SMC Queries\nExamples simulate [\u0026lt;=10] { x } creates one stochastic simulation run of up to 10 time units in length and plot the values of x expression over time (after checking, right-click the query and choose a plot). simulate [c\u0026lt;=10] { x, y+z } creates one simulation run of up to 10 cost units in terms of clock variable c and plot the values of x and y+z expressions over the cost c. simulate [#\u0026lt;=10] { x, y+z } creates one simulation run of up to 10 edge-transitions and plot the values of x and y+z expressions over the discrete simulation steps (edge-transitions). simulate [\u0026lt;=10; 100] { x, y+z } : 2 : goal selects up to 2 simulation runs from 100 simulations of up to 10 time units in length, which satisfy goal state predicate, and then plot the values of expressions x and y+z over time. The query will also estimate a probability confidense interval of the expression goal being true just like in Pr query. The confidence level is controlled by α-level of significance in the Statistical parameters. Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) runs a number of stochastic simulations and estimates the probability of good eventually becoming true within 10 time units. The number of runs is decided based on the probability interval precision (±ε) and confidence level (level of significance α in Statistical parameters), see Confidence Intervals for details. The query also computes a probability distribution over time when the predicate good is satisfied (right-click the property and choose a plot). Pr[c\u0026lt;=10; 100]([] safe) runs 100 stochastic simulations and estimates the probability of safe remaining true within 10 cost units in terms of clock c. Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) \u0026gt;= 0.5 checks if the probability of reaching good within 10 time units is greater than 50%. Such query uses Wald\u0026rsquo;s algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, α and β Statistical parameters. Pr[\u0026lt;=10](\u0026lt;\u0026gt; best) \u0026gt;= Pr[\u0026lt;=10](\u0026lt;\u0026gt; good) checks if the probability of reaching best is greater than reaching good within 10 time units. Such query uses a sequential algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, u0, u1, α and β Statistical parameters. The query also provides a probability comparison plot over time/cost (right-click the query and choose plot). E[\u0026lt;=10; 100](max: cost) estimates the maximal value of cost expression over 10 time units of stochastic simulation. Uses 100 stochastic simulations and assumes that the value follows Student\u0026rsquo;s t-distribution with 1-α confidence level. The plots can be super-imposed using the Plot Composer from the Tools menu.\n"},{"uri":"/language-reference/system-description/templates/","title":"Templates","tags":[],"description":"","content":"UPPAAL provides a rich language for defining templates in the form of extended timed automata. In contrast to classical timed automata, timed automata in UPPAAL can use a rich expression language to test and update clock, variables, record types, call user defined functions, etc.\nThe automaton of a template consist of Locations and edges. A template may also have local declarations and parameters. A template is instantiated by a process assignment (in the system definition).\n"},{"uri":"/gui-reference/toolbar/","title":"Tool Bar","tags":[],"description":"","content":"The tool bar is normally located just below the menu bar but can be moved (using the mouse) to other positions or even to a separate window. The tool bar is divided into four groups. The three leftmost groups provide quick access to some of the most frequently used menu items. The rightmost group contains editing tools.\nThe first group contains the following buttons: New, Open Project, and Save. These features are described in the File menu section.\nThe second group contains the following buttons: Undo and Redo. These features are described in the Edit menu section.\nThe third group contains the following buttons: Zoom to Fit, Zoom In, and Zoom Out. This features are described in the View menu section.\nThe fourth group contains tools used in the editor for selecting and moving elements of an automaton, and for adding locations, edges and nails. This features are described in the section on Drawing.\n"},{"uri":"/gui-reference/concrete-simulator/variables/","title":"Variables Panel","tags":[],"description":"","content":"The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.\n"},{"uri":"/gui-reference/verifier/verifying/","title":"Verifying Requirements","tags":[],"description":"","content":"The queries (i.e. the system requirements) are verified from the verifier interface of UPPAAL. A verification is always performed according to the settings specified in the Options menu of the main menu bar.\nThe selected queries are verified when the button named Check is pressed. The verification progress dialog displays the progress of how many queries have been verified, what is the current load of a passed-waiting list, current processor time usage (the time spent for verification is in blue, the time spent by operating system is in red), current usage of host\u0026rsquo;s random access memory (verification memory is in blue, memory used by other running processes is in gray and operating system cache and buffers are in yellow), swap disk usage (swapped out verification is in blue, other is in grey). Note that resource figures do not include the overhead of UPPAAL GUI and command line utilities (like memtime run on verifyta) are more accurate. Some figures are not available on some OSes (system cache allocation is not documented on Windows API and swap usage per process is not maintained by Linux kernel), therefore they might not show up.\nThe verification output is displayed in the Status field at the bottom of the verifier panel. The result is also indicated by the circular markers in the rightmost column of the Overview panel. A grey marker indicates that the truth value of the property is unknown, a green marker that the property is satisfied, and a red marker that the property is not satisfied.\nIn case the Over Approximation or the Under Approximation options are selected for State Space Representation, the output of the verifier might be that property is \u0026ldquo;maybe satisfied\u0026rdquo;. This happens when the verifier cannot determine the truth value of the property due to the approximations used.\nStatistical Model Checking Parameters for statistical model checking can be changed in the Options menu. Various data plots (if available) can be accessed via popup-menu by right-clicking the statistical property. The y-axis always denotes a probability or its density, while x-axis denotes either the variable values limited by the statistical query or a step (transition) count in the model run.\nProbability density distribution A histogram created from probability distribution where each bucket is normalized by a bucket width. Useful for comparison of various distributions, potentially with different bucket widths. Probability distribution A histogram created from a frequency histogram where each bucket is normalized by a total number of runs. Useful for assessing a probability of a property being satisfied at a particular moment in time interval. Cumulative probability distribution A histogram created by adding up all frequency histogram buckets up to the current bucket and normalized by a total number of runs. Confidence Intervals for Probabilities The confidence intervals for probabilities are computed using Clopper-Pearson method (also known as \"exact\") for binomial distribution for a given level of confidence (1-α). The method is conservative in a sense that it guarantees the minimum coverage of the real probability in (1-α) of cases. In the plots, the estimated confidence is valid only for one bucket at a time (the gathered data is reused to compute each individual bucket). Confidence Intervals for Mean The confidence intervals for mean estimation are computed using quantiles of Student's t-distribution for a given level of confidence of 1-α. Note that t-distribution approaches the commonly used Normal (Gaussian) distribution when the number of samples is high. Frequency histogram The frequency histogram is created by calculating the number of runs satisfying the property at a particular moment in time interval. Useful for calculating the number of runs. Any plot can be customized from a popup menu by right-clicking on the plot.\nFurther, the plot labels and titles can be edited and several data sets can be superimposed in one figure by using Plot Composer, accessible from the Tools menu. It is possible to create several composite plots at a time by invoking Plot Composer multiple times.\nAn extensive overview and comparison of methods for computing confidence intervals for binomial distribution can be found in the following publications:\nInterval Estimators for a Binomial Proportion: Comparison of Twenty Methods, Ana M. Pires and Conceicao Amado. REVSTAT \u0026ndash; Statistical Journal, Vol.6, No.2, June 2008, pages 165-197.\nInterval Estimation for a Binomial Proportion, Lawrence D. Brown, T. Tony Cai and Anirban DasGupta. Statistical Science, 2001, Vol.16, No.2, pages 101-133.\n"},{"uri":"/toolsandapi/verifyta/","title":"verifyta","tags":[],"description":"","content":"The verifier functionality is accessible through verifyta command line utility in bin-Windows or bin-Linux directory of the distribution. The supported options are displayed when running verifyta -h.\n"},{"uri":"/language-reference/query-syntax/learning_queries/","title":"Syntax of Learning Queries","tags":[],"description":"","content":"Learning Queries LearningQuery ::= ExpQuantifier \u0026#39;(\u0026#39; Expression \u0026#39;)\u0026#39; \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection | ExpQuantifier \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection | ExpPrQuantifier \u0026#39;[\u0026#39; BoundType \u0026#39;]\u0026#39; Features? \u0026#39;:\u0026#39; PathType Expression Subjection ExpQuantifier ::= ( minE | maxE ) ExpPrQuantifier ::= ( minPr | maxPr ) Features ::= \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; \u0026#39;-\u0026gt;\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; Subjection ::= // empty for no subjection | under StrategyName Features describes a mapping (state space partition) from a partial state to a player action. The first list maps in the discrete space (values interpreted as distinct categories) and the second list maps in continuous space (assumes distance between values: similar values yield similar cost). See rail road diagram for the entire LearningQuery syntax.\nExamples minE(cost) [\u0026lt;=10] : \u0026lt;\u0026gt; goal learns a strategy that minimizes the expected cost expression within 10 time units or when goal predicate becomes true given that the entire system state is observable. maxE(gain) [\u0026lt;=10] : \u0026lt;\u0026gt; goal learns a strategy that maximizes the expected gain expression withing 10 time units or when goal predicate becomes true given that the entire system state is observable. The goal predicate is deprecated, for best results use a predicate which stops together with the simulation bound, like t\u0026gt;=10, where t is a clock that is never reset.\nminE(cost) [\u0026lt;=10] { i, j } -\u0026gt; { d, f } : \u0026lt;\u0026gt; goal learns a strategy that minimizes the expected cost expression within 10 time units or when goal predicate becomes true. Where only the expressions i, j, d and f are observable. The {..} -\u0026gt; {..} syntax controls what is observable. On one hand, by observing only a partial state learning times can be significantly reduced and the strategy structure simplified. On the other hand, the resulting strategy is not guaranteed to converge to a optimal solution under partial observability. There are two types of observable state expressions: discrete and continuous. The discrete are specified in the first bracket and the continuous in the second: {discrete expressions} -\u0026gt; {continuous expressions}. By default the entire state is considered during learning. Discrete expressions are observed as they are, i.e the query minE(cost) [\u0026lt;=10] { i, j } -\u0026gt; { } : \u0026lt;\u0026gt; goal creates a strategy by only observing the values of i and j.\nContinuous expressions are discretized using online partition refinement (see Teaching Stratego to Play Ball). The query minE(cost) [\u0026lt;=10] { } -\u0026gt; { d, f } : \u0026lt;\u0026gt; goal learns a strategy based on the discretized expressions d and f.\nIntegers, clocks, floating points or even arbitrary expressions can be used in either type of observabilty. However we suggest caution when using floating point numbers or clocks in discrete observability.\nProcess locations are ignored when specifying observability unless explicitly specified using location keyword. For example Cat.location and Mouse.location refer to the locations of Cat and Mouse processes.\nThe learning queries are usually used together with strategy assignment and refinement explained in Strategy Queries.\n"},{"uri":"/gui-reference/system-editor/declarations/","title":"Declarations","tags":[],"description":"","content":"Types, constants, variables and functions can be defined in the global scope by placing them in the global section labelled Declarations or System declarations, or locally for a template by placing in the Declarations section of a template.\nProcesses are instantiated by placing a process assignments in the System declarations section.\nFinally, the system is defined as a parallel composition of a number of processes by placing a system declaration in the System declarations section.\nThe syntax for each of these sections is defined in the Language Reference.\n"},{"uri":"/language-reference/expressions/","title":"Expressions","tags":[],"description":"","content":"Most of the expression syntax of UPPAAL coincides with that of C, C++ and Java. For example assignments are done using the = operator (the older := still works, but = is preferred). Notice that assignments are expressions themselves, for example expression b = (a = 1) + 2 assigns 1 to a, then adds 2 and assigns the result to b.\nThe syntax of expressions is defined by the grammar for Expression.\nExpression = [ID] | NAT | Expression \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; | Expression \u0026#34;\u0026#39;\u0026#34; | \u0026#39;(\u0026#39; Expression \u0026#39;)\u0026#39; | Expression \u0026#39;++\u0026#39; | \u0026#39;++\u0026#39; Expression | Expression \u0026#39;--\u0026#39; | \u0026#39;--\u0026#39; Expression | Expression Assign Expression | Unary Expression | Expression Binary Expression | Expression \u0026#39;?\u0026#39; Expression \u0026#39;:\u0026#39; Expression | Expression \u0026#39;.\u0026#39; ID | Expression \u0026#39;(\u0026#39; Arguments \u0026#39;)\u0026#39; | \u0026#39;forall\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;exists\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;sum\u0026#39; \u0026#39;(\u0026#39; ID \u0026#39;:\u0026#39; Type \u0026#39;)\u0026#39; Expression | \u0026#39;deadlock\u0026#39; | \u0026#39;true\u0026#39; | \u0026#39;false\u0026#39;; Arguments = [ Expression ( \u0026#39;,\u0026#39; Expression )* ]; Assign = \u0026#39;=\u0026#39; | \u0026#39;:=\u0026#39; | \u0026#39;+=\u0026#39; | \u0026#39;-=\u0026#39; | \u0026#39;*=\u0026#39; | \u0026#39;/=\u0026#39; | \u0026#39;%=\u0026#39; | \u0026#39;|=\u0026#39; | \u0026#39;\u0026amp;=\u0026#39; | \u0026#39;^=\u0026#39; | \u0026#39;\u0026lt;\u0026lt;=\u0026#39; | \u0026#39;\u0026gt;\u0026gt;=\u0026#39;; Unary = \u0026#39;+\u0026#39; | \u0026#39;-\u0026#39; | \u0026#39;!\u0026#39; | \u0026#39;not\u0026#39;; Binary = \u0026#39;\u0026lt;\u0026#39; | \u0026#39;\u0026lt;=\u0026#39; | \u0026#39;==\u0026#39; | \u0026#39;!=\u0026#39; | \u0026#39;\u0026gt;=\u0026#39; | \u0026#39;\u0026gt;\u0026#39; | \u0026#39;+\u0026#39; | \u0026#39;-\u0026#39; | \u0026#39;*\u0026#39; | \u0026#39;/\u0026#39; | \u0026#39;%\u0026#39; | \u0026#39;\u0026amp;\u0026#39; | \u0026#39;|\u0026#39; | \u0026#39;^\u0026#39; | \u0026#39;\u0026lt;\u0026lt;\u0026#39; | \u0026#39;\u0026gt;\u0026gt;\u0026#39; | \u0026#39;\u0026amp;\u0026amp;\u0026#39; | \u0026#39;||\u0026#39; | \u0026#39;\u0026lt;?\u0026#39; | \u0026#39;\u0026gt;?\u0026#39; | \u0026#39;or\u0026#39; | \u0026#39;and\u0026#39; | \u0026#39;imply\u0026#39;; Like in C++, assignment, preincrement and predecrement expressions evaluate to references to the first operand. The inline-if operator does in some cases (e.g. when both the true and false operands evaluate to compatible references) also evaluate to a reference, i.e., it is possible to use an inline-if on the left hand side of an assignment.\nThe use of the deadlock keyword is restricted to the requirement specification language.\nSee rail road diagram for the entire Expression syntax.\nBoolean Values Boolean values are type compatible with integers. An integer value of 0 (zero) is evaluated to false and any other integer value is evaluated to true. The boolean value true evaluates to the integer value 1 and the boolean value false evaluates to the integer value 0. Notice: A comparison like 5 == true evaluates to false, since true evaluates to the integer value 1. This is consistent with C++.\nPrecedence UPPAAL operators have the following associativity and precedence, listed from the highest to lowest. Operators borrowed from C keep the same precedence relationship with each other.\nAssociativity Operator left () [] . right ! not ++ -- unary - unary + left * / % left binary - binary + left \u0026lt;\u0026lt; \u0026gt;\u0026gt; left \u0026lt;? \u0026gt;? left \u0026lt; \u0026lt;= \u0026gt;= \u0026gt; left == != left \u0026amp; left ^ left | left \u0026amp;\u0026amp; and left || or imply right ?: right = := += -= *= /= %= \u0026amp;= |= \u0026lt;\u0026lt;= \u0026gt;\u0026gt;= ^= left forall exists sum Operators Anybody familiar with the operators in C, C++, Java or Perl should immediately feel comfortable with the operators in UPPAAL. Here we summarise the meaning of each operator.\nOperator Description Example () Parenthesis alter the evaluation order 3 * (5 - 2) → 9 [] Array lookup my_array[0] . Infix lookup operator to access process or structure type scope my_struct.field1 ! Logical negation ! true → false not Logical negation not true → false ++ Increment (can be used as both prefix and postfix operator) ++counter counter++ -- Decrement (can be used as both prefix and postfix operator) --counter counter-- - Integer subtraction (can also be used as unary negation:-7) 5 - 3 → 2 + Integer addition (can also be used as unary plus: +7) 5 + 3 → 8 * Integer multiplication 5 * 3 → 15 / Integer division 5 / 3 → 1 % Modulo 5 % 3 → 2 \u0026lt;\u0026lt; Left bitshift 1 \u0026lt;\u0026lt; 4 → 16 \u0026gt;\u0026gt; Right bitshift 16 \u0026gt;\u0026gt; 4 → 1 \u0026lt;? Minimum 8 \u0026lt;? 12 → 8 \u0026gt;? Maximum 8 \u0026gt;? 12 → 12 \u0026lt; Less than 5 \u0026lt; 3 → true \u0026lt;= Less than or equal to 5 \u0026lt;= 3 → true == Equality operator 5 == 3 → false != Inequality operator 5 != 3 → true \u0026gt;= Greater than or equal to 5 \u0026gt;= 3 → true \u0026gt; Greater than 5 \u0026gt; 3 → true \u0026amp; Bitwise and 3 \u0026amp; 2 → 2 ^ Bitwise xor 1 ^ 3 → 2 | Bitwise or 1 | 3 → 3 \u0026amp;\u0026amp; Logical and (conjunction) true \u0026amp;\u0026amp; false → false and Logical and (conjunction) true and false → false || Logical or (disjunction) true || false → true or Logical or (disjunction) true or false → true ?: Inline if-then-else (ternary) operator true ? 8 : 12 → 8 imply Logical implication true imply false → false forall Forall quantifier forall (i : int[2, 10]) i*10 \u0026gt; 10 → true exists Exists quantifier exists (i : int[2, 10]) i*10 \u0026gt; 90 → true sum Sum expression sum (i : int[2, 10]) i*10 → 540 Notice that the keywords not, and and or behave the same as the !, \u0026amp;\u0026amp;, and || operators.\nAn integer expression used in logical expression is converted into boolean value by comparing the integer expression with zero. For example, x ? 1 : 2 is interpreted as (x != 0) ? 1 : 2.\nA few binary operators can be syntactically combined with assignment to produce a compact assignment expression:\nOperator Assignment Example Meaning + += x += y x = x + y - -= x -= y x = x - y * *= x *= y x = x * y / /= x /= y x = x / y % %= x %= y x = x % y \u0026amp; \u0026amp;= x \u0026amp;= y x = x \u0026amp; y ^ ^= x ^= y x = x ^ y | |= x |= y x = x | y \u0026lt;\u0026lt; \u0026lt;\u0026lt;= x \u0026lt;\u0026lt;= y x = x \u0026lt;\u0026lt; y \u0026gt;\u0026gt; \u0026gt;\u0026gt;= x \u0026gt;\u0026gt;= y x = x \u0026gt;\u0026gt; y Expressions Involving Clocks When involving clocks, the actual expression syntax is restricted by the type checker. Expressions involving clocks are divided into three categories: Invariants, guards, and constraints:\nAn invariant is a conjunction of upper bounds on clocks and differences between clocks, where the bound is given by an integer expression, and clock rates. A guard is a conjunction of bounds (both upper and lower) on clocks and differences between clocks, where the bound is given by an integer expression. A constraint is any boolean combination (involving negation, conjunction, disjunction and implication) of bounds on clocks and differences between clocks, where the bound is given by an integer expression. In addition, any of the three expressions can contain expressions (including disjunctions) over integers, as long as invariants and guards are still conjunctions at the top-level. The full constraint language is only allowed in the requirement specification language.\nOut of Range Errors and Invalid Evaluations An evaluation of an expression is invalid if out of range errors occur during evalution. This happens in the following situations:\nDivision by zero. Shift operation with negative count. Out of range assignment. Out of range array index. Assignment of a negative value to a clock. Function calls with out of range arguments. Function calls with out of range return values. In case an invalid evaluation occurs during the computation of a successor, i.e., in the evaluation of a guard, synchronisation, assignment, or invariant, then the verification is aborted.\nQuantifiers An expression forall (ID : Type) Expr evaluates to true if Expr evaluates to true for all values ID of the type Type. An expression exists (ID : Type) Expr evaluates to true if Expr evaluates to true for some value ID of the type Type. In both cases, the scope of ID is the inner expression Expr, and Type must be a bounded integer or a scalar set.\nExample The following function can be used to check if all elements of the boolean array a have the value true.\nbool alltrue(bool a[5]) { return forall (i : int[0,4]) a[i]; } Sum An expression sum (ID : Type) Expr evaluates to an integer and is equal to the sum of the expressions evaluated with ID ranging over the given type argument. Boolean or state predicates (in TCTL expressions only) are accepted but not clock constraints. The expressions must be side-effect free. The type must be a bounded integer or a scalar set.\nMITL Expressions Statistical model checking (SMC) supports the full logic of weighted metric interval temporal logic (MITL). The syntax of MITL expressions is defined by the grammar for MITLExpression.\nMITLExpression = BExpr | (MITLExpression \u0026amp;\u0026amp; MITLExpression) | (MITLExpression || MITLExpression) | (MITLExpression \u0026#39;U\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (MITLExpression \u0026#39;R\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;X\u0026#39; MITLExpression) | (\u0026#39;\u0026lt;\u0026gt;\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;[]\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression); BExpr describes a Boolean expression over clocks, variables, and locations. See rail road diagram of entire MITLExpression syntax: Floating Point Type Support Statistical model checking (SMC) supports double precision floating point type double. The clock variables also have floating point values in SMC. Symbolic and statistical model checking can be applied on the same model provided that double and hybrid clock type variables do not influencing the model logic, i.e. they cannot be used in guard and invariant constraints (but can be used in ODE expressions).\nThe following is the list of builtin floating point functions (mostly imported from C math library, hence the C math manual can be consulted for more details):\nint abs(int) absolute value of integer argument. double fabs(double) absolute value of double argument. double fmod(double x, double y) remainder of the division opration x/y. double fma(double x, double y, double z) computes x*y+z as if to infinite precision. double fmax(double x, double y) the larger of the two arguments. double fmin(double x, double y) the smaller of the two arguments. double exp(double x) Euler\u0026rsquo;s number raised to the given power: ex. double exp2(double x) 2 raised to the given power: 2x. double expm1(double x) Euler\u0026rsquo;s number raised to the given power minus 1: ex-1. double ln(double x) logarithm to the base of Euler\u0026rsquo;s number: loge(x). double log(double x) logarithm to the base of 10 log10(x) (this is different from C library, kept for backward compatibility). double log10(double x) logarithm to the base of 10: log10(x). double log2(double x) logarithm to the base of 2: log2(x). double log1p(double x) logarithm to the base of Euler\u0026rsquo;s number with argument plus 1: loge(1+x). double pow(double x, int y) raises to the specified integer power xy. double pow(double x, double y) raises to the specified floating point power xy. double sqrt(double x) computes a square root of x. double cbrt(double x) computes cubic root of x. double hypot(double x, double y) computes a hypotenuse of the right triangle using Pythogoras theorem: sqrt(x2+y2). double sin(double x) sine of an angle x in radians. double cos(double x) cosine of an angle x in radians. double tan(double x) tangent of an angle x in radians. double asin(double x) arc sine in radians. double acos(double x) arc cosine in radians. double atan(double x) arc tangent in radians. double atan2(double y, double x) arc tangent of the ratio y/x in radians. double sinh(double x) hyperbolic sine: (exp(x)-exp(-x))/2. double cosh(double x) hyperbolic cosine: (exp(x)+exp(-x))/2. double tanh(double x) hyperbolic tangent: (exp(x)-exp(-x))/(exp(x)+exp(-x)). double asinh(double x) inverse hyperbolic sine. double acosh(double x) inverse hyperbolic cosine. double atanh(double x) inverse hyperbolic tangent. double erf(double x) Gauss error function (special non-elementary function of sigmoid). double erfc(double x) complement of a Gauss error function. double tgamma(double x) absolute value of the Gamma function (an extension of a factorial function Γ(n)=(n-1)!). double lgamma(double x) natural logarithm of the Gamma function. double ceil(double x) the ceiling function, the smallest integer value not less than x. double floor(double x) the floor function, the largest integer value not greater than x. double trunc(double x) nearest integer not greater in magnitude than x. double round(double x) nearest integer value to x rounding halfway cases away from zero. int fint(double x) converts floating point value into integer (like trunc(), except returns an integer). double ldexp(double x, int y) multiplies by a specified power of two: x*2y. int ilogb(double x) extracts unbiased exponent: trunc(log2(x+1)). double logb(double x) extracts unbiased exponent: trunc(log2(x+1)). double nextafter(double from, double to) a next representable floating point value of from in the direction of to. double copysign(double x, double y) floating point value with magnitude of x and sign of y. bool signbit(double x) true if the argument x is negative. double random(double max) pseudo random number distributed uniformly over the range [0, max). double normal(double mean, double sd) pseudo random number according to Normal (Gaussian) distribution for a given mean and standard deviation sd (until Stratego-10). double random_normal(double mean, double sd) pseudo random number distributed according to Normal (Gaussian) distribution for a given mean and standard deviation sd (since Stratego-10). double random_poisson(double lambda) pseudo random number according to Poisson distribution for a given lambda expected number of occurances (since Stratego-10). double random_arcsine(double from, double till) pseudo random number according to Arcsine distribution over the range [from, till] (since Stratego-10). double random_beta(double alpha, double beta) pseudo random number distributed according to Beta distribution for alpha and beta shape parameters (since Stratego-10). double random_gamma(double shape, double scale) pseudo random number distributed according to Gamma distribution for the given shape and scale parameters (since Stratego-10). double random_tri(double from, double mode, double till) pseudo random number according to Triangular distribution over the range [from, till] with the given mode (since Stratego-10). double random_weibull(double shape, double scale) pseudo random number according to Weibull distribution for the given shape and scale parameters (since Stratego-10). A few common constants and types can be declared as follows (built-in since Stratego-10):\nconst int INT8_MIN = -128; const int INT8_MAX = 127; const int UINT8_MAX = 256; const int INT16_MIN = -32768; const int INT16_MAX = 32767; const int UINT16_MAX = 65535; const int INT32_MIN = -2147483648; const int INT32_MAX = 2147483647; typedef int[INT8_MIN, INT8_MAX] int8_t; typedef int[0, UINT8_MAX] uint8_t; typedef int[INT16_MIN, INT16_MAX] int16_t; typedef int[0, UINT16_MAX] uint16_t; typedef int[INT32_MIN, INT32_MAX] int32_t; const double FLT_MIN = 1.1754943508222875079687365372222456778186655567720875e-38; const double FLT_MAX = 340282346638528859811704183484516925440.0; const double DBL_MIN = 2.2250738585072013830902327173324040642192159804623318e-308; const double DBL_MAX = 1.79769313486231570814527423731704356798070567525845e+308; const double M_PI = 3.141592653589793115997963468544185161590576171875; // pi const double M_PI_2 = 1.5707963267948965579989817342720925807952880859375; // pi/2 const double M_PI_4 = 0.78539816339744827899949086713604629039764404296875; // pi/4 const double M_E = 2.718281828459045090795598298427648842334747314453125; // e const double M_LOG2E = 1.442695040888963387004650940070860087871551513671875; // log_2(e) const double M_LOG10E = 0.43429448190325181666793241674895398318767547607421875; // log_10(e) const double M_LN2 = 0.69314718055994528622676398299518041312694549560546875; // log_e(2) const double M_LN10 = 2.30258509299404590109361379290930926799774169921875; // log_e(10) const double M_1_PI = 0.31830988618379069121644420192751567810773849487304688; // 1/pi const double M_2_PI = 0.63661977236758138243288840385503135621547698974609375; // 2/pi const double M_2_SQRTPI = 1.1283791670955125585606992899556644260883331298828125; // 2/sqrt(pi) const double M_SQRT2 = 1.4142135623730951454746218587388284504413604736328125; // sqrt(2) const double M_SQRT1_2 = 0.70710678118654757273731092936941422522068023681640625; // sqrt(1/2) "},{"uri":"/language-reference/system-description/declarations/external-functions/","title":"External Functions","tags":[],"description":"","content":" The external functions are supported since Uppaal Stratego version 4.1.20-7, or Uppaal version 5.0 or later.\nExternal Functions is an expert user feature and requires a high-level understanding of dynamic library loading and linking.\nThe feature is supported on Linux and experimental on Windows and macOS.\nThe external function calls must be deterministic: for any argument values, the function should produce the same result at any time when called with the same values.\nUppaal does *not check and will not warn if an external function is behaving deterministically.\nFor example:\nSide-effect-free (or free) functions, which do not depend on static variables, are deterministic. Memoization pattern is not side-effect-free, but results in deterministic behavior. External Functions can be declared alongside other declaratios. External functions are local to the current scope, defined by the grammar:\nExternDecl = \u0026#39;import\u0026#39; Path \u0026#39;{\u0026#39; [FwdDeclList] \u0026#39;}\u0026#39; FwdDeclList = FwdDecl \u0026#39;;\u0026#39; | FwdDeclList FwdDecl \u0026#39;;\u0026#39; FwdDecl = [ID \u0026#39;=\u0026#39;] Type ID \u0026#39;(\u0026#39; [Parameters] \u0026#39;)\u0026#39; Path is a double-quoted (using \u0026quot;) character sequence (string) denoting a file path to the library placed on the same computer as the used engine (server or verifyta).\nNote that the backslash (\\) character in (Windows) paths needs to be either escaped with another backslash or replaced with the forwardslash (/), i.e. \\ should be replaced with either \\\\ or /. For example, \u0026quot;C:\\libexternal.dll\u0026quot; should be written as \u0026quot;C:\\\\libexternal.dll\u0026quot; or \u0026quot;C:/libexternal.dll\u0026quot;. The following code will load the external libary libexternal.so from the path /home/user/lib and import the functions get_number, set_number and is_the_world_safe. The function is_the_world_safe will be imported with the name is_safe.\nEven though Uppaal will attempt to locate the library in several default paths, we recommend using a fully qualified path to the library file.\nIf you are using integers in external function, we recommend defining a full integer range in order to avoid Uppaal int range ([-32768,32767]) errors.\nconst int INT32_MIN = -2147483648; // not needed since Stratego 4.1.20-11 const int INT32_MAX = 2147483647; // not needed since Stratego 4.1.20-11 typedef int[INT32_MIN,INT32_MAX] int32_t; // not needed since Stratego 4.1.20-11 import \u0026#34;/home/user/lib/libexternal.so\u0026#34; { int32_t get_number(); void set_number(int32_t n); int32_t get_sqrt(int32_t n); is_safe = bool is_the_world_safe(); }; Type Conversion and Restrictions The types transfarable between Uppaal and external functions are curretly limited to bool, int, double, clock, chan, ptr_t and string. Omitting complex types such as structs and nested data structures. Only single-dimentional arrays are supported on only mutable types; arrays of chan and strings are not currently supported.\nThe following table summarizes the current support:\nUPPAAL Type C Type By Value Return Array bool bool x x x int int32_t x x x double double x x x clock double x chan const char* ptr_t size_t x x x string const char* \u0026lt;type\u0026gt;[] \u0026lt;type\u0026gt; A violation of a range of a bounded integer (either pass-by-reference or return) will cause a runtime error.\nResource Initialization and Release The library is loaded during document parsing and the library can be instructed to initialize and release its resources using Special Functions.\nDefining External Library An external library can be compiled from C or C++ code and linked into a shared library. Uppaal uses C symbol name mangling, so C++ compiler needs to be instructed to export \u0026quot;C\u0026quot; names, whereas C compiler does it by default.\nThe following C/C++ code implements the library functions used for the example above.\nexternal.h:\n#ifndef LIBRARY_EXTERNAL_H #define LIBRARY_EXTERNAL_H #ifdef __cplusplus extern \u0026#34;C\u0026#34; { // tells C++ compiler to use C symbol name mangling (C compiler ignores) #endif // __cplusplus int get_number(); void set_number(int n); int get_sqrt(int n); bool is_the_world_safe(); #ifdef __cplusplus } // end of \u0026#34;C\u0026#34; symbol name mangling #endif // __cplusplus #endif // LIBRARY_EXTERNAL_H external.cpp:\n#include \u0026#34;external.h\u0026#34; #include \u0026lt;cmath\u0026gt; static int number = 42; // internal state, be careful #ifdef __cplusplus extern \u0026#34;C\u0026#34; { // tells C++ compiler to use C symbol name mangling (C compiler ignores) #endif // __cplusplus int get_number() { // is not free from side-effects, when set_number is used return number; } void set_number(int n) { // the state needs to be synchronized with the model state number = n; } int get_sqrt(int n) { return std::sqrt(n); } bool is_the_world_safe() { return true; } #ifdef __cplusplus } // end of \u0026#34;C\u0026#34; symbol name mangling #endif // __cplusplus Execute the following shell commands to compile the source external.cpp into object file external.o and then link external.o into a shared library libexternal.so:\ng++ -std=c++17 -Wpedantic -Wall -Wextra -fPIC -g -Og -o external.o -c external.cpp gcc -shared -o libexternal.so external.o For optimized builds replace -g Og with -DNDEBUG -O3 in the above command and strip the details with strip libexternal.so.\nFor more library examples please visit uppaal-libs repository.\nDebugging Inspect the library file using file /home/user/lib/libexternal.so:\nlibexternal.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, ... Inspect the dynamic library dependencies ldd /home/user/lib/libexternal.so:\nstatically linked This means that the library is linked with everything it needs and is self-contained, it does not require any additional libraries. Alternatively, one may see a list of required libraries and where the library loader (ld-linux.so) can (not) find them.\nInspect the exported dynamic symbols of the library using objdump -T /home/user/lib/libexternal.so:\nlibexternal.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000000000 w D *UND* 0000000000000000 __cxa_finalize 0000000000000000 w D *UND* 0000000000000000 _ITM_registerTMCloneTable 0000000000000000 w D *UND* 0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 w D *UND* 0000000000000000 __gmon_start__ 0000000000001120 g DF .text 0000000000000006 is_the_word_safe 0000000000001100 g DF .text 000000000000000a get_number 0000000000004008 g DO .data 0000000000000004 number 0000000000001110 g DF .text 000000000000000a set_number Similarly using nm -D /home/user/lib/libexternal.so:\nw __cxa_finalize 0000000000001100 T get_number w __gmon_start__ 0000000000001120 T is_the_word_safe w _ITM_deregisterTMCloneTable w _ITM_registerTMCloneTable 0000000000004008 D number 0000000000001110 T set_number (GNU compiler exports all symbols by default, hence number can be part of the exported symbol listing)\nOne can also inspect the library loading among all OS kernel calls, for example strace verifyta external.xml:\n... read(3, \u0026#34;\u0026lt;?xml version=\\\u0026#34;1.0\\\u0026#34; encoding=\\\u0026#34;ut\u0026#34;..., 4096) = 1332 getcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/lib/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = 4 read(4, \u0026#34;\\177ELF\\2\\1\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0\u0026gt;\\0\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\u0026#34;..., 832) = 832 newfstatat(4, \u0026#34;\u0026#34;, {st_mode=S_IFREG|0750, st_size=13920, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f30277e5000 mmap(0x7f30277e6000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f30277e6000 mmap(0x7f30277e7000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f30277e7000 mmap(0x7f30277e8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f30277e8000 close(4) = 0 mprotect(0x7f30277e8000, 4096, PROT_READ) = 0 read(3, \u0026#34;\u0026#34;, 4096) = 0 close(3) = 0 ... Here, one can see verifyta requesting for current directory (getcwd), and then opening /home/user/libexternal.so file (openat).\nAlternatively, one may find errors when some library is missing or a path is wrong:\ngetcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/wrong/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Errors when some symbol is not found (wrong function name):\ngetcwd(\u0026#34;/tmp/uppaal-lib\u0026#34;, 1024) = 16 read(3, \u0026#34;\u0026#34;, 4096) = 0 openat(AT_FDCWD, \u0026#34;/home/user/lib/libexternal.so\u0026#34;, O_RDONLY|O_CLOEXEC) = 4 read(4, \u0026#34;\\177ELF\\2\\1\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0\u0026gt;\\0\\1\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\\0\u0026#34;..., 832) = 832 newfstatat(4, \u0026#34;\u0026#34;, {st_mode=S_IFREG|0750, st_size=15264, ...}, AT_EMPTY_PATH) = 0 mmap(NULL, 16408, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7f988f7d5000 mmap(0x7f988f7d6000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x1000) = 0x7f988f7d6000 mmap(0x7f988f7d7000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f988f7d7000 mmap(0x7f988f7d8000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7f988f7d8000 close(4) = 0 mprotect(0x7f988f7d8000, 4096, PROT_READ) = 0 futex(0x7f988f6791f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 read(3, \u0026#34;\u0026#34;, 4096) = 0 close(3) = 0 write(2, \u0026#34;external.xml\u0026#34;, 12external.xml) = 12 write(2, \u0026#34;:\u0026#34;, 1:) = 1 write(2, \u0026#34;/nta/declaration\u0026#34;, 16/nta/declaration) = 16 write(2, \u0026#34;:\u0026#34;, 1:) = 1 write(2, \u0026#34;5\u0026#34;, 15) = 1 write(2, \u0026#34;: [\u0026#34;, 3: [) = 3 write(2, \u0026#34;error\u0026#34;, 5error) = 5 write(2, \u0026#34;] \u0026#34;, 2] ) = 2 write(2, \u0026#34;/home/user/lib/libexternal.so: \u0026#34;..., 68/home/user/lib/libexternal.so: undefined symbol: is_the_word_safe.) = 68 If the library implementation crashes, then one may try and debug it by loading verifyta with the specified model into a debugger or Integrated Development Environmnet (IDE) like Netbeans or Clion.\nIn order to step through the library calls, make sure that the library is compiled and linked with debug information (using -g -Og compiler arguments).\nAlternatively, we strongly suggest to use unit tests to call your library and inspect the behavior in the debugger or IDE, for example:\nexternal_test.cpp\n#include \u0026#34;external.h\u0026#34; #include \u0026lt;cassert\u0026gt; int main() { int seven = get_sqrt(50); assert(seven == 7); int two = get_sqrt(-4); assert(two == 2); } Compile external_test.cpp into external_test against libexternal.so in /home/user/lib and run:\ng++ -std=c++17 -Wpedantic -Wall -Wextra -g external_test.cpp -L/home/user/lib -lexternal -o external_test LD_LIBRARY_PATH=/home/user/lib ./external_test The test above may produce the following output:\nexternal_test: external_test.cpp:9: int main(): Assertion `two == 2\u0026#39; failed. Aborted (core dumped) Which means that the assertion two == 2 on line 9 of external_test.cpp is false.\nThe test above can be (re-)run using gdb debugger:\nLD_LIBRARY_PATH=/home/user/lib gdb ./external_test Reading symbols from ./external_test... (gdb) r Starting program: /tmp/uppaal-lib/external_test [Thread debugging using libthread_db enabled] Using host libthread_db library \u0026#34;/lib/x86_64-linux-gnu/libthread_db.so.1\u0026#34;. external_test: external_test.cpp:8: int main(): Assertion `two == 2\u0026#39; failed. Program received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=\u0026lt;optimized out\u0026gt;, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=\u0026lt;optimized out\u0026gt;, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007ffff7d61d2f in __pthread_kill_internal (signo=6, threadid=\u0026lt;optimized out\u0026gt;) at ./nptl/pthread_kill.c:78 #2 0x00007ffff7d12ef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007ffff7cfd472 in __GI_abort () at ./stdlib/abort.c:79 #4 0x00007ffff7cfd395 in __assert_fail_base (fmt=0x7ffff7e71a70 \u0026#34;%s%s%s:%u: %s%sAssertion `%s\u0026#39; failed.\\n%n\u0026#34;, assertion=assertion@entry=0x55555555602c \u0026#34;two == 2\u0026#34;, file=file@entry=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=line@entry=8, function=function@entry=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:92 #5 0x00007ffff7d0bdf2 in __GI___assert_fail (assertion=0x55555555602c \u0026#34;two == 2\u0026#34;, file=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=9, function=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:101 #6 0x00005555555551c7 in main () at external_test.cpp:8 (gdb) up #1 0x00007ffff7d61d2f in __pthread_kill_internal (signo=6, threadid=\u0026lt;optimized out\u0026gt;) at ./nptl/pthread_kill.c:78 78 in ./nptl/pthread_kill.c (gdb) #2 0x00007ffff7d12ef2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 26 ../sysdeps/posix/raise.c: No such file or directory. (gdb) #3 0x00007ffff7cfd472 in __GI_abort () at ./stdlib/abort.c:79 79 ./stdlib/abort.c: No such file or directory. (gdb) #4 0x00007ffff7cfd395 in __assert_fail_base (fmt=0x7ffff7e71a70 \u0026#34;%s%s%s:%u: %s%sAssertion `%s\u0026#39; failed.\\n%n\u0026#34;, assertion=assertion@entry=0x55555555602c \u0026#34;two == 2\u0026#34;, file=file@entry=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=line@entry=8, function=function@entry=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:92 92 ./assert/assert.c: No such file or directory. (gdb) #5 0x00007ffff7d0bdf2 in __GI___assert_fail (assertion=0x55555555602c \u0026#34;two == 2\u0026#34;, file=0x55555555600f \u0026#34;external_test.cpp\u0026#34;, line=8, function=0x555555556004 \u0026#34;int main()\u0026#34;) at ./assert/assert.c:101 101 in ./assert/assert.c (gdb) #6 0x00005555555551c7 in main () at external_test.cpp:9 9 assert(two == 2); (gdb) p two $1 = -2147483648 (gdb) In the log above, one can see that the binary is loaded from external_test.\nThe program is run by command r, then a crash is observed due to failed assertion two == 2.\nA call stack trace is printed using command bt, in particular it contains main () from our source file external_test.cpp.\nThen the debugger is instructed to go up in the call stack multiple times by issuing a command up and then blank command (simply enter, which repeats the last command).\nThen at the main function call, the code line assert(two == 2); is highlighted.\nAnd finally the value of variable two is printed using command p two. The value is -2147483648 which is not as expected, hence the assertion failed.\nIt is also possible to attach gdb to an already running process (like verifyta or Uppaal engine server), set break points and watches.\n"},{"uri":"/language-reference/system-description/system-definition/gantt-chart/","title":"Gantt Chart","tags":[],"description":"","content":"A Gantt chart, commonly used in project management, is a bar chart that shows activities displayed against time. On the left of the chart is a list of the activities and along the top is a suitable time scale. Each activity is represented by a bar; the position and length of the bar reflect the start date, duration and end date of the activity.\nIn UPPAAL Gantt Charts are used to automatic visualize traces in Concrete Simulator. One needs to specify the list of activities and for each activity, what the different colored parts of the bar should reflect.\nThe Gantt Chart specification is placed after the system definition. The syntax is defined by the following grammar:\nGanttDecl ::= \u0026#39;gantt {\u0026#39; GanttDef \u0026#39;}\u0026#39; GanttDef ::= \u0026#39;\u0026#39; | GanttDef NonTypeId GanttArgs \u0026#39;:\u0026#39; GanttExprList \u0026#39;;\u0026#39; GanttArgs ::= \u0026#39;\u0026#39; | \u0026#39;(\u0026#39; GanttDeclSelect \u0026#39;)\u0026#39; GanttDeclSelect ::= [Id] \u0026#39;:\u0026#39; [Type] | GanttDeclSelect \u0026#39;,\u0026#39; Id \u0026#39;:\u0026#39; Type GanttExprList ::= GanttExpr | GanttExprList \u0026#39;,\u0026#39; GanttExpr GanttExpr ::= [Expression] \u0026#39;-\u0026gt;\u0026#39; [Expression] | \u0026#39;for (\u0026#39; GanttEntrySelect \u0026#39;)\u0026#39; [Expression] \u0026#39;-\u0026gt;\u0026#39; [Expression] GanttEntrySelect ::= Id \u0026#39;:\u0026#39; Type | GanttEntrySelect \u0026#39;,\u0026#39; Id \u0026#39;:\u0026#39; Type The first part of GanttDef (the one before the colon) specifies the list of activities. The second part (the one after the colon) specifies for each activity, what the bar should reflect. An instance of GanttExpr consists of two expressions. The one before -\u0026gt; is evaluated to a boolean value. If it is evaluated to true, the expression after -\u0026gt; will be evaluated to an integer. Note that this integer is not necessarily a constant. The integer will be map to a color (e.g. 0 will be map to red and 1 to green), which is the color of the bar when the expression is evaluated to true. GanttDeclSelect and for (...) are to be considered as syntax shortcuts rather than constructs.\nExamples Sample color definitions:\nconst int C_RED = 0; const int C_GREEN = 1; const int C_BLUE = 2; const int C_PURPLE = 3; const int C_ORANGE = 5; const int C_YELLOW = 6; const int C_CYAN = 9; gantt { Red: true -\u0026gt; C_RED; Colors(i:int[0,32]): true -\u0026gt; i; } Scheduling gantt { Task(i : pid_t): Task(i).Ready -\u0026gt; 1, Task(i).Running -\u0026gt; 2, Task(i).Blocked -\u0026gt; 3, Task(i).Error -\u0026gt; 0, for(j : sid_t) Task(i).sema[j] -\u0026gt; 6; Scheduler: len==0 -\u0026gt; 0, len\u0026gt;0 -\u0026gt; 1; } Train Gate gantt { Xxxx: Train(0).Cross -\u0026gt; 0, Train(1).Cross -\u0026gt; 1, Train(2).Cross -\u0026gt; 2; Gate: true -\u0026gt; Gate.len; } Once declared, the Gantt chart is rendered in Concrete Simulator when enabled in the menu View \u0026gt; Gantt Chart.\n"},{"uri":"/toolsandapi/javaapi/","title":"Java API","tags":[],"description":"","content":"UPPAAL models can be created, loaded, saved, simulated and checked using libs/model.jar library. There is also javadoc included libs/model-javadoc.jar.\nA demonstrating example is included in the demo/ModelDemo.java file.\n"},{"uri":"/language-reference/system-description/parameters/","title":"Parameters","tags":[],"description":"","content":"Templates and functions are parameterised. The syntax for parameters is defined by the grammar for Parameters:\nParameters ::= [ Parameter (\u0026#39;,\u0026#39; Parameter)* ] Parameter ::= [Type] [ \u0026#39;\u0026amp;\u0026#39; ] [ID] [ArrayDecl]* In contrast to global and local declarations, the parameter list should not be terminated by a semicolon.\nCall by Reference and Call by Value Parameters can be declared to have either call-by-value or call-by-reference semantics. The syntax is taken from C++, where the identifier of a call-by-reference parameter is prefixed with an ampersand in the parameter declaration. Call-by-value parameters are not prefixed with an ampersand.\nClocks and channels must always be reference parameters.\nNote: Array parameters must be prefixed with an ampersand to be passed by reference, this does not follow the C semantics.\nExamples P(clock \u0026amp;x, bool bit) process template P has two parameters: the clock x and the boolean variable bit. Q(clock \u0026amp;x, clock \u0026amp;y, int i1, int \u0026amp;i2, chan \u0026amp;a, chan \u0026amp;b) process template Q has six parameters: two clocks, two integer variables (with default range), and two channels. All parameters except i1 are reference parameters. "},{"uri":"/gui-reference/concrete-simulator/process/","title":"Process Panel","tags":[],"description":"","content":"The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.\nClicking inside a process box with the right mouse button opens a pop-up menu with the following items:\nZoom In: increases the zoom of the process, Zoom Out: decreases the zoom of the process, Hide: hides the process, Export: opens a file dialog for saving the process in encapsulated postscript format. "},{"uri":"/language-reference/query-semantics/smc_queries/","title":"Semantics of the Statistical Queries","tags":[],"description":"","content":"UPPAAL can estimate the probability of expression values statistically. There are four types of statistical properties: quantitative, qualitative, comparison and probable value estimation.\nSee also Syntax of Statistical Queries.\nSimulation \u0026#39;simulate\u0026#39; \u0026#39;[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;{\u0026#39; List \u0026#39;}\u0026#39; [ \u0026#39;:\u0026#39; [ SATRUNS \u0026#39;:\u0026#39; ] Expression ] The simulation query collects the valuation of the specified list of expressions over the time, cost or action-transitions of the simulated run. The simulation runs can be filtered by a state expression after the colon (\u0026rsquo;:\u0026rsquo;) and the number of satisfying runs can be limited by positive integer using SMCBounds and SATRUNS. If the filtering expression is provided then the result also includes a probability confidence interval similar to Probability Estimation below.\nProbability Estimation (Quantitative Model Checking) \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; Quantitative query estimates the probability of a path expression being true given that the predicate in probability brackets is true. Intuitively the model exploration is bounded by an expression in the brackets: it can be limited by setting the bound on absolute model time, a clock value, or the number of steps (discrete transitions).\nThe result is an estimated probability confidence interval (CI), where the level of significance (probability that CI does not include the actual probability) is controlled by α and the width is controlled by ε in the statistical parameters. In addition the and a number of histograms over the values of the variable specified in the probability brackets. Note that histograms omit runs that do not satisfy the property.\nThe number of runs can be specified by the optional RUNS argument in the SMCBounds. If the argument is absent, then the number of runs is determined by a sequential CI estimation algorithm.\nSee also: CI Estimation\nHypothesis Testing (Qualitative Model Checking) \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; (\u0026#39;\u0026lt;=\u0026#39;|\u0026#39;\u0026gt;=\u0026#39;) ProbNumber Hypothesis testing checks whether the probability of a property is less or greater than specified bound. The query is more efficient than probability estimation as it is one sided and requires fewer simulations to attain the same level of significance.\nProbability Comparison \u0026#39;Pr[\u0026#39; SMCBounds \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; **\u0026#39;\u0026gt;=\u0026#39;** \u0026#39;Pr[\u0026#39; ( Variable | \u0026#39;#\u0026#39; ) \u0026#39;\u0026lt;=\u0026#39; CONST \u0026#39;](\u0026#39; (\u0026#39;\u0026lt;\u0026gt;\u0026#39; | \u0026#39;[]\u0026#39;) Expression \u0026#39;)\u0026#39; Compares two probabilities indirectly without estimating them.\nValue Estimation \u0026#39;E[\u0026#39; SMCBounds \u0026#39;]\u0026#39; \u0026#39;(\u0026#39; (\u0026#39;min:\u0026#39;|\u0026#39;max:\u0026#39; Expression \u0026#39;)\u0026#39; Estimates the value of an expression by running a given number of simulations.\nFull Weighted MITL MITLQuery = \u0026#39;Pr\u0026#39; MITLExpression MITLExpression = BExpr | (MITLExpression \u0026amp;\u0026amp; MITLExpression) | (MITLExpression || MITLExpression) | (MITLExpression \u0026#39;U\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (MITLExpression \u0026#39;R\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;X\u0026#39; MITLExpression) | (\u0026#39;\u0026lt;\u0026gt;\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression) | (\u0026#39;[]\u0026#39; \u0026#39;[\u0026#39; NAT \u0026#39;,\u0026#39; NAT \u0026#39;]\u0026#39; MITLExpression); BExpr describes a Boolean expression over clocks, variables, and locations. See rail road diagram of entire MITLExpression syntax:\nThe exact evaluation of the probability that a run satisfies a given weighted MITL formula.\nExamples Pr[\u0026lt;=100] (\u0026lt;\u0026gt; Train.Cross) estimates the probability of the process Train reaching the location Cross within 100 model time units. The tool will produce a number of histograms over model time, like probability density distribution of Train.Cross becoming true over model time, thus allowing to inspect what the most likely moment in time is when the train arrives at crossing. Pr[cost\u0026lt;=1000] (\u0026lt;\u0026gt; Plane.Landing) estimates the probability of the process Plane reaching the location Landing within 1000 cost units where clock variable cost has various rates in different locations. The tool will produce a number of histograms over the cost values, like a probability density distribution of Plane.Landing becoming true over cost, thus allowing to inspect what the most likely cost is when the plane lands. "},{"uri":"/gui-reference/symbolic-simulator/simulation-control/","title":"Simulation Control","tags":[],"description":"","content":"The simulation control is the left panel of the simulator. It is used to control the simulation and to select the (symbolic) state or transition to be visualized in the other two panels of the simulator. The control panel is divided in two parts:\nThe upper part is used for performing step-by-step simulation. A list view displays the enabled transitions, with the currently selected transition highlighted. Pressing the Next-button causes the simulated system to take the selected transition. The Reset-button is used to reset the simulated system to its initial state.\nThe lower part of the control panel has a view displaying the generated trace. The displayed trace is an alternating sequence of control location vectors and transitions. The simulation always progresses from the highlighted element in this view. It is possible to change the selection using the mouse.\nThe six buttons below the trace view have the following semantics:\nPrev: highlights the element immediately preceding the current selection (if any) in the trace. Next: highlights the element immediately following the current selection (if any) in the trace. Replay: replays the trace starting from the currently selected element. Open: opens a file dialog for loading a trace from file. Save: opens a file dialog for saving the current trace on file. The valid file extension is \u0026ldquo;xtr\u0026rdquo;. When no file extension is provided, it will be automatically appended. Random: starts a random simulation where the simulator proceed automatically by randomly selecting enabled transitions. The slider at the bottom of the control panel is used to control the speed used when traces are replayed and when random simulation is performed.\nKeyboard Shortcuts Key Shortcut to Z Move selection up in the enabled transitions list view. X Move selection down in the enabled transitions list view. Q Correspond to the button Prev. A Correspond to the button Next. P Correspond to the button Replay. R Correspond to the button Random. F Highlights the first element in the trace. L Highlights the last element in the trace. Toggle selection of an enabled transition. Follow the selected enabled transition. "},{"uri":"/language-reference/query-syntax/strategy_queries/","title":"Syntax of Strategy Queries","tags":[],"description":"","content":"Strategy Queries Strategy queries allow store, load, reuse and refine the strategies by assigning names to them.\nAssignQuery ::= \u0026#39;strategy\u0026#39; StrategyName \u0026#39;=\u0026#39; AssignableQuery AssignableQuery ::= ControlQuery | LearningQuery | \u0026#39;loadStrategy\u0026#39; Features \u0026#39;(\u0026#39; Path \u0026#39;)\u0026#39; NonAssignableQuery ::= SymbolicQuery | SMCQuery | \u0026#39;saveStrategy\u0026#39; \u0026#39;(\u0026#39; Path \u0026#39;,\u0026#39; StrategyName \u0026#39;)\u0026#39; StrategyName indicates the name of a strategy. Path is a double-quoted (using \u0026quot;) character sequence (string) denoting a file path on the same computer as the used engine (server or verifyta).\nNote that the backslash (\\) character in (Windows) paths needs to be either escaped with another backslash or replaced with the forwardslash (/), i.e. \\ should be replaced with either \\\\ or /. See rail road diagram of AssignableQuery in Query overview.\nExamples strategy Safe = A[] safe computes a safety/permissive strategy over the timed game model and stores it under the name Safe. A[] good under Safe checks that the predicate good is always satisfied when the player/controller sticks to actions permitted by Safe strategy. E\u0026lt;\u0026gt; goal under Safe checks that the goal state predicate is eventually satisfied when the player/controller uses Safe strategy. strategy SafeCheap = minE(cost)[\u0026lt;=10] {i,j} -\u0026gt; {d,f} : \u0026lt;\u0026gt; t\u0026gt;=10 under Safe refines Safe strategy into SafeCheap by minimizing the expected value of cost expression. saveStrategy(\u0026quot;folder/file.json\u0026quot;, Safe) writes Safe strategy to the file with path folder/file.json. strategy Safe = loadStrategy{i,j}-\u0026gt;{d,f}(\u0026quot;folder/file.json\u0026quot;) reads the strategy from the file with path folder/file.json and stores it under the name Safe. "},{"uri":"/gui-reference/system-editor/","title":"System Editor","tags":[],"description":"","content":"The system editor is used to create and edit the system to be analysed. A system description is defined by a set of process templates (possibly with local declarations), global declarations, and a system definition.\nIn this help section we describe how to use the left panel of the editor, called the navigation tree, how to draw automata with the editor, and where to place declarations. The system description language used in UPPAAL is described in the Language Reference section.\n"},{"uri":"/toolsandapi/","title":"Tools & API","tags":[],"description":"","content":"Chapter 1 Tools \u0026amp; API "},{"uri":"/gui-reference/symbolic-simulator/variables/","title":"Variables Panel","tags":[],"description":"","content":"The variables panel is the middle panel of the simulator. It displays the values of the data and clock variables in the current state or transition selected in the trace of the simulation control panel.\nThe data variable values are always shown as integers. The clock values are shown symbolically as a conjunction of clock guards of lower and upper bounds on individual clocks or differences between pairs of clocks (see Expressions section for more information on clock guards). The possible clock values of the associated state (or transition) are all possible solutions to the conjunction of all clock constraints. The symbols \u0026ldquo;[\u0026rdquo; and \u0026ldquo;]\u0026rdquo; are used for closed intervals and \u0026ldquo;(\u0026rdquo; and \u0026ldquo;)\u0026rdquo; for open intervals in the usual way.\nIf the selected element in the simulation control panel is a state, the variables panel shows the symbolic values of the state (in normal black color). If the selected element is a transition, the shown symbolic values are those of the immediately preceding state satisfying the guard(s) of the transition (shown in blue color).\nNote: variables can be hidden and displayed using the \u0026ldquo;Variables\u0026hellip;\u0026rdquo; item in the View menu. The representation of the clock constraints can also be changed from this menu, using the \u0026ldquo;Full DBM\u0026rdquo; item. When \u0026ldquo;Full DBM\u0026rdquo; is checked a constraint is shown for each pair of clocks, otherwise a minimum set of constraints is shown. The minimum set of constraints is such that all constraints that are in the full DBM but not in the minimum set can be derived from constraints in the minimum set.\n"},{"uri":"/gui-reference/menu-bar/view/","title":"View Menu","tags":[],"description":"","content":"The view menu is used to modify the appearance of the system currently shown in the system editor and the simulator. The items are:\nZoom: shows a sub menu with fixed zoom values, zoom to fit, and itemes for zooming in, out, or to normal size. A change in the zoom value affects the templates the editor or the processes in the simulator (if one of the tools is active).\nLabels: shows a sub menu from which one can select which type of labels should be shown in the drawing area. Even when hidden, all labels can be seen in the tooltip of locations and edges.\nShow Grid: the drawing grid is shown when this item is checked.\nSnap to Grid: makes new drawing objects (such as locations, nails, and labels) align to the snap grid. The size of the snap grid is related to the size of the drawing grid.\nNote: the Snap to Grid option can be used even if the drawing grid is not shown.\nCoarser: increases the distance between the lines in the drawing grid.\nTighter: decreases the distance between the lines in the drawing grid.\nMark Visited highlights the locations and edges traversed by a trace in the simulator process panel.\nShow Coverage shows graphs of location and edge coverage dynamics over the simulated trace in a popup window. The Mark Visited option above enables this menu item.\nReload Simulator: uploads the system currently loaded in the editor, to the simulator and the verifier.\nProcesses: displays a dialog window for hiding and showing processes in the process panel of the simulator.\nVariables: shows a dialog window for hiding and showing variables in the variables panel of the simulator.\nFull DBM: shows all constraints on the clocks in the variables panel of the simulator. If not selected a minimal number of constraints will be shown.\n"},{"uri":"/language-reference/query-semantics/smc_queries/ci_estimation/","title":"Confidence Intervals","tags":[],"description":"","content":"Probability estimation query Pr[\u0026hellip;](\u0026lt;\u0026gt; q) yields a confidence interval (CI) for the probability of the state expression q being true with the confidence level of 1-α. For example, it could be [0.45, 0.55] (95% CI), or could be written as 0.5 ± 0.05 (95% CI), where ε=0.05 and α=0.05.\nThe frequentist interpretation of CI is that there exists a true probability that the state expression q is true and it is included in that confidence interval, but there is a risk α of making an error (the true probability being outside the confidence interval).\nChernoff-Hoeffding bound N=ln(2/α)/(2ε2) provides an intuition that the number of required samples (runs) N is inversely proportional to ε2 and proportional to the ln(1/α). This result assumes that the measurements are sampled from a continuous interval [0,1] which makes it overly conservative. For example, for α=0.05 and ε=0.05 it requires 738 runs irrespective of the actual probability. However, if the samples are constrained to either 0 or 1 and we observe a repetitive sequence of 30 successes we could conclude much earlier with [0.9,1] (95% CI) just by using a statistical rule of three.\nInstead, UPPAAL uses Clopper-Pearson exact method for binomial distribution which samples from {0,1} and provides more precise bounds with fewer runs, especially when the probability is close to 0 or 1.\nIf the number of runs is not specified in the query, then the probability estimation uses Clopper-Pearson algorithm sequentially to determine when to stop generating the simulation runs thus allowing earlier termination. Therefore the number of runs is sensitive to α, ε and also the estimated probability itself. The α and ε parameters are controlled in the statistical parameters of engine options.\nThe following plots show the number of samples (runs) required to estimate the confidence interval using the exact method sequentially for a given α, ε and the true probability (estimating P\u0026gt;0.5 is symmetric to estimating 1-P): For example, for the default parameter values ε=0.05 and α=0.05 the sequential algorithm requires 411 — the highest number of samples (runs) — when the probability is close to 0.5, where the uncertainty is the highest. Whereas the algorithm cannot distinguish the true probabilities ≤ ε (0.05) and thus could terminate much earlier: after 72 runs. Note that the uncertainty of the required runs is the largest when the true probability is close to either 0 or 1.\nThe following plot shows the number of samples (runs) required when the width of the interval is halved to ε=0.025: The following plot shows the number of samples (runs) required when the width of the interval is even more narrow ε=0.01: The following series of plots demonstrates how the estimated confidence interval converges to the true probability P value as more samples are produced:\nNote that occasionally the confidence intervals may overstep and thus exclude the true probability value, which should not happen more often than the specified level of significance α.\nThe following sequence of plots show how the width of the confidence intervals converges as more samples are produced:\nNote that in case of extreme probability value (close to 0 or 1, e.g. P=0.01), repeated observations are more likely and thus they may create false confidence that the probability is extreme (i.e. 0 or 1), but then a single differing observation may disturb the interval size greately and therefore more samples are required than just single sided interval.\nSeveral sequential CI estimation algorithms for binomial proportion are described in the literature below.\nFixed-Width Sequential Confidence Intervals for a Proportion, Jesse Frey. The American Statistician Volume 64, 2010 - Issue 3. doi:10.1198/tast.2010.09140\nExact Group Sequential Methods for Estimating a Binomial Proportion, Zhengjia Chen and Xinjia Chen. Journal of Probability and Statistics, 2013, special issue \u0026ldquo;Adaptive and Sequential Methods for Clinical Trials\u0026rdquo;. doi:10.1155/2013/603297\n"},{"uri":"/extensions/","title":"Extensions","tags":[],"description":"","content":"Chapter 4 Extensions CORA ECDAR UPPAAL Tiga UPPAAL TRON "},{"uri":"/gui-reference/concrete-simulator/sequence-chart/","title":"Message Sequence Chart","tags":[],"description":"","content":"The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).\nIn the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.\n"},{"uri":"/gui-reference/symbolic-simulator/process/","title":"Process Panel","tags":[],"description":"","content":"The process panel is the rightmost upper panel of the simulator. It displays the process instances of the system descriptions. A red token marks the current control point of each automaton. One or more of the automata edges may also be red to indicate the transition currently selected in the simulation control panel.\nClicking inside a process box with the right mouse button opens a pop-up menu with the following items:\nZoom In: increases the zoom of the process, Zoom Out: decreases the zoom of the process, Hide: hides the process, Export: opens a file dialog for saving the process in encapsulated postscript format. Note: several items in the View menu affect the processes in the process panel. For example, the \u0026ldquo;Processes\u0026hellip;\u0026rdquo; item may be used to hide and show processes.\n"},{"uri":"/language-reference/reserved-keywords/","title":"Reserved Keywords","tags":[],"description":"","content":"The reserved keywords that should not be used as identifier names when defining systems are: chan, clock, double, bool, int, commit, const, urgent, broadcast, init, process, state, invariant, location, guard, sync, assign, system, trans, deadlock, and, or, not, imply, true, false, for, forall, exists, while, do, if, else, return, typedef, struct, rate, before_update, after_update, meta, priority, progress, scalar, select, void, default, string, minE, maxE, Pr.\nThe following keywords are reserved for future use: switch, case, continue, break, enum.\n"},{"uri":"/toolsandapi/socketserver/","title":"Socketserver","tags":[],"description":"","content":"To start a remote server, use the socketserver binary (included for Linux, SunOS and MacOS). To use a remote server, see the section on command line options for the GUI.\nThe socketserver can be executed from the command line using one of the following commands:\nsocketserver [-p] [-s]\nsocketserver -h\nThe available command line options are:\n-h Prints a brief description of the command line options. -p Set port in server mode (default is 2350). -s Set filename of server binary to P2. The socketserver will load the server from the directory where it was invoked, and act as a proxy.\n"},{"uri":"/gui-reference/symbolic-simulator/","title":"Symbolic Simulator","tags":[],"description":"","content":"The simulator is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. In this sense, it provides an inexpensive mean of fault detection prior to verification by the model-checker. The simulator is also used to visualise executions (i.e. symbolic traces) generated by the verifier. Please see the Symbolic Traces section for a brief introduction of the concept.\nThe simulator consist of four panels: the leftmost called simulation control, the middle called variables, the upper right called processes, and the lower right called message sequence chart.\n"},{"uri":"/language-reference/system-description/system-definition/","title":"System Definition","tags":[],"description":"","content":"In the system definition, a system model is defined. Such a model consists of one or more concurrent processes, local and global variables, and channels.\nGlobal variables, channels and functions can be defined in the system definition using the grammar for declarations. Such declarations have a global scope. However, they are not directly accessible by any template, as they are declared after the templates. They are most useful when giving actual arguments to the formal parameters of templates. The declarations in the system definition and in the top-level declarations section are part of the system model.\nThe processes of the system model are defined in the form of a system declaration line, using the grammar for System given below. The system line contains a list of templates to be instantiated into processes. Processes can be prioritised as described in the section on priorities.\nSystem ::= \u0026#39;system\u0026#39; ID ((\u0026#39;,\u0026#39; | \u0026#39;\u0026lt;\u0026#39;) ID)* \u0026#39;;\u0026#39; Templates without parameters are instantiated into exactly one process with the same name as the template. Parameterised templates give rise to one process per combination of arguments, i.e., UPPAAL automatically binds any free template parameters. Any such parameter must be either a call-by-value bounded integer and or a call-by-value scalar. Individual processes can be referenced in expressions using the grammar for Process given below. Notice that this is already covered by the grammar for expressions.\nProcess ::= ID \u0026#39;(\u0026#39; [Arguments] \u0026#39;)\u0026#39; It is often desirable to manually bind some or all formal parameters of a template to actual arguments. This can be done by partial instantiation of templates.\nAny progress measures for the model or Gantt chart are defined after the system line.\nExample In this example we use the textual syntax for template declaration as used in the XTA format. In the GUI, these templates would be defined graphically.\nprocess P() { state s...; ... } process Q(int[0,3] a) { state t...; ... } system P, Q; This defines a system consisting of five processes named P, Q(0), Q(1), Q(2) and Q(3). Automatic binding of template parameters is very useful in models in which a large number of almost identical processes must be defined, e.g., the nodes of a network in a model of a communication protocol. In order to express that, e.g., all Q processes must be in location s, an expression like forall (i : int[0,3]) Q(i).s suffices.\n"},{"uri":"/gui-reference/menu-bar/tools/","title":"Tools Menu","tags":[],"description":"","content":"The tools menu contains a set of tools useful in the system edtior. The items are:\nCheck Syntax: checks if syntax and types are correct in the edited system. Any found errors and warnings are listed in the lower part of the drawing area of the system editor, and (when applicable) underlinded in the automata. Convert Syntax: assists in convering a system complying with the syntax used in UPPAAL 3.4 to the current syntax. Align to Grid: makes all existing objects of the current template align to the specified drawing grid. Plot Composer: creates a new Plot Composer window to superimpose multiple results from statistical model checking in the Verifier. "},{"uri":"/gui-reference/concrete-simulator/","title":"Concrete Simulator","tags":[],"description":"","content":"The concrete simulator is similar to the symbolic simulation in the sense that it is a validation tool that enables examination of the possible dynamic executions of a system during early design (or modeling) stages. The difference is that the simulation is based on concrete traces, i.e. one can choose a specific time to fire a transition. The tool helps to see at which time a transition can be fired.\nThe concrete simulator consists of the following panels:\nSimulation Control Variables Panel Process Panel Message Sequence Chart Gantt Chart Panel "},{"uri":"/toolsandapi/file-formats/","title":"File Formats","tags":[],"description":"","content":"UPPAAL supports three file formats for models: XML, XTA and TA. XML and XTA files can be loaded and stored via the Open Project, Open System, Save System, and Save System As menus. When saving a file, the file type is determined by the file name extension used. Each format is explained in more details below.\nNotice that the above mentioned file formats are mostly independent from the type of changes made to the syntax between UPPAAL 3.4 and UPPAAL 4.0.\nIn additon to the file formats for models, UPPAAL uses clear text query files for storing queries and the XTR file format for storing traces.\nXML The newest format is XML based and files in this format have the ending .xml. This format supports all features of UPPAAL. Elements like templates, locations, edges and labels are described using tags. This format was introduced in the GUI in version 3.2. As of version 3.4, the XML format is also supported by the verification engine. The GUI uses this format as its native file format. The addition of colors and notes on labels and edges, and the select expresssion on edges in UPPAAL 4.0 has resulted in the addition of a color attribute and two new label types. If these features are not used, the XML files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.\nThe level of abstraction in the format is chosen so that the format is independent of the actual syntax of declarations, invariants, guards, etc. Thus all labels are simply treated as strings without structure. In a GUI, this is very important, since the user might enter arbitrary text into the label fields and the file format must be able to cope with this situation. Before the introduction of the XML format, the XTA format was used. With this format it was not possible to save syntactically incorrect systems, i.e., if the user made a mistake in the syntax of a label it was not possible to save this systems.\nXTA The XTA format was introduced in version 3.0. This format can only reliably store syntactically correct systems. Anonymous locations are not supported by this format (UPPAAL automatically assigns a unique name to anonymous locations when saved to an XTA file). Graphical information (coordinates) about the objects are stored in a separate UGI file, although this is transparent to the user. XTA files use the ending .xta and UGI files the ending .ugi.\nIn UPPAAL 4.0, the XTA format was extended with support for the select expression on edges. The UGI format was extended with support for the color attributes. If these features are not used, the XTA files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.\nTA The TA format is a subset of the XTA format and does not support the template concept nor does it contain any graphical information about the system. UPPAAL can no longer save files in this format, although TA files can still be read.\nQuery files Query files use a clear-text format listing all queries inleaved with comments. The format dates back to UPPAAL 2. Files in this format have the file ending .q.\nTrace files Traces can be stored using the XTR format and files in this format have the file ending .xtr. The format was introduced in UPPAAL 3.0.\nXTR files are intimately linked to the model from which they were generated. Any change (other than layout and white space changes) in the model may render the trace file unreadable. Even reordering some variable declarations will break the link.\nOur parser library, libutap, contains a small utility called tracer, which can read XTR files and translate them to a human readable format. The library and the utility are released under the LGPL license and may thus be used as a starting point for writing custom trace analysis tools. More information about the library can be found on the UPPAAL web page.\n"},{"uri":"/gui-reference/concrete-simulator/gantt-chart/","title":"Gantt Chart Panel","tags":[],"description":"","content":"The Gantt Chart panel is the middle rightmost panel of the simulator. It displays another view of the generated trace according to the Gantt Chart specification given in system definition.\nIn the Gantt Chart view, the horizontal axis represents the time span, and in the vertical axis the list of activities (usually some of the system processes) defined in the Gantt chart specification are listed. A vertical line is used to represent the current time (which corresponds to the one displayed in the Simulation Trace-combo box). Horizontal bars of varying lengths and colors represent when the different expressions in the Gantt chart specification are satisfied according to the current state of the trace.\nIf the mouse is placed over a Gantt bar, information about the intervals when the corresponding expressions are satisfied are shown.\n"},{"uri":"/gui-reference/symbolic-simulator/sequence-charts/","title":"Message Sequence Chart","tags":[],"description":"","content":"The Message Sequence Chart (MSC) panel is the lower rightmost panel of the simulator. It displays an MSC view of the generated trace (also displayed in the simulation control panel of the simulator).\nIn the MSC view there is a vertical line for each process, and a horizontal line for each synchronisation point. The process name of each vertical line is indicated in the upper part of the MSC panel. The node names shown on the vertical lines indicate the control location of the automaton. If the mouse is placed over the MSC all control location names at the position are shown. If a position is selected, the process panel and the simulation control panel are updated accordingly.\n"},{"uri":"/gui-reference/menu-bar/options/","title":"Options Menu","tags":[],"description":"","content":"The options menu contains settings to control the behavior of the model-checker.\nSearch Order This option influences the order in which the state space is explored.\nBreadth first Search the state space in breadth first search order. This is typically the most efficient option when the complete state space must be searched. When generating shortest or fastest traces, this is likely the best setting. Depth first Search the state space in depth first search order. If a counter example or witnessing trace is expected to exist, this setting is usually better than the breadth first setting. It is not recommended to use this search order when generating shortest or fastest traces. Random depth first Search the state space in randomised depth first search order. If a counter example or witnessing trace is expected to exist, this is usually the best setting. Due to the randomisation, traces may vary from run to run. It is not recommended to use this search order when generating shortest or fastest traces. State Space Reduction When searching the state space, UPPAAL does not necessarily have to store all states in memory in order to guarantee termination. This option influences how aggressively UPPAAL tries to avoid storing states. There is normally a tradeoff between space and speed.\nNone Store all states. Conservative Avoid storing committed states. Aggressive Avoid storing more than one state per cycle. State Space Representation This option determines how the state space should be represented in the model checker.\nSome representations are approximative in the sence that either a larger or smaller state space than the real one is generated. When an approximative representation is used, UPPAAL may conclude that a query is maybe satisfied, i.e., UPPAAL cannot make a decisive conclusions given the representation selected.\nDifference Bound Matrices (DBM) DBMs are often fast, but for models with many clocks they require a lot of memory. Compact Data Structure A more compact, but slower representation than DBMs. In particular for models with many clocks, this setting will often significantly reduce memory consumption. Even for models with no or few clocks, this option enables other memory saving techniques at the expense of speed. Under Approximation Uses bit-state hashing to represent the state space. This results in an under approximation, however the degree of approximation can be adjusted by adjusting the size of the hash table: Large hash tables result in a larger part of the state space being searched. The hash table size can be selected with the hash table size option. Over Approximation Uses convex-hull approximation of zones. This results in an over approximation of the state space. For models without clocks, this setting has no effect. Note that if a model contains stopwatches (invariant expressions like x'==0 where x is a clock), then the resulting analysis is overapproximate even if DBM or Compact Data Structure options are selected (DBM cannot represent additional constraints required by stopwatches). In such case, UPPAAL may also report that a reachability propery is maybe satisfied, meaning that the found counter-example trace may be spurious (i.e. not realizable).\nDiagnostic Trace This option controls if a counter-example or witnessing trace (if there is one) should be generated during verification. The trace is loaded into the simulator after verification. Enabling trace generation has two side effects:\nOnly one property at a time can be verified. Symmetry reduction is disabled. The possible settings for trace generation are:\nNone Do not generated any diagnostic trace. Some Generate a diagnostic trace. Shortest Generate a shortest trace, i.e. a trace with the smallest number of transitions. Fastest Generate a fastest trace, i.e. a trace with the shortest accumulated time delay. Extrapolation The range of clocks is unbounded, i.e., clocks can obtain arbitrarily large real values. To guarantee termination, UPPAAL uses an abstraction techniques called extrapolation. The extrapolated state space is finite. UPPAAL implements a number of extrapolation techniques that differ in the size of the extrapolated state space. Not all extrapolation techniques preserve all properties for all kinds of models. UPPAAL automatically selects the coarsets extrapolation, which still preserves the property being analysed.\nSometimes it may be of benefit to use a coarser (and faster) extrapolation that the one selected by UPPAAL. By doing so, the analysis will use an over-approximation of the state space. Listed from finest to coarsets, the choices are: None, Difference, Local, and Lower/Upper.\nAutomatic Selects the coarsest extrapolation preserving the property being analysed. If in doubt, use this setting. None Do not use extrapolation. Termination is no longer guaranteed. Since performing the extrapolation is relatively expensive, this may be of use if you know that the symbolic state space is finite. Difference Used whenever the model or the query contain difference constraints over clocks, e.g., x - y \u0026lt; 3. Local Used whenever the query contains either the deadlock keyword or involves a liveness property (except if the model or the query contain difference constraints). Lower/Upper Used whenever a reachability analysis is performed, except when the deadlock keyword is used or when the model or the query contain difference constraints. Hash table size Adjusts the amount of memory used to represent the state space when using bit-state hashing. This option has no effect unless under approximation is selected.\nReuse When selected, instructs the verifier to (whenever possible) reuse the generated portion of the state space when several properties of the same system are checked.\nStatistical Parameters Lower probabilistic deviation (-δ) Used in hypothesis testing (qualitative model-checking) to specify the lower bound of indifference region from the specified probability. Upper probabilistic deviation (+δ) Used in hypothesis testing (qualitative model-checking) to specify the upper bound of indifference region from the specified probability. Probability of false positives (α) Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) \u0026lt;= 0.5) and probability estimation (quantitative model-checking queries like Pr[...](...)) to specify the level of significance (probability of Type I error). Probability of false negatives (β) Used in hypothesis testing (qualitative model-checking queries like Pr[...](...) \u0026lt;= 0.5) to specify the level of significance (probability of Type II error). Probability uncertainty (ε) Used in probability estimation (qualitative model-checking) to constrain the size of the confidence interval in a form of p ± ε (1-α CI). Ratio lower bound (u0) Used in comparison of two probabilities. Ratio upper bound (u1) Used in comparison of two probabilities. Histogram bucket width Specifies the width of each column in the histogram. By default it is set to zero meaning that the width is determined by ratio of entire histogram width divided by a bucket count. Histogram bucket count Specifies the number of columns in the histogram. By default it is set to zero meaning that the count is determined by taking a square root of a total number of samples and dividing by four. More Information The compact data structure and the options for state space reduction are described in the following paper:\nEfficient Verification of Real-Time Systems: Compact Data Structure and State Space Reduction, Kim G. Larsen, Fredrik Larsson, Paul Pettersson and Wang Yi. In Proceedings of the 18th IEEE Real-Time Systems Symposium, pages 14-24. San Francisco, California, USA, 3-5 December 1997.\n"},{"uri":"/language-reference/system-description/priorities/","title":"Priorities","tags":[],"description":"","content":"Given some priority order on the transitions, the intuition is that, at a given time-point, a transition is enabled only if no higher priority transition is enabled (see also Semantics.) We say that the higher priority transition blocks the lower priority transition.\nPriorities can be assigned to the channels and processes of a system. The priority orders defined in the system are translated into a priority order on tau-transitions and synchronizing transitions. Delay transitions are still non-deterministic (unless urgent channels are used.)\nPriorities on Channels Priorities on Processes Priorities on both Channels and Processes Priorities on Channels ChanPriority ::= \u0026#39;chan\u0026#39; \u0026#39;priority\u0026#39; (ChanExpr | \u0026#39;default\u0026#39;) ((\u0026#39;,\u0026#39; | \u0026#39;\u0026lt;\u0026#39;) (ChanExpr | \u0026#39;default\u0026#39;))* \u0026#39;;\u0026#39; ChanExpr ::= ID | ChanExpr \u0026#39;[\u0026#39; Expression \u0026#39;]\u0026#39; A channel priority declaration can be inserted anywhere in the global declarations section of a system (only one per system). The priority declaration consist of a list of channels, where the \u0026lsquo;\u0026lt;\u0026rsquo; separator defines a higher priority level for channels listed on its right side. The default priority level is used for all channels that are not mentioned, including tau transitions.\nNote: the channels listed in the priority declaration must be declared earlier.\nExample chan a,b,c,d[2],e[2]; chan priority a,d[0] \u0026lt; default \u0026lt; b,e; The example assigns the lowest priority to channels a and d[0], and the highest priority to channels b, e[0] and e[1]. The default priority level is assigned to channels c and d[1].\nPriorities on Processes Process priorities are specified on the system line, using the separator \u0026lsquo;\u0026lt;\u0026rsquo; to define a higher priority for processes to its right. If an instance of a template set is listed, all processes in the set will have the same priority.\nExample system A \u0026lt; B,C \u0026lt; D; Resolving Synchronization In a synchronisation the process priorities are ambigous, because more than one process is involved in such a transition.\nWhen several processes synchronize, the priority of the transition is given by the highest priority of the processes. This applies to both standard synchronization and broadcast.\nPriorities on both Channels and Processes In a system with priorities on both processes and channels, priorities are resolved by comparing priorities on channels first. If they are the same, the process priorities are compared.\n"},{"uri":"/gui-reference/menu-bar/help/","title":"Help Menu","tags":[],"description":"","content":"The help menu has two items: Help which opens a separate window showing the help pages, and About which opens a window showing the version number and information about the copyrights of UPPAAL.\n"},{"uri":"/toolsandapi/latex/","title":"Latex","tags":[],"description":"","content":"UPPAAL web site includes links to uppaal.sty file — style for typesetting documents in LaTeX.\nUPPAAL Latex "},{"uri":"/language-reference/system-description/scope-rules/","title":"Scope Rules","tags":[],"description":"","content":"The scope rules determine which element a name refers to in a given context. The context is either local (to a process template), or global (in a system description).\nIn a local context, the names are always referring to local declarations or formal parameters (if the name is locally defined), otherwise to a globally declared name.\nIn the global context, a name is always referring to a global declaration.\nNote: There is only one name space in each context. This means that in each context all declared clocks, integer variables, constants, locations, and formal paramters must have unique names. However, local names may shadow globally declared names.\n"},{"uri":"/language-reference/system-description/semantics/","title":"Semantics","tags":[],"description":"","content":"In the following we give a pseudo-formal semantics for UPPAAL. The semantics defines a timed transition system (S, s0, →) describing the behaviour of a network of extended timed automata. The set of states S is defined as {(L, v) | v ⊨ Inv(L)}, where L is a location vector, v is a function (called a valuation) mapping integer variables and clocks to their values, and Inv is a function mapping locations and location vectors to invariants. The initial state s0 is the state where all processes are in the initial location, all variables have their initial value, and all clocks are zero. The transition relation, →, contains two kinds of transitions: delay transitions and action transitions. We will describe each type below.\nGiven a valuation v and an expression e, we say that v satisfies e if e evaluates to non-zero for the given valuation v.\nInvalid Evaluations If during a successor computation any expression evaluation is invalid (consult the section on expressions for further details about invalid evaluations), the verification is aborted.\nDelay Transitions Delay transitions model the passing of time without changing the current location. We have a delay transition (L, v) −d→ (L, v\u0026rsquo;), where d is a non-negative real, if and only if:\nv\u0026rsquo; = v+d, where v+d is obtained by incrementing all clocks with d. for all 0 ≤ d\u0026rsquo; ≤ d: v+d\u0026rsquo; ⊨ Inv(L) L contains neither committed nor urgent locations for all locations ℓ in L and for all locations ℓ\u0026rsquo; (not necessarily in L), if there is an edge from ℓ to ℓ\u0026rsquo; then either: this edge does not synchronise over an urgent channel, or this edge does synchronise over an urgent channel, but for all 0 ≤ d\u0026rsquo; ≤ d we have that v+d\u0026rsquo; does not satisfy the guard of the edge. Action Transitions For action transtions, the synchronisation label of edges is important. Since UPPAAL supports arrays of channels, we have that the label contains an expression evaluating to a channel. The concrete channel depends on the current valuation. To avoid cluttering the semantics we make the simplifying assumption that each synchronisation label refers to a channel directly.\nPriorities increase the determinism of a system by letting a high priority action transition block a lower priority action transition. Note that delay transitions can never be blocked, and no action transition can be blocked by a delay transition.\nFor action transitions, there are three cases: Internal transitions, binary synchronisations and broadcast synchronisations. Each will be described in the following.\nInternal Transitions We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there is an edge e=(ℓ,ℓ\u0026rsquo;) such that:\nthere is no synchronisation label on e v satisfies the guard of e L\u0026rsquo; = L[ℓ\u0026rsquo;/ℓ] v\u0026rsquo; is obtained from v by executing the update label given on e v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either ℓ is committed or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Binary Synchronisations We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there are two edges e1=(ℓ1,ℓ1\u0026rsquo;) and e2=(ℓ2,ℓ2\u0026rsquo;) in two different processes such that:\ne1 has a synchronisation label c! and e2 has a synchronisation label c?, where c is a binary channel. v satisfies the guards of e1 and e2. L\u0026rsquo; = L[ℓ1\u0026rsquo;/ℓ1, ℓ2\u0026rsquo;/ℓ2] v\u0026rsquo; is obtained from v by first executing the update label given on e1 and then the update label given on e2. v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either ℓ1 or ℓ2 or both locations are committed, or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Broadcast Synchronisations Assume an order p1, p2, … pn of processes given by the order of the processes in the system declaration statement. We have a transition (L, v) −*→ (L\u0026rsquo;, v\u0026rsquo;) if there is an edge e=(ℓ,ℓ\u0026rsquo;) and m edges ei=(ℓi,ℓi\u0026rsquo;) for 1≤i≤m such that:\nEdges e, e1, e2, …, em are in different processes. e1, e2, …, em are ordered according to the process ordering p1, p2,… pn. e has a synchronisation label c! and e1, e2, …, em have synchronisation labels c?, where c is a broadcast channel. v satisfies the guards of e, e1, e2, … em. For all locations ℓ in L not a source of one of the edges e, e1, e2, … em, all edges from ℓ either do not have a synchronisation label c? or v does not satisfy the guard on the edge. L\u0026rsquo; = L[ℓ\u0026rsquo;/ℓ, ℓ1\u0026rsquo;/ℓ1, ℓ2\u0026rsquo;/ℓ2, … ℓm\u0026rsquo;/ℓm] v\u0026rsquo; is obtained from v by first executing the update label given on e and then the update labels given on ei for increasing order of i. v\u0026rsquo; satisfies Inv(L\u0026rsquo;) Either one or more of the locations ℓ, ℓ1, ℓ2, … ℓm are committed, or no other location in L is committed. There is no action transition from (L, v) with a strictly higher priority. Probabilistic Transitions In statistical model checking the concrete delay and transition are determined as follows:\nEach process chooses a delay based on its current location: If the current location invariant has a time bound, then the concrete delay is taken according uniform distribution up to that bound. Otherwise (the time invariant is absent) the delay is chosen by exponential distribution using the rate λ specified on the current location. The probability density function of delay d∈[0;∞) is F(d)=λe−λd, where e=2.718281828… and the concrete delay is generated by −ln(u)/λ where u is a uniform random number from (0;1] interval. The process with the shortest delay is chosen. If there are several such processes then a random one of these is chosen (according to uniform distribution). The shortest delay is executed and continuous variables are updated. The chosen process attempts to take a transition: Compute all enabled internal and sending edge-transitions. Pick the concrete edge according to uniform distribution. If the edge has probabilistic branches, then the probability of taking a branch i is determined by the ratio wi/W, where wi is the weight of the branch i and W is the sum of all branch weights: W=Σjwj. Statistical model checking has the following assumptions about the model:\nInput enableness (non-blocking inputs): Sending cannot be blocked, i.e. the channel is either broadcast or there is always one process with an enabled receiving edge-transition. Input determinism: There is exactly one enabled receiving edge-transition at a time. For binary synchronizations there is at most one receiving process at a time. For more details about probabilistic semantics of priced timed automata please see:\nStatistical Model Checking for Networks of Priced Timed Automata, Alexandre David, Kim G. Larsen, Axel Legay, Marius Mikučionis, Danny Bøgsted Poulsen, Jonas van Vliet and Zheng Wang. In Proceedings of the 9th International Conference on Formal Modeling and Analysis of Timed Systems (FORMATS), Aalborg, Denmark, September 2011.\n"},{"uri":"/gui-reference/symbolic-simulator/symbolic-traces/","title":"Symbolic Traces","tags":[],"description":"","content":"Since clocks range over the non-negative reals, timed automata can have infinitely many states (not to be confused with locations) and infinitely many traces. The simulator cannot visualize all these concrete traces. Instead it shows an infinite set of traces - a so called symbolic trace. Each symbolic state of a symbolic trace is a set of states and their delay successors described by a number of constraints on the clocks. In a given symbolic state, the active locations and the values of discrete variables are the same for all states.\nSymbolic traces shown in the simulator are backward stable, but not forward stable:\n**Forward stable** Given two symbolic states A and B on a symbolic trace such that A is before B, every state in A can reach a state in B. **Backward stable** Given two symbolic states A and B on a symbolic trace such that A is before B, every state in B can be reached by a state in A. In particular, care must be taken when interpreting a counter example produced by the model checker: Not every state in the symbolic states along a symbolic trace will necessarily lead to an error state, although all states in the last symbolic state are indeed reachable from the initial state.\nNote: verifyta can be used to produce forward stable traces.\n"},{"uri":"/gui-reference/verifier/","title":"Verifier","tags":[],"description":"","content":"The verifier is to check safety and liveness properties by on-the-fly exploration of the state-space of a system in terms of symbolic states represented by constraints. The verification tool in UPPAAL also provides a requirement specification editor for specifying and documenting the system requirements.\nIn this help section we describe how to operate the verification tool, in terms of how to specify and verify requirements. The requirement specification language and the verification options are described in separate sections.\n"},{"uri":"/gui-reference/yggdrasil/","title":"Test Cases (Yggdrasil)","tags":[],"description":"","content":"Test Cases (Yggdrasil) tab contains an offline test-case generation tool with a purpose of increasing edge coverage. It generates traces from the model, and translates them into test cases based on test code entered into the model on edges and locations next to comments.\nThe main features of the Test Cases generator are:\nThe generated test code is backend agnostic, meaning that it is user-defined and independent of specific test execution engines. Three modes for test case generation: Test purpose mode: Generates a test case specified by a reachability query An auto-depth mode: Generates tests automatically aiming at achieving edge/location coverage Single-step mode: Generates an individual test case per uncoverd edge. Visualization of coverage Determinism Test generator expects a deadlock free and mostly deterministic model.\nDeadlocks can be checked against in the Verifier tab using A[] not deadlock query.\nThere are no checks or reinforcements made for determinism. Non-deterministic implementation requirements (behavior not controlled by a test execution harness) may yield test-cases which cannot be executed in a controlled manner. For example, test execution harness might not be able to force the implementation under test to respond in a specific way assumed by a test case if the implementation is allowed to respond in multiple ways non-deterministically. The environment assumption model (edges controlled by the test execution harness) is encouraged to be non-deterministic to facilitate a more focused and flexible control when selecting test cases.\nBasic operation The buttons Add will generate traces based on the verification options selected in the Options menu where the search order and diagnostic trace options are overridden by the corresponding drop-down list selection. Unless intimately familiar with the search algorithms of Uppaal, leave the options at their default settings.\nThe traces are added and shown in the Traces list below on the left. Selecting a trace will show the statistics for this trace in the Trace statistics on the right. The Total Coverage button will show the combined statistics of all the traces added so far. Double clicking a trace loads the trace in the Simulator tab, where the execution scenario can be examined in detail. Simulator colors the covered locations and edges in blue when Mark Visited option is selected under the View menu.\nTest cases are exported to a specified directory specified by clicking Save Test Cases button at the bottom. Previously stored test cases are overwritten by new test ones.\nNote: the traces and statistics are lost when the model is reloaded. Traces and statistics are not saved with the model. Only the test cases can be saved.\nSuggested methodology: Test Cases can be generated in several ways, depending on the actual project, but it is designed to support the method outlined below:\nTest purposes very often represent mandatory critical observations that must be observed on the system under test. First, Add the test cases representing the test purposes. These test are mandated anyway, and will cover some parts of the model, but this coverage is typically insufficient. Generate tests that improves the (edge/location) coverage of the model (but does not guarantee so). Second, Add the test cases using the auto-depth mode to improve the coverage. The coverage achieved by the second step can be completed by adding an individual test-case for each of these uncovered edges or locations. Hence, third, Add the test cases using the single-step mode. "},{"uri":"/gui-reference/yggdrasil/tutorial/","title":"Tutorial","tags":[],"description":"","content":"This tutorial shows how to use the Uppaal Test Generator (Yggdrasil) to generate test scripts step-by-step. It assumes that you are familar with the basic syntax and semantics of Uppaal automata, the basic query language, and is able to use the model-editor.\nAt the end of the tutorial you will be able to generate simple executable test cases.\nThe features for generating offline test cases are presented terms of two simple example systems: An On/Off system and an Up/Down counter. The behavior of these systems are generic, but could, respectively, represent a lamp with on/off capabilities and a dimmer lamp, which can be turned up or down.\nBoth examples include a model, decorated with test-code, a (supposedly) correct implementation of the system, and a implementation mutant representing an implementation mistake. The system and mutant are implemented in Java so they should be platform independent. The generated test cases are output in Java and is, when compiled, executable on these implementations. Execution scripts are included for Windows and Linux.\nThe necessary files are provided as part of the Uppaal distribution in the directory demo/testcases/.\nThe tutorial proceeds in three steps:\nBasic Test Cases Generation. Here you will learn the basic steps involved in annotating the model with test code, and generating simple test cases. Test cases with model-variables. Here you will learn how to insert the values of model variables into the test code, and how to generate a covering test suite. Generating testcases using queries (test purposes). Here you will learn to generate test cases based on test purpose queries. The concepts of Test Cases generation is explained in the Test Cases section.\nFor comments or questions please contact Brian Nielsen bnielsen@cs.aau.dk or Marius Mikucionis marius@cs.aau.dk.\n"},{"uri":"/","title":"","tags":[],"description":"","content":"UPPAAL Help UPPAAL is a tool for modeling, validation and verification of real-time systems. It is appropriate for systems that can be modeled as a collection of non-deterministic processes with finite control structure and real-valued clocks (i.e. timed automata), communicating through channels and (or) shared data structures. Typical application areas include real-time controllers, communication protocols, and other systems in which timing aspects are critical.\nThe UPPAAL tool consists of three main parts:\na graphical user interface (GUI), a verification server, and a command line tool. The GUI is used for modelling, symbolic simulation, concrete simulation, and verification. For both simulation and verification, the GUI uses the verification server. In simulation, the server is used to compute successor states. See also the section on setting up a remote server. The command line tool is a stand-alone verifier, appropriate for e.g. batch verifications.\nMore information can be found at the UPPAAL web site: http://www.uppaal.org.\n"},{"uri":"/preview-build/","title":"","tags":[],"description":"","content":"Preview Build UPPAAL 5.0.0 beta2 since UPPAAL 5.0.0 beta1 Fixed symbolic trace as concrete trace output to pass the regression suite by Fix version check serialization issue on startup Fix issue where fatal engine errors are lost when parsing BasicResponse Fixed version date parsing to be more robust Updated JetBrainMono fonts Added bold italic highlighting for /// comments Update old dtd version to fit model files UPPAAL 5.0.0 beta1 since UPPAAL 4.1.20 Stratego 11 Graceful cancellation and other result output fixes Cleanup demo examples Fix ant release date and applied format validation to release dates Fix issue where plots would seemingly go backwards in time Swap result and query Fixed font and drawing anti-aliasing in the verification dialog Removed splashscreen as startup seems to be fast enough Fix issue where the last delay transition of a concrete witness trace would be omitted Fixed issues with advanced line break Recover concrete trace output on verifyta Add parsing for saving plot settings in concrete simulator "},{"uri":"/categories/","title":"Categories","tags":[],"description":"","content":""},{"uri":"/extensions/cora/","title":"CORA","tags":[],"description":"","content":"Language Guide UPPAAL CORA is based on the newest internal development version of UPPAAL. On one hand this means that it contains all the new and exciting features of the next version of UPPAAL, but on the other it also means that it contains many new and untried features, that might change before the final release of UPPAAL. This page describes the new language features compared to the UPPAAL 4.0 series.\nCost Annotation In LPTA, an implicit continuous monotonic variable called cost is defined. The rate at which this variable grows can be specified in the location invariant as:\ncost\u0026rsquo; == INTEXPR\nwhere INTEXPR is an integer expression. If specified in multible locations, the actual cost rate is the sum of the cost rate specified in the current location of each process. The cost can be incremented on edges using the increment operator +=.\nHere is an example of the aircraft landing problem: xta, q.\nRemaining Cost Estimation The performance of UPPAAL CORA can be improved dramatically by annotating the model with an admissible estimate of the remaining cost to reach the goal condition. Admissible means that the estimate is not bigger than the actual cost of reaching the goal, i.e., the estimate provides a lower bound on the remaining cost. The estimate is specified by declaring a meta integer variable named remaining. Specifying a good value for remaining is crucial for good performance.\nIn previous versions of UPPAAL, remaining had to be a lower bound on the remaining cost from the state and all its delay successors, but this is no longer required. Now remaining must simply be a lower bound on the remaining cost. When computing a successor, UPPAAL automatically adjusts the value of remaining. Thus even when you do not recompute remaining, it will still be a lower bound of the remaining cost. You will probably be able to come up with a better lower bound on the remaining cost, so you should try compute a remaining cost yourself on each edge transition.\nCommand Line Options Below we describe the new options supported by the command line interface of UPPAAL (verifyta). Most of these options are also available from the options menu in the graphical frontend.\nGuiding A number of different search orders are supported. These can be selected with the -o option:\n-o0 Breadth first. -o1 Depth first. -o2 Random depth first. -o3 Smallest heur first. -o4 Best first. -o5 Best depth first. The first two are well known from previous releases of UPPAAL. Random depth first search is similar to depth first search, but it randomises the order in which the successors of a state are searched. Smallest heur first requires the presence of an integer variable named heur in the model. The state with the smallest value of this variable is always explored next. In most cases, this variable should be a meta variable. Best first and best depth first are used for optimal reachability, see the next topic.\nOptimal Reachability UPPAAL CORA has support for finding optimal schedules. Optimality is defined in terms of a cost variable, see the Language Guide for details. The optimal trace can be found by using the -t3 option. With this option, UPPAAL CORA keeps searching until a trace to a goal state with the smallest value for the cost variable has been found. Alternatively you can use the -E option to find the optimal cost without generating the trace.\nUPPAAL CORA automatically enables the -o4 option (best first) when using the -t3 option. This can be changed by manually using a different -o option after the -t3 option. In the best first search order, the state with the smallest value of the cost variable is searched next. An alternative is to use best depth first. This search order performs a depth first search, but always searches the state with the lowest cost first. If a remaining cost estimate annotation is provided, the interpretation of the best first and best depth first is changed to search the state with the smallest sum of the cost variable and the remaining variable next.\nExamples The jugs example has been updated to the new syntax. You can download it here: jugs2.ta, jugs2.q. You can find the optimal solution like this:\nverifyta -E jugs2.ta jugs2.q\nLimitations UPPAAL CORA has a number of limitations. These limitations are not fundamental, but are a result of using new internal data structures with a currently limited feature set. Over time, these limitations will be resolved.\nNo extrapolation, hence termination is not guaranteed unless you guarantee that either: The system is acyclic. All clocks are bound by invariants. Simple reachability only: No liveness check No deadlock check Limited use of guiding: Support for (cost + remaining) sorting is implemented (best first search) Support for heuristic variable is implemented, but the expression cannot refer to the cost variable. "},{"uri":"/extensions/ecdar/","title":"ECDAR","tags":[],"description":"","content":"Language To define timed I/O automata, timed game automata of TIGA with the following constraints are used:\nInvariants may not be strict. Inputs must use controllable edges. Outputs must use uncontrollable edges. All channels must be declared broadcast. The system is implicitly input enabled due to broadcast communication but for refinement checking purposes, the relevant inputs must be explicit in the model. In the case of parallel composition of several components, a given output must be exclusive to one component. For implementations, outputs must be urgent. For implementations, every state must have independent time progress, i.e., progress must be ensured by either an output or infinite delay. Tau transitions (no output or input) are forbidden. Global variables are forbidden. The grammar for specifying property is given by:\nProperty := \u0026#39;consistency:\u0026#39; System | \u0026#39;refinement:\u0026#39; System \u0026#39;\u0026lt;=\u0026#39; System | \u0026#39;specification:\u0026#39; System | \u0026#39;implementation:\u0026#39; System System := ID | \u0026#39;(\u0026#39; System Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Composition Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Conjunction Expr \u0026#39;)\u0026#39; | \u0026#39;(\u0026#39; Quotient Expr \u0026#39;)\u0026#39; Composition := System \u0026#39;||\u0026#39; System | Composition \u0026#39;||\u0026#39; System Conjunction := System \u0026#39;\u0026amp;\u0026amp;\u0026#39; System | Conjunction \u0026#39;\u0026amp;\u0026amp;\u0026#39; System Quotient := System \u0026#39;\\\u0026#39; System Expr := /* nothing */ | \u0026#39;:\u0026#39; tctl In particular the grammar can generate expressions of the type refinement: (A || B) \u0026lt;= (C : A[] not C.unsafe). As a reminder the tctl formulas supported are\nA[ p U q ]\nFor all path p must be satisfied until q with the twist (due to the game setting) that p must still hold when q holds. A\u0026lt;\u0026gt; q\nEquivalent to A[ true U q ]. A[ p W q ]\nThe weak until variant. A[] p\nEquivalent to A[ p W false ]. A[] (p \u0026amp;\u0026amp; A\u0026lt;\u0026gt; q)\nThis is the Büchi objective formula with safety. for all path p must always hold and q must always be reachable from all states. A[] A\u0026lt;\u0026gt; q\nEquivalent to A[] (true \u0026amp;\u0026amp; A\u0026lt;\u0026gt; q). The formulas involving a Büchi objective can be used to constrain the behaviours to be non-zeno by adding an observer automata that visits a state when time elapses.\u0026lt;/e\u0026lt;=i)\u0026gt;\nKnown Issues When checking for refinement, inputs that are part of the alphabet of the processes must be put explicitly in the model for all locations of that process. The graphical simulator determinizes the strategy and limits the game even though the underlying strategy is more permissive. When a sub-formula is inconsistent there is no strategy. If you want a strategy you need to ask for a consistency check on that sub-formula. If you use the quotient, you must add two locations to the processes, one Universal and one Inconsistent. The universal one must accept all inputs of that process and generate all outputs. This must match the signature of the component. The inconsistent location must be urgent without any transition at all. It is not possible to simulate the quotient in the simulator. This is a limitation inherent to the problem because this operator generates new states and transitions that do not have references in the original model, thus the graphical simulator will be lost. We suspect that it is possible to write models that may fool ECDAR by giving wrong answers. This may happen due to some issues with extrapolation. Please deactivate extrapolations and make sure that your model is bounded if you experience this. "},{"uri":"/tags/","title":"Tags","tags":[],"description":"","content":""},{"uri":"/extensions/tiga/","title":"UPPAAL Tiga","tags":[],"description":"","content":"Manual The manual (updated 9/8/07) is available separately from the distribution. You can access it from here.\nKnown Issues Extrapolation option -n 4. This option should not be used, it would give wrong results. It is possible to get the GUI choose randomly wrong points w.r.t. the strategy occasionally. The generated C-code makes sense only for models with winning non-cooperative strategies. "},{"uri":"/extensions/tron/","title":"UPPAAL TRON","tags":[],"description":"","content":"Requirements TRON requires Unix environment and GNU C++ compiler (g++) or Microsoft Visual Studio or Sun Java 1.5 for creating custom adapters. It has been built on Debian GNU/Linux SID (unstable) and also for Windows in Cygwin environment using g++ from MingGW so it\u0026rsquo;s very likely to work with C-library adapters built there. There\u0026rsquo;s a small example C-library adapter built by Microsoft compiler, however currently it is only useful to connect to real IUTs in real-time, the virtual-time framework won\u0026rsquo;t work in Windows, unless through TCP/IP socket adapter. Here is the dependency list with Debian package names in parenthesis:\nJava 2 Standard Development Kit 1.5 (AKA J2SDK 5.0) from http://java.sun.com/. Used by: TRON Tracer GUI, smart-lamp. Earlier Java versions won\u0026rsquo;t work. Dot/Graphviz (graphviz) from http://www.graphviz.org/. Used by: TRON Tracer GUI. R (r-base) from http://www.r-project.org/. Used by: latency. GhostView (gv) from http://wwwthep.physik.uni-mainz.de/~plass/gv/. Used by: latency. Install them all on Debian: apt-get install g++ libstdc++6 graphviz r-base gv\nStatus of the Project Now Uppaal TRON version 1.4 Beta 1 is available. The tool is still in early development and experimental phase, but now anyone can checkout and taste the early fruits on his/her own. The current version is based on the latest Uppaal 4.1. Current availability and limitations:\nSystem specification accepted in Uppaal xta and xml format. The interface is specified separately in adapter library code. Supported main Uppaal features: clocks, data variables, paired channel synchronizations, urgent locations. The use of arrays, broadcast channel, and committed locations are experimental and not tested. Input and output actions through channel handshake synchronization (no buffering or value passing). User supplied adapter loading via dynamic library interface. Adapter development framework (C++), interfaces are not completely stabilized yet. Examples of tool applications against C++ programs as IUT. Use Uppaal to create and edit models. TRON Tracer GUI demonstrates the main concepts: system model partitioning, interactive traces in testing, system emulation and monitoring. Graphical user interface is mounted on generic trace-interpreter-adapter (special IUT adapter library) and serves as generic example of how to connect/link to TRON. Stripped binary executable form of Uppaal TRON. No source code provided due to licensing restrictions. Binary is dynamically linked in order to provide efficient connectivity with user-supplied adapter. The tool is prepared on the following platforms: Windows 2000 Professional, GNU Compiler Collection 3.4.5 Linux 2.6.18 on Intel PC, GNU Compiler Collection 4.1.2\nLatest builds for Sun Solaris could also be provided upon request. It is important that the machine architecture should match and GCC-2 should not be mixed with GCC-3. The same holds for GCC-4. Please report your experiences. User Manual You may want to read an early draft of user-manual (still under development, comments are welcome).\nTesting Runtime Command Line Options TRON binary is based on verifyta utility from Uppaal, hence there are a few options available to tune the Uppaal engine too. I will explain only TRON specific ones and some of verifyta that might effect testing. The following is printed on screen when TRON is run in command line:\n./tron -h Usage: tron [options] -I adapter model.xml [-- parameters to adapter] Options: -A Use convex-hull approximation. [-D filename](#D) specify a file for driver log (default /dev/null). [-F future](#F) The amount of future in mtu to be precomputed (default 0), To disable precomputation set it to -1 (not recommended). [-H n](#H) Set the hash table size for bit state hashing to 2**n (default = 27) [-I filename](#I) dynamic C-library with adapter to an implementation, or: TraceAdapter -- interact via textual stdin/stdout; SocketAdapter -- remote TCP/IP socket adapter. [-P delay](#P) short,long: try random delay from one of intervals (mtu), eager: delay as little as possible for chosen transition, lazy: delay as much as possible for chosen transition, random: delay within bounds specified by model (default). [-Q log](#Q) use logical (simulated) clock instead of host clock. or specify port number for simulated clock: -Q 6521 [-S filename](#S) Append the verdict, I/O and duration to file (default /dev/null) -U Unpack reduced constraint systems before relation test. -V Print version information and exit. [-X integer](#X) Value to initialize random number generator (default time) -h Print this message. [-i ](#i) Print a signal flow diagram of the system and exit: dot: outputs dot graph, expects formated standard input: \"input\" (channel)* \"output\" (channel)* gui: non-partitioned flow information for TRON GUI; [-o filename](#o) Redirect output to file instead of stdout, see also -v -s \u003c0|1|2\u003e Select search order. 0: Breadth first (default) 1: Depth first 2: Random depth first [-u inpDelay,inpRes,outDelay,outRes](#u) -u inpRes,outRes Observation uncertainty intervals in microseconds: inpDelay: the least delay that takes to deliver input, inpRes: possible additional delay for delivering input, outDelay: the least delay that takes to observe output, outRes: possible additional delay for observing output. [-v \u003c0+1+2+4+8+16\u003e](#v) Specify verbosity of the output. For -o test logging verbosity bit-flags: = 0: only verdict, disable trace output (default), \u0026 1: progress indicator for interactive experiments, \u0026 2: test events applied in the UPPAAL engine, \u0026 4: available input and delay choices for simulation, \u0026 8: backup state set and prepare for final diagnostics, \u002616: dumps current state set on each update. [For -i partitioning: 0-none, 1-errors, 2-warnings, 3-diagnostics](#iv). [-w integer](#w) Specify additional number of time units to attempt to violate invariants. Works under assumption that invariants are not used in Environment. -q Do not display the copyright message. Environment variables: UPPAAL_DISABLE_SWEEPLINE disable sweepline method UPPAAL_DISABLE_OPTIMISER disable peephole optimiser UPPAAL_OLD_SYNTAX use version 3.4 syntax The value of these variables does not matter. Defining them is enough to activate the feature in question. Here is a more detailed description of testing specific options:\n-I filename specifies the adapter to connect to IUT. It is either the name of a built-in adapter (such as TraceAdapter and SocketAdapter) or the filename of dynamically loaded C-library. See Building Test Adapter on how to make one.\n-D filename specifies where the output of the Driver (component that time-stamps input and output events) should be redirected to. The EBNF of the output is the following:\nDriverLog ::= ( line **EOL** )* line ::= timestamp | event timestamp ::= **\"delay\"** integer event ::= channelname **\"(\"** paramlist **\")\"** paramlist ::= | integer ( **\",\"** integer )* The timestamp line means that the system has delayed until the specified absolute time moment in microseconds counting from the beginning of testing. The event line means an input or an output event observation at the last delay timestamp in the driver. The specific input or output nature is specified by channel name and the bounded variable integer values.\n-S filename specifies where the verdict information should be saved (usually used for gathering Statistics of many TRON runs). If specified, each line of the file will consist of five elements: 1) integer for random seed used (see -X) 2) verdict 3) number of inputs 4) number of outputs 5) time used in model time units.\n-v \u0026lt;0+1+2+4+8+16\u0026gt; specifies what testing information should be visible on the output by bit-flags:\n1 progress indicator, useful in interactive command-line when no other testing information is specified; 2 events applied in Uppaal engine (mainly for debugging); 4 choices considered when emulating the environment; 8 makes a copy of the current state set before applying delay and output events, this enables some diagnostic information when test verdict is failed or inconclusive but also costs a bit of additional memory; 16 shows the current reachable state set before each update.The numbers above should be added and final integer result used in -v option. For example, for progress indicator (1) and diagnostic information (8) one should use -v 9 as 1+8=9. -o filename redirects the testing information (specified by -v) to the file rather than standard output stream.\n-H n specifies the size of hash table in Uppaal engine for detecting loops in passed list states (as in verifyta), the size in testing can be much smaller as the TRON considers only the current reachable state set which is much smaller than the whole state space of the system (as in verification process);\n-F future specifies the future input event horizon for environment emulation in model time units, the further horizon the more TRON should pre-compute into the future when choosing input event; the value should be as large as possible for richer input choices but small enough for TRON to be able to compute respond within 1 model time unit; the default is 1 model time unit (disabling it with 0 is not recommended);\n-P delay constrains the choice of delay by the following heuristics:\nrandom the choice is based on available delays in the model and concrete delay is chosen by pseudo-random number generator; if delays are not bounded by invariant TRON may choose very large delays and hence appear idle for very long time; lazy the choice is based on available delays in the model and concrete delay is taken by choosing the longest possible; TRON may delay for very long if constraints (invariants) allow it; eager the choice is based on available delays in the model and concrete delay is taken by choosing the shortest delay possible; short,long are integers and specify the longest delay choice for short and long delay. The concrete delay is then chosen randomly based on the model and longest possible delay. The choice of a short or a long delay is random; -w integer prolongs the model delay by specified number of model time units possibly breaking the invariants in the model; it was created as a workaround for proper IUT and environment invariant separation to be able to test the IUT invariants under assumption that the environment model did not contain any invariants; today correct partitioning (see Test Interface Specification) of the system model is recommended instead of this option;\n-u inpDelay,inpRes,outDelay,outRes see Observation Uncertainties for explanation.\n-Q log specifies that virtual time framework should be used rather than host machine\u0026rsquo;s clock, string log can also be replaced by an integer meaning the port number for external virtual clock users, see Virtual Time for more details;\n-X integer specifies the value of random seed for the random number generator which drives the environment emulation choices; it could be useful to attempt to replicate an identical test run although it is very hard to ensure the same flow of time and event interleaving;\n-i \u0026lt;dot|gui\u0026gt; generates the signal flow of the system model in graphviz format; when specified, TRON expects the input/output interface to be fed into standard input stream in the following EBNF format:\nTIS ::= inputs outputs precision timeout inputs ::= **\"input\"** channels **\";\"** outputs ::= **\"output\"** channels **\";\"** precision ::= **\"precision\"** integer **\";\"** timeout ::= **\"timeout\"** integer **\";\"** channels ::= | channel ( **\",\"** channel )* **\";\"** channel ::= channelname **\"(\"** variables **\")\"** variables ::= | variablename ( **\",\"** variablename)* See also Test Interface Specification. When -i is specified, -v option has a different special meaning:\n-v \u0026lt;0|1|2|3\u0026gt; specifies what information is produced in partitioning (-i) mode: 0 \u0026ndash; silent, no errors are shown, 1 - only errors are shown, 2 - warnings are shown, 3 - errors, warnings and rules being applied are shown. See also Test Interface Specification.\nInterpreting Messages Here is the beginning of output from smart lamp demo:\n1. UPPAAL TRON 1.4 Beta 2 using UPPAAL 4.1.0 (rev. 2765), October 2006 2. Compiled with g++-4.1.2 -Wall -DNDEBUG -O2 -DBOOST_DISABLE_THREADS 3. Copyright (c) 1995 - 2006, Uppsala University and Aalborg University. 4. All rights reserved. 5. Options for the UPPAAL engine: 6. Search order is breadth first 7. Using no space optimisation 8. State space representation uses minimal constraint systems 9. Observation uncertainties: 0, 0, 0, 0 (microseconds). 10. Future precomputation: closure(300 mtu). 11. Input delay extended by: 0 12. OS scheduler: non-real-time. 13. socket connect: Connection refused 14. (* 9 tries left *) 15. Environment processes: user. 16. Timeunit: 10000us 17. Timeout: 1000000mtu 18. Inputs: grasp(), release() 19. Outputs: level(adapLevel) Lines 1-2 specify the version and the build environment of TRON binary, might be important when building the C-library adapter. Lines 3-4 contain copyright information. Lines 5-11 show the state of Uppaal engine and TRON options. Line 12 says that TRON is using non-real-time process scheduler which is used for all virtual time runs. In real time mode TRON will attempt to gain high priority and select real-time round-robin scheduler if possible (available and enough permissions given), which would minimize the scheduling disturbances from other processes. Lines 13-14 show that TRON attempted socket connection (to IUT) but failed and it will retry doing so for 9 times with 2 second intervals. Lines 15-19 show the model partitioning and testing interface information: environment consists of just user process (user invariants will be considered when offering input), model time unit is interpreted as 10000 microseconds, and 1000000 model time units are allocated for testing.\nThe messages are typical from TRON standard output stream when bit-flag 2 is selected in -v option:\n1. TEST: delay to [245.. on 1 2. TEST: grasp()@1225896-1225940 at [245..246) on 1 3. TEST: level(0)@1771740 at [353..356) on 5 4. TEST: level(1)@2752912 at [549..552) on 3 5. TEST: level(2)@3777576 at [755..756) on 3 6. TEST: level(3)@4798399 at [959..960) on 3 7. TEST: delay to [1153.. on 3 8. TEST: delay to [1159.. on 3 9. TEST: release()@5798049-5798094 at [1159..1162) pre\u003e 10. TEST: delay to [1169.. on 13 11. TEST: delay to [1175.. on 13 Lines 20, 26-27, 29-30 mean that TRON has chosen a delay and nothing happened until it has expired, for example line 20 says that TRON is applying a delay on a current state set to the moment of 245 model time units on a single (1) state in a set, the upper bound of a delay is open and bounded only by future horizon (see -F). Line 21 says that TRON is applying the input event on channel grasp it has just executed at time interval 1225896-1225940 microseconds which is mapped to model time interval [245..246) in Uppaal constraint encoding. The encoding [245..246) means a model time interval (122,123) as 245/2=122.5 (remainder shows that the constraint is strict, i.e. \u0026gt;122, and the point 122mtu is not included) and 246/2=123 which is strict as \u0026ldquo;)\u0026rdquo; in the log. The same mapping and encoding procedure applies to outputs on lines 22-25 which show that output events on channel level have variable values attached (0, 1, 2 and 3). The output is time-stamped right after it is registered in the driver. The inputs are time-stamped with two time-stamps: just before offering an input and right after the input is offered, to reflect an over-approximation and uncertainty on when exactly it was actually delivered at (remote) IUT.\nVerdict Assignment and Diagnostics At the end of testing TRON will issue a verdict, which is either PASSED, INCONCLUSIVE or FAILED. PASSED means that the timeout for testing has expired and no faulty behavior has been detected. Test may fail with verdict FAILED if IUT exposes the behavior which could not be mapped in the model of IUT, i.e. if IUT reported wrong output at wrong time (too early or too late) or IUT did not respond at all when it was required to respond with some output. In case of INCONCLUSIVE verdict, TRON is either 1) confused with the output observed from IUT, cannot map this output to the model of environment and hence does not know how to continue testing or 2) late for delivering an input in time as required by the model of environment. The second option can be very frequent on heavily loaded machines, broken schedulers (Windows tend to issue spurious timeouts even if timeout did not expire) while testing in real time using the host machine\u0026rsquo;s clock. Also it is still not clear how to handle situations when TRON and IUT rely on different clocks which drift away from each other, hence we rely on assumption that TRON is operating on a correct (reference) clock.\nTRON can also provide additional information on why the test ended up with verdict FAILED or INCONCLUSIVE if the bit-flag 8 is specified on -v option. The following is a typical output of such diagnostic information:\n1. Short post-mortem analysis based on last good stateSet(3): 2. 1) 3. ( interface.touching switch.idle dimmer.PassiveUp user.busy graspAdapter._id26 ... ) 4. interface.x\u003e47, dimmer.x\u003e260, user.z\u003e52, graspAdapter.x\u003e52, ... 5. on=1 iutLevel=5 OL=7 adapLevel=5 user.L=5 6. 2) 7. ( interface.holding switch.idle dimmer._id10 user.busy graspAdapter._id26 ... ) 8. interface.x\u003e=50, user.z\u003e52, graspAdapter.x\u003e52, releaseAdapter.x\u003e162, ... 9. on=1 iutLevel=7 OL=7 adapLevel=5 user.L=5 10. 3) 11. ( interface.holding switch.idle dimmer.Up user.busy graspAdapter._id26 ... ) 12. interface.x\u003e=50, user.z\u003e52, graspAdapter.x\u003e52, releaseAdapter.x\u003e162, #t\u003e5937, ... 13. on=1 iutLevel=7 OL=7 adapLevel=7 user.L=5 14. Options for input : (empty) 15. Options for output : level@[11875..11894) 16. Options for internal: starthold@[11875..13770), setLevel@[11875..11890) 17. Options for delay : ..13770) 18. Last time-window : [11987..11990) 19. Could not delay any more (to the last time-window). 20. Output expected: level(7)@0-0[11875..11894) 21. TEST FAILED: IUT failed to produce output in time 22. Time elapsed: 5993 tu = 59.939325s 23. Time left: 994007 tu = 9940.060675s 24. Random seed: 1163420344 25. AdapterConnection died: socket closed upon read Line 31 says the following analysis is based only on the last good state (might be inaccurate if fault happened much earlier than observed) consisting of 3 symbolic states. Lines 32-43 enumerate the symbolic states (it can be very long, this is a shortened version of it), for example line 32 specifies the symbolic state number 1, line 33 says in which control locations the processes are, line 34 enumerates clock constraints and line 35 enumerates values of integer variables. Lines 44-47 reiterates what options TRON was facing just before test has terminated: line 44 says that there could be no inputs offered, line 45 says that according to model the output level is expected at model time interval (5937,5947) (as 11875/2=5937.5 and 11894/2=5947 in Uppaal encoding), line 46 enumerates internal transitions available in the model, line 47 specifies the longest possible delay until 6885mtu without observable input/output. Line 48 says that TRON was trying to compute the reachable symbolic state set for the interval (5993,5995), but according to line 49 it could not, as the resulting symbolic state set contained no states. Line 50 notes that there was level(7) output expected at (5937,5947) therefore the conclusion in line 51 is that IUT failed to produce output (in required time). Lines 52-53 show how long test was running and how much left to testing timeout in model time units and seconds. Line 54 shows the random seed used to start the pseudo-random number generator (see -X option). Line 55 contains spurious exception upon disposing SocketAdapter which can be safely ignored.\nAs of version 1.4 be aware of bug 369 in diagnosis.\nAdaptation In this section we are going to show the adaptation process for TRON framework. We are going to use the smart lamp light controller example to highlight the supported features and to show how to use them.\nModel Specification TRON supports abstract requirement models in a sense that implementation under test (IUT) does not necessarily have to follow the structure of the model. User should use Uppaal to specify requirements by creating a timed automata model of the whole (closed) system, i.e. the model should contain requirements for the IUT and also the assumptions about its environment (user). The processes in Uppaal timed automata network communicate via channels. Every channel synchronization is an instantaneous event in the system, taking zero time as any other transition. So the simplest closed system suitable for testing using TRON consists of at least two communicating processes: IUT process and environment process. In this simple system the input event is fired whenever environment process shouts at some channel and IUT receives the channel synchronization, the output happens in the same manner but opposite direction.\nThe model of environment can be as simple as one process containing one location with a synchronized transition loop for each input/output channel synchronization. Such environment would test the most of IUT features/requirements as it is fully permissive, however this might be too expensive and unrealistic, especially if environment assumptions can be stated more precisely, e.g. modeling some case of system usage. It is important that environment is input enabled, i.e. it is able to consume any possible output produced by IUT, otherwise TRON will issue verdict \u0026ldquo;inconclusive\u0026rdquo; in case the received output event cannot be applied to environment.\nIn a more complex system the IUT (and environment) requirements may be modelled by many processes. In this case the system is partitioned into two sets of processes: the processes modelling the requirements for IUT (model of IUT) typically mimicking what the IUT should do and the processes for the environment assumptions (model of environment) mimicking what the tester should do. The IUT (environment) processes may communicate among themselves by channel synchronizations too, but such communication is treated as internal and not observable. The channel synchronization is treated as observable input/output event if and only if it is between the environment and IUT processes.\nAs noted before, the channel synchronization is an instantaneous event in timed automata network, hence the communication between the environment and the IUT is also treated as instantaneous. However real-time black-box testing is also a kind of remote testing, where the inputs/outputs are fed at one time instance and received slightly later as there is at least small communication delay. Even the slightest delay of electronic signal running short distance at a speed of light is significant as it might imply a different input and output event interleaving and hence a different outcome. The communication delay is especially significant on soft-real-time operating systems (such as Windows and Linux) where the process scheduling is a major contributor but is hardly predictable (Linux scheduler tries hard to be at most 10ms late and 2.6 branch usually fits into 1ms delay under low load conditions, see Latency Experiments). Currently TRON time-stamps the input and output events when they arrive/leave TRON process, hence the model of IUT should also include the processes of adapter proxying and slightly delaying the actual input and output to reflect such communication reality. The model of adapter also helps to make sure that the model of IUT is input enabled, i.e. IUT cannot refuse to accept the offered input, which might be important in testing features that are triggered only by that particular input (and time). TRON will not try to offer an input if the model of IUT is not able to consume it.\nThe model of the system should be validated in the Uppaal symbolic simulator to make sure the model reflects an intended system behavior and the verifier should be used to check at least that model does not contain deadlocks (\u0026ldquo;A[] not deadlock\u0026rdquo; must be satisfied). In extreme cases where system state space is too large and cannot be verified (e.g. adapter processes involve queueing of input/output events and hence blowup the state space), a more abstract version of the model should be verified. TRON might issue verdict \u0026ldquo;inconclusive\u0026rdquo; or \u0026ldquo;failed\u0026rdquo; if it runs into deadlock situation and/or give unreliable \u0026ldquo;last good state set\u0026rdquo; diagnostic information if deadlock is present but was avoided by taking other transitions.\nExample. Consider the smart lamp demo with the following model of the system: LightContr.xml (you are encouraged to load it into Uppaal). I will use the signal flow diagram LightContr.png to demonstrate how processes in this system communicate (see Test Interface Specification to produce signal flows of your own). The legend of this signal flow diagram is as follows: ellipse means process, rectangle means integer variable, diamond means channel, arrows indicate the flow of signal, i.e. process transmit on given channel if arrow is from ellipse to diamond, process receives on given channel if arrow is from diamond to ellipse, variable is being written by process if arrow points from ellipse to rectangle and variable is being read if arrow is from rectangle to ellipse. The labels on arrows indicate the channel synchronization when variable is accessed, dash means silent (internal) access without channel synchronization. TRON uses the observable input/output channel (double diamonds) declaration (see Test Interface Specification) to partition the system into the model of environment (light green items) and the model of IUT (light blue items). In this example, environment consists of user process communicating through input channels grasp and release and output channel level. The requirements for IUT are modeled by interface, dimmer and switch processes. The communication delay is modeled by levelAdapter, releaseAdapter and graspAdapter processes.\nTest Interface Specification Test interface is a set of observable input and output channels possibly with integer variables values bound to channel. Observable input and output channels define how the system model is partitioned into the model of IUT and the model of environment. The correct system partitioning is important in order to ensure correct verdict computation by using relativized timed input/output conformance relation (which means identifying and special treatment of IUT invariants which might interact with environment model as invariants are global in Uppaal semantics). The idea of correct partitioning is a complete and consistent separation of environment model and IUT model by inspecting the following control rules:\nChannels, that are not declared as inputs/outputs, are non-observable called internal. Internal channel belongs to environment (IUT) if it is used by environment (IUT) process (respectively). Model is inconsistent and cannot be partitioned if the internal channel is used by both environment and IUT. Process belongs to environment (IUT) if it uses the internal environment (IUT) channel (respectively). Variable belongs to environment (IUT) if it is accessed by environment (IUT) process without observable input/output channel synchronization. Variable is not cathegorized (can be either) if accessed consistently only during observable input/output channel synchronization. Process belongs to environment (IUT) if accesses environment (IUT) variable (respectively) without observable channel synchronization. It might be tricky to get complete and consistent (all processes are assigned to either IUT or environment) partitioning. Currently the adapter API is the only way to specify the test interface. The easiest way to experiment with test interface and partitioning is by generating signal flow diagram of the system. The signal flow diagram in graphviz format can be obtained from TRON standard output with -i dot option on specific Uppaal model and entering the test interface information via standard input in the following tiny EBNF grammar (terminals are quoted in bold, this grammar is also used in TraceAdapter):\nTIS ::= inputs outputs precision timeout inputs ::= **\"input\"** channels **\";\"** outputs ::= **\"output\"** channels **\";\"** precision ::= **\"precision\"** integer **\";\"** timeout ::= **\"timeout\"** integer **\";\"** channels ::= | channel ( **\",\"** channel )* **\";\"** channel ::= channelname **\"(\"** variables **\")\"** variables ::= | variablename ( **\",\"** variablename )* Here, the precision specifies the duration of one model time unit (mtu) in microseconds and timeout specifies how many model time units is allocated for testing. Upon success TRON will terminate with verdict \u0026ldquo;passed\u0026rdquo; when precision × timeout microseconds elapse and no fault is found.\nExample. The following command lines produce signal flow in graphviz format which is further laid-out onto the PNG picture format by dot utility, the third line does it all in one:\ntron -i dot [LightContr.xml](LightContr.xml) \u003c [LightContr.trn](LightContr.trn) \u003e [LightContr.dot](LightContr.dot) dot -Tpng -o [LightContr.png](LightContr.png) [LightContr.dot](LightContr.dot) tron -i dot [LightContr.xml](LightContr.xml) \u003c [LightContr.trn](LightContr.trn) | dot -Tpng -o [LightContr.png](LightContr.png) Note that TRON also adds a few constraints for the graph layout in dot file, in particular it specifies landscape A4 paper, which is handy for -Teps option but might not be good for some larger models.\nIf partitioning is not complete (some process, variable or channel is assigned to neither IUT nor environment) or inconsistent (according to rules some item is assigned to both IUT and environment) then TRON will write complains and warnings to the standard error stream. The verbosity of partitioning messages is controlled by -v option: -v 0 \u0026ndash; none, -v 1 \u0026ndash; errors, -v 2 \u0026ndash; warnings, -v 3 \u0026ndash; diagnostics. The diagnostic messages will show how TRON is trying to partition the processes, variables and channels by iteratively applying the control rules. It is also recommended to check the separation in the output stream from TRON once the test interface is specified during testing.\nCurrently (as of version 1.4 Beta 2) the variable usage in C-code functions is not analyzed, hence partitioning might work incorrectly. Also observable broadcast channels should be used with caution (IUT/environment cannot send and receive at the same time on observable broadcast channel). The source code for signal flow static analysis and partitioning will probably be available in the next release of UTAP library.\nObservation Uncertainties TRON is applying observable input and output events by the following algorithm: 1) time-stamp the event with the host machine clock, 2) convert to a model time representation in floating point number form 3) find the closest integers to the given floating point number 4) apply input/output event to the model state space as if it happened between the closest integers time points. Observation uncertainty is a tweak for such time-stamping scheme, which expands and shifts the time-stamping interval: the output event is expanded to the direction of past (as if it happened earlier than observed), the input event is expanded to the direction of future (as if it will happen later than it is actually sent). The observation uncertainty was an early idea to reduce state space explosion due to adapter models and still be able to handle the communication and scheduling latency.\nThe observation time uncertainty can be specified by -u option, see the output of tron -h. The parameters inpDelay and outDelay control how many microseconds the event time window is shifted and parameters inpRes and outRes specify how many microseconds the window is be expanded, which potentially might touch or cover a next time unit(s). Current implementation (1.4 Beta 2) does not treat the time-stamp shifts correctly as it is required to create a hole in a state space between possible outputs in the past and possible inputs, hence requires a more complicated state exploration algorithm. Values other than 0 for inpDelay and outDelay are not recommended. The values for inpRes and outRes should reflect the scheduling and communication latency, e.g. allow about 3000-4000 microseconds on Linux-2.6 (may vary on different machines).\nObservation uncertainty is relevant only in testing in real world time and is irrelevant in virtual time.\nBuilding Test Adapter Normally, when TRON process is launched for testing the following happens:\nTRON parses and sets the command line options TRON looks for Uppaal timed automata model and loads it. TRON looks for adapter specified and attempts to create it via constructor call by passing a reporter object handle. Adapter constructor establishes connection to IUT (possibly launching another IUT process/thread, or simply connecting to remote IUT process). Adapter constructor configures the testing interface by declaring observable input/output channels, binding needed variables, sets the precision and the timeout for testing and returns the adapter handle to TRON. TRON statically analyzes the model and partitions the system into IUT and environment. TRON calls adapter.start() routine to indicate that no problems were found, adapter should finish any initializations and testing begins from the moment thread returns to TRON. Further input and output communication is asynchronous in a sense that IUT should use its own thread to report outputs to the reporter (which in turn will time-stamp and queue it) and TRON will call the method to register input (IUT is expected to add input to its input queue, notify its thread and return as soon as possible). Caution: adapter interface may deadlock if the same input-offering-thread (from TRON) is used by adapter to report the output from IUT. It is also important to release the lock on input queue (if any) in IUT adapter when reporting outputs to allow TRON to offer input while the output is being reported. After test is finished (via timeout or failure), TRON calls the adapter destructor to disconnect from IUT, cleanup and release all the resources. Currently there are a few different adapter examples available as reference implementations, depending on platform and adapter method the actual action names may differ:\nTextual communication via standard I/O adapter (virtual time recommended). See source code using TraceAdapter in tracer directory under GNU environment (requires bash, GNU make, use Cygwin if on Windows). TraceAdapter uses the ANTLR lexer and parser to read the standard input stream (see how \u0026ldquo;make testsuite\u0026rdquo; example works for example traces accepted by TraceAdapter, it\u0026rsquo;s even possible for human to interact with TRON). TCP/IP socket adapter for remote IUTs (both: virtual and real time). See Java source code of smart-lamp using SocketAdapter in java directory, java-doc. Remote adapter implementation in C/C++ can also be provided upon a request. Microsoft Visual C library adapter example (currently only real time). See source code of mouse button example in MSVC directory. GNU C library adapter example on Unix (both: virtual and real time). See source code of mouse button example in button directory. Virtual Time Much of real-time control software concerns mainly correct timing and functional behavior and time spent on computation is negligible or predictable. TRON\u0026rsquo;s virtual time framework offers a possibility to test a real-time application in laboratory conditions where time flow is controlled, i.e. time is allowed to flow when all processes are explicitly waiting and is stopped when at least process is busy computing. Virtual time framework has an advantage that otherwise inherent latencies (OS scheduling, communication) are removed.\nThe idea is based on a concept of monitor, where mutex locking and unlocking wrap a negligible amount of atomic computations and temporary mutex release by waiting on conditional variable reflects the process\u0026rsquo; intent to delay and wait for a specific condition.\nBy default TRON assumes host machine\u0026rsquo;s real time clock and virtual time clock can be turned on by option -Q log which also opens a server socket on port 6521 to serve any remote request for virtual clock. User can also change the port number to 1234 by using option -Q 1234 instead, just make sure that remote IUT will also use the same port number. Reference Java client implementation of remote virtual time clock can be found in java/tron/VirtualThread.java file.\nPOSIX C Example POSIX (Portable Operating System Interface for uniX) way of creating a monitors is by using pthread_mutex_lock, pthread_mutex_unlock, pthread_cond_wait and pthread_cond_timedwait functions (see their manual pages e.g. on your Linux distribution). TRON binary (on Linux) exports the following substitute functions which call the OS\u0026rsquo;s POSIX layer when testing in real time and uses virtual TRON\u0026rsquo;s clock when testing in virtual time:\ntron_thread_create instead of pthread_create tron_mutex_init instead of pthread_mutex_init tron_mutex_destroy instead of pthread_mutex_destroy tron_mutex_lock instead of pthread_mutex_lock tron_mutex_unlock instead of pthread_mutex_unlock tron_cond_init instead of pthread_cond_init tron_cond_destroy instead of pthread_cond_destroy tron_cond_wait instead of pthread_cond_wait tron_cond_timedwait instead of pthread_cond_timedwait tron_cond_signal instead of pthread_cond_signal tron_cond_broadcast instead of pthread_cond_broadcast tron_gettime instead of gettimeofday There are also functions to temporarily remove the current running thread from virtual time accounting and put it back to the pool of virtual time threads: tron_thread_deactivate and tron_thread_activate. These functions are not normally used, and exist only to simplify design of remote adapters like SocketAdapter.\nJava Example Example in java directory provides tron.VirtualLock class for controlling the state of (potentially remote) lock and creating tron.VirtualCondition variables. TRON\u0026rsquo;s monitor paradigm is very similar to Java\u0026rsquo;s synchronized methods, except that all participating threads should be created via tron.VirtualThread object, locking, unlocking, waits and notifications (signals) should be done explicitly on corresponding VirtualLock and VirtualCondition objects. See java-doc for more.\n"}] \ No newline at end of file diff --git a/language-reference/expressions/identifiers/index.html b/language-reference/expressions/identifiers/index.html index 1765af83..042627a0 100644 --- a/language-reference/expressions/identifiers/index.html +++ b/language-reference/expressions/identifiers/index.html @@ -1,7 +1,7 @@ Identifiers :: UPPAAL Documentation -

    Identifiers

    The valid identifier names are described by the following regular expression: [a-zA-Z_]([a-zA-Z0-9_])*

    Examples

    • a, B, c2, d2 valid identifier names.
    • 1, 2a, 3B, 4c5 invalid identifier names.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/expressions/index.html b/language-reference/expressions/index.html index 6d51e836..50ab52b4 100644 --- a/language-reference/expressions/index.html +++ b/language-reference/expressions/index.html @@ -1,7 +1,7 @@ Expressions :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/index.html b/language-reference/index.html index 45b691dc..4b3fef85 100644 --- a/language-reference/index.html +++ b/language-reference/index.html @@ -1,8 +1,8 @@ Language Reference :: UPPAAL Documentation -

    Chapter 2

    UPPAAL Language Reference

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-semantics/index.html b/language-reference/query-semantics/index.html index 726c1afa..f33248b9 100644 --- a/language-reference/query-semantics/index.html +++ b/language-reference/query-semantics/index.html @@ -1,10 +1,10 @@ Query Semantics :: UPPAAL Documentation -

    Query Semantics

    Semantics of requirement specification language used in the verifier of UPPAAL.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-semantics/smc_queries/ci_estimation/index.html b/language-reference/query-semantics/smc_queries/ci_estimation/index.html index ea7a5138..c3803f8d 100644 --- a/language-reference/query-semantics/smc_queries/ci_estimation/index.html +++ b/language-reference/query-semantics/smc_queries/ci_estimation/index.html @@ -1,7 +1,7 @@ Confidence Intervals :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-semantics/smc_queries/index.html b/language-reference/query-semantics/smc_queries/index.html index 8eeb022e..c5900388 100644 --- a/language-reference/query-semantics/smc_queries/index.html +++ b/language-reference/query-semantics/smc_queries/index.html @@ -1,7 +1,7 @@ Semantics of the Statistical Queries :: UPPAAL Documentation -
    BExpr
    describes a Boolean expression over clocks, variables, and locations.

    See rail road diagram of entire MITLExpression syntax:

    The exact evaluation of the probability that a run satisfies a given weighted MITL formula.

    Examples

    Pr[<=100] (<> Train.Cross)
    estimates the probability of the process Train reaching the location Cross within 100 model time units. The tool will produce a number of histograms over model time, like probability density distribution of Train.Cross becoming true over model time, thus allowing to inspect what the most likely moment in time is when the train arrives at crossing.
    Pr[cost<=1000] (<> Plane.Landing)
    estimates the probability of the process Plane reaching the location Landing within 1000 cost units where clock variable cost has various rates in different locations. The tool will produce a number of histograms over the cost values, like a probability density distribution of Plane.Landing becoming true over cost, thus allowing to inspect what the most likely cost is when the plane lands.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-semantics/symb_queries/index.html b/language-reference/query-semantics/symb_queries/index.html index e4990845..d96ae32a 100644 --- a/language-reference/query-semantics/symb_queries/index.html +++ b/language-reference/query-semantics/symb_queries/index.html @@ -1,10 +1,10 @@ Semantics of the Symbolic Queries :: UPPAAL Documentation -

    Semantics of the Symbolic Queries

    In the following we give a pseudo-formal semantics for the requirement specification language of UPPAAL. We assume the existence of a timed transition system (S, s0, →) as defined in the semantics of UPPAAL timed automata. In the following, p and q are state properties for which we define the following temporal properties:

    See also Syntax of Symbolic Queries.

    Possibly

    The property E<> p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → … → sn, where s0 is the initial state and sn satisfies p.

    Invariantly

    The property A[] p evaluates to true if (and only if) every reachable state satisfy p.

    An invariantly property A[] p can be expressed as the possibly property not E<> not p.

    Potentially always

    The property E[] p evaluates to true for a timed transition system if and only if there is a sequence of delay and action transitions s0 → s1 → … → si → … for which p holds in all states si and which either:

    • is infinite, or
    • ends in a state (Ln, vn) such that either
      • for all d: (Ln, vn+d) satisfies p and Inv(Ln), or
      • there is no outgoing transition from (Ln, vn)

    Eventually

    The property A<> p evaluates to true if (and only if) all possible transition sequences eventually reaches a state satisfying p.

    An eventually property A<> p can be expressed as the potentially property not E[] not p.

    Leads To

    The syntax p --> q denotes a leads to property meaning that whenever p holds eventually q will hold as well. Since UPPAAL uses timed automata as the input model, this has to be interpreted not only over action transitions but also over delay transitions.

    A leads to property p --> q can be expressed as the property A[] (p imply A<> q).

    State Properties

    Any side-effect free expression is a valid state property. In addition it is possible to test whether a process is in a particular location and whether a state is a deadlock. State proprerties are evaluated for the initial state and after each transition. This means for example that a property A[] i != 1 might be satisfied even if the value of i becomes 1 momentarily during the evaluation of initializers or update-expressions on edges.

    Locations

    Expressions on the form P.ℓ, where P is a process and ℓ is a location, evaluate to true in a state (L, v) if and only if P.ℓ is in L.

    Deadlocks

    The state property deadlock evaluates to true for a state (L, v) if and only if for all d ≥ 0 there is no action successor of (L, v + d).

    Property Equivalences

    The UPPAAL requirement specification language supports five types of properties, which can be reduced to two types as illustrated by the following table.

    NamePropertyEquivalent to
    PossiblyE<> p
    InvariantlyA[] pnot E<> not p
    Potentially alwaysE[] p
    EventuallyA<> pnot E[] not p
    Leads top --> qA[] (p imply A<> q)
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/controller_synthesis/index.html b/language-reference/query-syntax/controller_synthesis/index.html index 70919b04..2d8358b8 100644 --- a/language-reference/query-syntax/controller_synthesis/index.html +++ b/language-reference/query-syntax/controller_synthesis/index.html @@ -1,7 +1,7 @@ Syntax of Controller Synthesis :: UPPAAL Documentation -
    GameTimeLimitExpression
    describes a time limit within the game must be won. This expression is only evaluated once at the beginning, thus should not depend on the current state.
    LocalGameTimeLimitExpression
    describes an additional time limit such that the game can be won within GameTimeLimitExpression - LocalGameTimeLimitExpression time units. This expression is evaluated in each state, and can therefore depend on state or clock constraints. Must be side-effect free.

    See rail road diagram for the entire ControlQuery syntax.

    Examples

    control: E<> goal
    compute a strategy where goal state predicate is eventually true no matter what the oponent/environment chooses to do. The resulting strategy is deterministic in a sense that for a given state the strategy proposes one action for the player/controller (while the oponent/environment may still choose from multiple actions).
    control: A[] safe
    compute a strategy where safe state predicate is always true no matter what the opponent/environment chooses to do. The strategy is permissive in a sense that for a given state the strategy may propose multiple actions for the player/controller. Such permissive strategy can be thought of as a union of all strategies satisfying the predicate, therefore it does not have any notion of progress and may include infinite loops.
    A[ safe U goal ]
    computes a safety strategy but only up until the goal is reached.
    A[ safe W goal ]
    (weakly until the goal) either a safety strategy is found or a safety strategy holds until the goal is reached.

    See also Strategy Queries below on how to store and query the properties of the computed strategies.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/index.html b/language-reference/query-syntax/index.html index 8eb09c42..9e09095e 100644 --- a/language-reference/query-syntax/index.html +++ b/language-reference/query-syntax/index.html @@ -1,10 +1,10 @@ Query Syntax :: UPPAAL Documentation -

    Query Syntax

    This section describes a BNF-grammar for the requirement specification language used in the verifier of UPPAAL.

    See also rail road diagram for the entire Query syntax.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/learning_queries/index.html b/language-reference/query-syntax/learning_queries/index.html index 40a26f90..b1a32494 100644 --- a/language-reference/query-syntax/learning_queries/index.html +++ b/language-reference/query-syntax/learning_queries/index.html @@ -1,7 +1,7 @@ Syntax of Learning Queries :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/statistical_queries/index.html b/language-reference/query-syntax/statistical_queries/index.html index 791dc594..6a8cae51 100644 --- a/language-reference/query-syntax/statistical_queries/index.html +++ b/language-reference/query-syntax/statistical_queries/index.html @@ -1,7 +1,7 @@ Syntax of Statistical Queries :: UPPAAL Documentation -
    BOUND
    is a non-negative integer constant denoting an upper bound over the absolute global time (when a variable is not specified), specific Clock (cost) variable or a number of action-transitions (#).
    RUNS
    is an optional positive integer constant denoting the maximum number of runs. If the number of runs is not specified, then it is decided based on Statistical parameters and the particular estimation algorithm.
    SATRUNS
    is an optional positive integer constant denoting the maximum number of runs that satisfy the state expression.
    PROB
    is a floating point number from interval [0; 1] denoting a probability bound.
    ’#’
    means a number of simulation steps – discrete edge-transitions – in the run.
    ‘min:’
    means the minimum value over a run of the proceeding expression.
    ‘max:’
    means the maximum value over a run of the proceeding expression.

    All expressions are state predicates and must be side effect free. It is possible to test whether a certain process is in a given location using expressions on the form process.location.

    See rail road diagram for the entire SMCQuery syntax.

    See also: Semantics of the SMC Queries

    Examples

    simulate [<=10] { x }
    creates one stochastic simulation run of up to 10 time units in length and plot the values of x expression over time (after checking, right-click the query and choose a plot).
    simulate [c<=10] { x, y+z }
    creates one simulation run of up to 10 cost units in terms of clock variable c and plot the values of x and y+z expressions over the cost c.
    simulate [#<=10] { x, y+z }
    creates one simulation run of up to 10 edge-transitions and plot the values of x and y+z expressions over the discrete simulation steps (edge-transitions).
    simulate [<=10; 100] { x, y+z } : 2 : goal
    selects up to 2 simulation runs from 100 simulations of up to 10 time units in length, which satisfy goal state predicate, and then plot the values of expressions x and y+z over time. The query will also estimate a probability confidense interval of the expression goal being true just like in Pr query. The confidence level is controlled by α-level of significance in the Statistical parameters.
    Pr[<=10](<> good)
    runs a number of stochastic simulations and estimates the probability of good eventually becoming true within 10 time units. The number of runs is decided based on the probability interval precision (±ε) and confidence level (level of significance α in Statistical parameters), see Confidence Intervals for details. The query also computes a probability distribution over time when the predicate good is satisfied (right-click the property and choose a plot).
    Pr[c<=10; 100]([] safe)
    runs 100 stochastic simulations and estimates the probability of safe remaining true within 10 cost units in terms of clock c.
    Pr[<=10](<> good) >= 0.5
    checks if the probability of reaching good within 10 time units is greater than 50%. Such query uses Wald’s algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, α and β Statistical parameters.
    Pr[<=10](<> best) >= Pr[<=10](<> good)
    checks if the probability of reaching best is greater than reaching good within 10 time units. Such query uses a sequential algorithm to decide the probability inequality and requires fewer runs than probability estimation and explicit comparison. Uses -δ, +δ, u0, u1, α and β Statistical parameters. The query also provides a probability comparison plot over time/cost (right-click the query and choose plot).
    E[<=10; 100](max: cost)
    estimates the maximal value of cost expression over 10 time units of stochastic simulation. Uses 100 stochastic simulations and assumes that the value follows Student’s t-distribution with 1-α confidence level.

    The plots can be super-imposed using the Plot Composer from the Tools menu.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/strategy_queries/index.html b/language-reference/query-syntax/strategy_queries/index.html index 1926eccd..8115e7af 100644 --- a/language-reference/query-syntax/strategy_queries/index.html +++ b/language-reference/query-syntax/strategy_queries/index.html @@ -1,7 +1,7 @@ Syntax of Strategy Queries :: UPPAAL Documentation -
    StrategyName
    indicates the name of a strategy.
    Path
    is a double-quoted (using ") character sequence (string) denoting a file path on the same computer as the used engine (server or verifyta).
    Note that the backslash (\) character in (Windows) paths needs to be either escaped with another backslash or replaced with the forwardslash (/), i.e. \ should be replaced with either \\ or /.

    See rail road diagram of AssignableQuery in Query overview.

    Examples

    strategy Safe = A[] safe
    computes a safety/permissive strategy over the timed game model and stores it under the name Safe.
    A[] good under Safe
    checks that the predicate good is always satisfied when the player/controller sticks to actions permitted by Safe strategy.
    E<> goal under Safe
    checks that the goal state predicate is eventually satisfied when the player/controller uses Safe strategy.
    strategy SafeCheap = minE(cost)[<=10] {i,j} -> {d,f} : <> t>=10 under Safe
    refines Safe strategy into SafeCheap by minimizing the expected value of cost expression.
    saveStrategy("folder/file.json", Safe)
    writes Safe strategy to the file with path folder/file.json.
    strategy Safe = loadStrategy{i,j}->{d,f}("folder/file.json")
    reads the strategy from the file with path folder/file.json and stores it under the name Safe.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/query-syntax/symbolic_queries/index.html b/language-reference/query-syntax/symbolic_queries/index.html index 75f7910d..b3555606 100644 --- a/language-reference/query-syntax/symbolic_queries/index.html +++ b/language-reference/query-syntax/symbolic_queries/index.html @@ -1,7 +1,7 @@ Syntax of Symbolic Queries :: UPPAAL Documentation -
    Subjection
    indicates whether the query should be subjected to a strategy.

    For sup properties, expression may not contain clock constraints and must evaluate to either an integer or a clock.

    See rail road diagram for the entire SymbolicQuery syntax.

    See also: Semantics of the Symbolic Queries

    Examples

    A[] 1<2
    invariantly 1<2.
    E<> p1.cs and p2.cs
    true if the system can reach a state where both process p1 and p2 are in their locations cs.
    A[] p1.cs imply not p2.cs
    invariantly process p1 in location cs implies that process p2 is not in location cs.
    A[] not deadlock
    invariantly the process is not deadlocked.
    sup: Train(1).x, Train(2).x
    computes the suprema of Train(1).x and Train(2).x expressions (maximal values in case of integers, upper bounds, strict or not, for clocks).
    sup{Train(1).Crossing}: Train(1).x
    computes the supremum of Train(1).x but only when Train(1) is in Crossing.
    inf{Gate.Occ}: Gate.len
    similarly to sup, infquery computes infimum of the given expression Gate.len while process Gate is in Occ location. When a clock infimum is needed, the state predicate should be used, otherwise the result is trivially >=0.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/reserved-keywords/index.html b/language-reference/reserved-keywords/index.html index 75fd85b9..c5aa6e52 100644 --- a/language-reference/reserved-keywords/index.html +++ b/language-reference/reserved-keywords/index.html @@ -1,9 +1,9 @@ Reserved Keywords :: UPPAAL Documentation -

    Reserved Keywords

    The reserved keywords that should not be used as identifier names when defining systems are: chan, clock, double, bool, int, commit, const, urgent, broadcast, init, process, state, invariant, location, guard, sync, assign, system, trans, deadlock, and, or, not, imply, true, false, for, forall, exists, while, do, if, else, return, typedef, struct, rate, before_update, after_update, meta, priority, progress, scalar, select, void, default, string, minE, maxE, Pr.

    The following keywords are reserved for future use: switch, case, continue, break, enum.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/declarations/external-functions/index.html b/language-reference/system-description/declarations/external-functions/index.html index 31c743ff..aefd2eb9 100644 --- a/language-reference/system-description/declarations/external-functions/index.html +++ b/language-reference/system-description/declarations/external-functions/index.html @@ -1,13 +1,13 @@ External Functions :: UPPAAL Documentation -

    External Functions

    The external functions are supported since Uppaal Stratego version 4.1.20-7, or Uppaal version 5.0 or later.

    External Functions is an expert user feature and requires a high-level understanding of dynamic library loading and linking.
    The feature is supported on Linux and experimental on Windows and macOS.

    The external function calls must be deterministic: for any argument values, the function should produce the same result at any time when called with the same values.
    For example, side-effect-free (or free) functions, which do not depend on static variables, are deterministic.
    Memoization is allowed.

    External Functions can be declared alongside other declaratios. External functions are local to the current scope, defined by the grammar:

    ExternDecl   = 'import'  Path '{' [FwdDeclList] '}'
+> Language Reference > System Description > Declarations > External Functions

    External Functions

    The external functions are supported since Uppaal Stratego version 4.1.20-7, or Uppaal version 5.0 or later.

    External Functions is an expert user feature and requires a high-level understanding of dynamic library loading and linking.
    The feature is supported on Linux and experimental on Windows and macOS.

    The external function calls must be deterministic: for any argument values, the function should produce the same result at any time when called with the same values.
    Uppaal does *not check and will not warn if an external function is behaving deterministically.
    For example:

    • Side-effect-free (or free) functions, which do not depend on static variables, are deterministic.
    • Memoization pattern is not side-effect-free, but results in deterministic behavior.

    External Functions can be declared alongside other declaratios. External functions are local to the current scope, defined by the grammar:

    ExternDecl   = 'import'  Path '{' [FwdDeclList] '}'
 FwdDeclList  = FwdDecl ';' |
                FwdDeclList FwdDecl ';'
 FwdDecl      = [ID '='] Type ID '(' [Parameters] ')'
@@ -201,4 +201,4 @@
 $1 = -2147483648
 (gdb)

    In the log above, one can see that the binary is loaded from external_test.

    The program is run by command r, then a crash is observed due to failed assertion two == 2.

    A call stack trace is printed using command bt, in particular it contains main () from our source file external_test.cpp.

    Then the debugger is instructed to go up in the call stack multiple times by issuing a command up and then blank command (simply enter, which repeats the last command).

    Then at the main function call, the code line assert(two == 2); is highlighted.

    And finally the value of variable two is printed using command p two. The value is -2147483648 which is not as expected, hence the assertion failed.

    It is also possible to attach gdb to an already running process (like verifyta or Uppaal engine server), set break points and watches.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/declarations/functions/index.html b/language-reference/system-description/declarations/functions/index.html index e1d70efe..5ccfa9a8 100644 --- a/language-reference/system-description/declarations/functions/index.html +++ b/language-reference/system-description/declarations/functions/index.html @@ -1,7 +1,7 @@ Functions :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/declarations/index.html b/language-reference/system-description/declarations/index.html index 49ba34c5..4ff66550 100644 --- a/language-reference/system-description/declarations/index.html +++ b/language-reference/system-description/declarations/index.html @@ -1,7 +1,7 @@ Declarations :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/declarations/types/index.html b/language-reference/system-description/declarations/types/index.html index 1f0b9892..faeb9980 100644 --- a/language-reference/system-description/declarations/types/index.html +++ b/language-reference/system-description/declarations/types/index.html @@ -1,7 +1,7 @@ Types :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/index.html b/language-reference/system-description/index.html index c8802269..e725491c 100644 --- a/language-reference/system-description/index.html +++ b/language-reference/system-description/index.html @@ -1,10 +1,10 @@ System Description :: UPPAAL Documentation -

    System Description

    A system model in UPPAAL consists of a network of processes described as extended timed automata. The description of a model consist of three parts: its global and local declarations, the automata templates, and the system definition.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/parameters/index.html b/language-reference/system-description/parameters/index.html index ce70eefe..4667abc1 100644 --- a/language-reference/system-description/parameters/index.html +++ b/language-reference/system-description/parameters/index.html @@ -1,7 +1,7 @@ Parameters :: UPPAAL Documentation -

    Parameters

    Templates and functions are parameterised. The syntax for parameters is defined by the grammar for Parameters:

    Parameters ::= [ Parameter (',' Parameter)* ]
 Parameter  ::= [Type] [ '&' ] [ID] [ArrayDecl]*

    In contrast to global and local declarations, the parameter list should not be terminated by a semicolon.

    Call by Reference and Call by Value

    Parameters can be declared to have either call-by-value or call-by-reference semantics. The syntax is taken from C++, where the identifier of a call-by-reference parameter is prefixed with an ampersand in the parameter declaration. Call-by-value parameters are not prefixed with an ampersand.

    Clocks and channels must always be reference parameters.

    Note: Array parameters must be prefixed with an ampersand to be passed by reference, this does not follow the C semantics.

    Examples

    P(clock &x, bool bit)
    process template P has two parameters: the clock x and the boolean variable bit.
    Q(clock &x, clock &y, int i1, int &i2, chan &a, chan &b)
    process template Q has six parameters: two clocks, two integer variables (with default range), and two channels. All parameters except i1 are reference parameters.
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/priorities/index.html b/language-reference/system-description/priorities/index.html index 651869ac..afe83d2a 100644 --- a/language-reference/system-description/priorities/index.html +++ b/language-reference/system-description/priorities/index.html @@ -1,7 +1,7 @@ Priorities :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/scope-rules/index.html b/language-reference/system-description/scope-rules/index.html index dc388c2e..99df62f2 100644 --- a/language-reference/system-description/scope-rules/index.html +++ b/language-reference/system-description/scope-rules/index.html @@ -1,10 +1,10 @@ Scope Rules :: UPPAAL Documentation -

    Scope Rules

    The scope rules determine which element a name refers to in a given context. The context is either local (to a process template), or global (in a system description).

    In a local context, the names are always referring to local declarations or formal parameters (if the name is locally defined), otherwise to a globally declared name.

    In the global context, a name is always referring to a global declaration.

    Note: There is only one name space in each context. This means that in each context all declared clocks, integer variables, constants, locations, and formal paramters must have unique names. However, local names may shadow globally declared names.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/semantics/index.html b/language-reference/system-description/semantics/index.html index 471de7c0..33b62560 100644 --- a/language-reference/system-description/semantics/index.html +++ b/language-reference/system-description/semantics/index.html @@ -1,10 +1,10 @@ Semantics :: UPPAAL Documentation -

    Semantics

    In the following we give a pseudo-formal semantics for UPPAAL. The semantics defines a timed transition system (S, s0, →) describing the behaviour of a network of extended timed automata. The set of states S is defined as {(L, v) | v ⊨ Inv(L)}, where L is a location vector, v is a function (called a valuation) mapping integer variables and clocks to their values, and Inv is a function mapping locations and location vectors to invariants. The initial state s0 is the state where all processes are in the initial location, all variables have their initial value, and all clocks are zero. The transition relation, →, contains two kinds of transitions: delay transitions and action transitions. We will describe each type below.

    Given a valuation v and an expression e, we say that v satisfies e if e evaluates to non-zero for the given valuation v.

    Invalid Evaluations

    If during a successor computation any expression evaluation is invalid (consult the section on expressions for further details about invalid evaluations), the verification is aborted.

    Delay Transitions

    Delay transitions model the passing of time without changing the current location. We have a delay transition (L, v) −d→ (L, v’), where d is a non-negative real, if and only if:

    • v’ = v+d, where v+d is obtained by incrementing all clocks with d.
    • for all 0 ≤ d’ ≤ d: v+d’ ⊨ Inv(L)
    • L contains neither committed nor urgent locations
    • for all locations ℓ in L and for all locations ℓ’ (not necessarily in L), if there is an edge from ℓ to ℓ’ then either:
      • this edge does not synchronise over an urgent channel, or
      • this edge does synchronise over an urgent channel, but for all 0 ≤ d’ ≤ d we have that v+d’ does not satisfy the guard of the edge.

    Action Transitions

    For action transtions, the synchronisation label of edges is important. Since UPPAAL supports arrays of channels, we have that the label contains an expression evaluating to a channel. The concrete channel depends on the current valuation. To avoid cluttering the semantics we make the simplifying assumption that each synchronisation label refers to a channel directly.

    Priorities increase the determinism of a system by letting a high priority action transition block a lower priority action transition. Note that delay transitions can never be blocked, and no action transition can be blocked by a delay transition.

    For action transitions, there are three cases: Internal transitions, binary synchronisations and broadcast synchronisations. Each will be described in the following.

    Internal Transitions

    We have a transition (L, v) −*→ (L’, v’) if there is an edge e=(ℓ,ℓ’) such that:

    • there is no synchronisation label on e
    • v satisfies the guard of e
    • L’ = L[ℓ’/ℓ]
    • v’ is obtained from v by executing the update label given on e
    • v’ satisfies Inv(L’)
    • Either ℓ is committed or no other location in L is committed.
    • There is no action transition from (L, v) with a strictly higher priority.

    Binary Synchronisations

    We have a transition (L, v) −*→ (L’, v’) if there are two edges e1=(ℓ1,ℓ1’) and e2=(ℓ2,ℓ2’) in two different processes such that:

    • e1 has a synchronisation label c! and e2 has a synchronisation label c?, where c is a binary channel.
    • v satisfies the guards of e1 and e2.
    • L’ = L[ℓ1’/ℓ1, ℓ2’/ℓ2]
    • v’ is obtained from v by first executing the update label given on e1 and then the update label given on e2.
    • v’ satisfies Inv(L’)
    • Either
      • ℓ1 or ℓ2 or both locations are committed, or
      • no other location in L is committed.
    • There is no action transition from (L, v) with a strictly higher priority.

    Broadcast Synchronisations

    Assume an order p1, p2, … pn of processes given by the order of the processes in the system declaration statement. We have a transition (L, v) −*→ (L’, v’) if there is an edge e=(ℓ,ℓ’) and m edges ei=(ℓi,ℓi’) for 1≤i≤m such that:

    • Edges e, e1, e2, …, em are in different processes.
    • e1, e2, …, em are ordered according to the process ordering p1, p2,… pn.
    • e has a synchronisation label c! and e1, e2, …, em have synchronisation labels c?, where c is a broadcast channel.
    • v satisfies the guards of e, e1, e2, … em.
    • For all locations ℓ in L not a source of one of the edges e, e1, e2, … em, all edges from ℓ either do not have a synchronisation label c? or v does not satisfy the guard on the edge.
    • L’ = L[ℓ’/ℓ, ℓ1’/ℓ1, ℓ2’/ℓ2, … ℓm’/ℓm]
    • v’ is obtained from v by first executing the update label given on e and then the update labels given on ei for increasing order of i.
    • v’ satisfies Inv(L’)
    • Either
      • one or more of the locations ℓ, ℓ1, ℓ2, … ℓm are committed, or
      • no other location in L is committed.
    • There is no action transition from (L, v) with a strictly higher priority.

    Probabilistic Transitions

    In statistical model checking the concrete delay and transition are determined as follows:

    1. Each process chooses a delay based on its current location:
      • If the current location invariant has a time bound, then the concrete delay is taken according uniform distribution up to that bound.
      • Otherwise (the time invariant is absent) the delay is chosen by exponential distribution using the rate λ specified on the current location. The probability density function of delay d∈[0;∞) is F(d)=λe−λd, where e=2.718281828… and the concrete delay is generated by −ln(u)/λ where u is a uniform random number from (0;1] interval.
    2. The process with the shortest delay is chosen. If there are several such processes then a random one of these is chosen (according to uniform distribution).
    3. The shortest delay is executed and continuous variables are updated.
    4. The chosen process attempts to take a transition:
      • Compute all enabled internal and sending edge-transitions.
      • Pick the concrete edge according to uniform distribution.
      • If the edge has probabilistic branches, then the probability of taking a branch i is determined by the ratio wi/W, where wi is the weight of the branch i and W is the sum of all branch weights: W=Σjwj.

    Statistical model checking has the following assumptions about the model:

    Input enableness (non-blocking inputs):
    Sending cannot be blocked, i.e. the channel is either broadcast or there is always one process with an enabled receiving edge-transition.
    Input determinism:
    There is exactly one enabled receiving edge-transition at a time. For binary synchronizations there is at most one receiving process at a time.

    For more details about probabilistic semantics of priced timed automata please see:

    Statistical Model Checking for Networks of Priced Timed Automata, Alexandre David, Kim G. Larsen, Axel Legay, Marius Mikučionis, Danny Bøgsted Poulsen, Jonas van Vliet and Zheng Wang. In Proceedings of the 9th International Conference on Formal Modeling and Analysis of Timed Systems (FORMATS), Aalborg, Denmark, September 2011.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/system-definition/gantt-chart/index.html b/language-reference/system-description/system-definition/gantt-chart/index.html index c4ed9792..83572cd7 100644 --- a/language-reference/system-description/system-definition/gantt-chart/index.html +++ b/language-reference/system-description/system-definition/gantt-chart/index.html @@ -1,7 +1,7 @@ Gantt Chart :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/system-definition/index.html b/language-reference/system-description/system-definition/index.html index 88cdeaa1..b3ddf5e2 100644 --- a/language-reference/system-description/system-definition/index.html +++ b/language-reference/system-description/system-definition/index.html @@ -1,7 +1,7 @@ System Definition :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/system-definition/progress-measures/index.html b/language-reference/system-description/system-definition/progress-measures/index.html index 58d43d11..e09610b8 100644 --- a/language-reference/system-description/system-definition/progress-measures/index.html +++ b/language-reference/system-description/system-definition/progress-measures/index.html @@ -1,7 +1,7 @@ Progress Measures :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/system-definition/template-instantiation/index.html b/language-reference/system-description/system-definition/template-instantiation/index.html index 84f3aad1..61a850a8 100644 --- a/language-reference/system-description/system-definition/template-instantiation/index.html +++ b/language-reference/system-description/system-definition/template-instantiation/index.html @@ -1,7 +1,7 @@ Template Instantiation :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/templates/edges/index.html b/language-reference/system-description/templates/edges/index.html index a715d73d..01c54e44 100644 --- a/language-reference/system-description/templates/edges/index.html +++ b/language-reference/system-description/templates/edges/index.html @@ -1,7 +1,7 @@ Edges :: UPPAAL Documentation -
    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/templates/index.html b/language-reference/system-description/templates/index.html index a1047848..a7cf7bfb 100644 --- a/language-reference/system-description/templates/index.html +++ b/language-reference/system-description/templates/index.html @@ -1,11 +1,11 @@ Templates :: UPPAAL Documentation -

    Templates

    UPPAAL provides a rich language for defining templates in the form of extended timed automata. In contrast to classical timed automata, timed automata in UPPAAL can use a rich expression language to test and update clock, variables, record types, call user defined functions, etc.

    The automaton of a template consist of Locations and edges. A template may also have local declarations and parameters. A template is instantiated by a process assignment (in the system definition).

    \ No newline at end of file +
    \ No newline at end of file diff --git a/language-reference/system-description/templates/locations/index.html b/language-reference/system-description/templates/locations/index.html index 6be2a145..9e9220e9 100644 --- a/language-reference/system-description/templates/locations/index.html +++ b/language-reference/system-description/templates/locations/index.html @@ -1,7 +1,7 @@ Locations :: UPPAAL Documentation -

    Locations

    Locations of a timed automaton are graphically represented as circles. If a timed automaton is considered as a directed graph, then locations represent the vertices of this graph. Locations are connected by edges.

    Names

    Locations can have an optional name. Besides serving as an identifier allowing you to refer to the location from the requirement specification language, named locations are useful when documenting the model. The name must be a valid identifier and location names share the name space with variables, types, templates, etc.

    Invariants

    Locations are labelled with invariants. Invariants are expressions and thus follow the abstract syntax of expressions. However, the type checker restricts the set of possible expressions allowed in invariants.

    An invariant must be a conjunction of simple conditions on clocks, differences between clocks, and boolean expressions not involving clocks. The bound must be given by an integer expression. Furthermore lower bounds on clocks are disallowed. It is important to understand that invariants influence the behaviour of the system – they are distinctly different from specifying safety properties in the requirements specification language. States which violate the invariants are undefined; by definition, such states do not exist. This influences the interpretation of urgent channels and broadcast channels. Please see the section on synchronisations for a detailed discussion of this topic.

    In addition, stop-watches are supported and they are declared with invariants. Clock rate expressions are specified and they are part of the conjunction in the invariant. Furthermore, the forall construct is accepted in invariants to ease use of arrays.

    Statistical model checker supports any integer expression as a clock rate which allows modeling costs.

    Rate of Exponential

    The rate of exponential is a ratio expression which specifies the rate of exponential probability distribution. The rate expression can be a simple integer expression or two integer expressions separated by a colon like r:q where the rate is determined as ratio r/q.

    The rate of exponential is used in a statistical model checking. If the location does not have an invariant over time, then it is assumed that the probability of leaving the location is distributed according to the exponential distribution: Pr(leaving after t)=1−e−λt, where e=2.718281828…, t is time and λ is the fixed rate. Probability density of the exponential distribution is λe−λt and thus intuitively λ means the probability density of leaving at time zero, i.e. as soon as some edge is enabled. The smaller the rate is specified, the longer the delay is preferred.

    The generation of exact delay relies on pseudo random number generator and on 32-bit architectures the longest possible delay is rather limited: ln(231)/λ ≈ 21.49/λ.

    Examples

    The following are valid invariants. Here x and y are clocks and i is an integer array.

    x <= 2
    x is less than or equal to 2.
    x < y
    x is (strictly) less than y.
    forall(i:int[0,2]) x[i] <= 3
    The clocks x[0], x[1] and x[2] of the clock array x are less or equal to 3.
    forall(i:int[0,2]) y[i]' == b[i]
    The clock rates y[0]', y[1]', and y[2]' are set to, respectively, b[0], b[1] and b[2]. Note that for symbolic queries the only valid values are 0 and 1. Setting the rate to 0 effectively stops a clock (makes it a stop-watch). In statistical model checking the rate is allowed to be any floating point value. hybrid clock can be interpreted as a continuous cost and abstracted away in symbolic queries while maintaining concrete values in statistical queries.

    Initial locations

    Each template must have exactly one initial location. The initial location is marked by a double circle.

    Urgent locations

    Urgent locations freeze time; i.e. time is not allowed to pass when a process is in an urgent location.

    Semantically, urgent locations are equivalent to:

    • adding an extra clock, say x, that is reset on every incomming edge, and
    • adding an invariant x <= 0 to the location.

    Committed locations

    Like urgent locations, committed locations also freeze time. Furthermore, if any process is in a committed location, the next transition must involve an edge from one of the committed locations.

    Committed locations are useful for creating atomic sequences and for encoding synchronization between more than two components. Notice that if several processes are in a committed location at the same time, then they will interleave.

    \ No newline at end of file +
    \ No newline at end of file diff --git a/preview-build/index.html b/preview-build/index.html index 47a38c83..3b1f496e 100644 --- a/preview-build/index.html +++ b/preview-build/index.html @@ -1,9 +1,9 @@ :: UPPAAL Documentation -

    Preview Build

    UPPAAL 5.0.0 beta2 since UPPAAL 5.0.0 beta1

    • Fixed symbolic trace as concrete trace output to pass the regression suite by
    • Fix version check serialization issue on startup
    • Fix issue where fatal engine errors are lost when parsing BasicResponse
    • Fixed version date parsing to be more robust
    • Updated JetBrainMono fonts
    • Added bold italic highlighting for /// comments
    • Update old dtd version to fit model files

    UPPAAL 5.0.0 beta1 since UPPAAL 4.1.20 Stratego 11

    • Graceful cancellation and other result output fixes
    • Cleanup demo examples
    • Fix ant release date and applied format validation to release dates
    • Fix issue where plots would seemingly go backwards in time
    • Swap result and query
    • Fixed font and drawing anti-aliasing in the verification dialog
    • Removed splashscreen as startup seems to be fast enough
    • Fix issue where the last delay transition of a concrete witness trace would be omitted
    • Fixed issues with advanced line break
    • Recover concrete trace output on verifyta
    • Add parsing for saving plot settings in concrete simulator
    \ No newline at end of file +
    \ No newline at end of file diff --git a/tags/index.html b/tags/index.html index c7126a12..4bea174b 100644 --- a/tags/index.html +++ b/tags/index.html @@ -1,7 +1,7 @@ Tags :: UPPAAL Documentation -

    tag :: -Tags

      \ No newline at end of file +Tags
      \ No newline at end of file diff --git a/toolsandapi/file-formats/index.html b/toolsandapi/file-formats/index.html index 1b63f920..560a0a02 100644 --- a/toolsandapi/file-formats/index.html +++ b/toolsandapi/file-formats/index.html @@ -1,9 +1,9 @@ File Formats :: UPPAAL Documentation -

      File Formats

      UPPAAL supports three file formats for models: XML, XTA and TA. XML and XTA files can be loaded and stored via the Open Project, Open System, Save System, and Save System As menus. When saving a file, the file type is determined by the file name extension used. Each format is explained in more details below.

      Notice that the above mentioned file formats are mostly independent from the type of changes made to the syntax between UPPAAL 3.4 and UPPAAL 4.0.

      In additon to the file formats for models, UPPAAL uses clear text query files for storing queries and the XTR file format for storing traces.

      XML

      The newest format is XML based and files in this format have the ending .xml. This format supports all features of UPPAAL. Elements like templates, locations, edges and labels are described using tags. This format was introduced in the GUI in version 3.2. As of version 3.4, the XML format is also supported by the verification engine. The GUI uses this format as its native file format. The addition of colors and notes on labels and edges, and the select expresssion on edges in UPPAAL 4.0 has resulted in the addition of a color attribute and two new label types. If these features are not used, the XML files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.

      The level of abstraction in the format is chosen so that the format is independent of the actual syntax of declarations, invariants, guards, etc. Thus all labels are simply treated as strings without structure. In a GUI, this is very important, since the user might enter arbitrary text into the label fields and the file format must be able to cope with this situation. Before the introduction of the XML format, the XTA format was used. With this format it was not possible to save syntactically incorrect systems, i.e., if the user made a mistake in the syntax of a label it was not possible to save this systems.

      XTA

      The XTA format was introduced in version 3.0. This format can only reliably store syntactically correct systems. Anonymous locations are not supported by this format (UPPAAL automatically assigns a unique name to anonymous locations when saved to an XTA file). Graphical information (coordinates) about the objects are stored in a separate UGI file, although this is transparent to the user. XTA files use the ending .xta and UGI files the ending .ugi.

      In UPPAAL 4.0, the XTA format was extended with support for the select expression on edges. The UGI format was extended with support for the color attributes. If these features are not used, the XTA files generated by UPPAAL 4.0 are readable by UPPAAL 3.4.

      TA

      The TA format is a subset of the XTA format and does not support the template concept nor does it contain any graphical information about the system. UPPAAL can no longer save files in this format, although TA files can still be read.

      Query files

      Query files use a clear-text format listing all queries inleaved with comments. The format dates back to UPPAAL 2. Files in this format have the file ending .q.

      Trace files

      Traces can be stored using the XTR format and files in this format have the file ending .xtr. The format was introduced in UPPAAL 3.0.

      XTR files are intimately linked to the model from which they were generated. Any change (other than layout and white space changes) in the model may render the trace file unreadable. Even reordering some variable declarations will break the link.

      Our parser library, libutap, contains a small utility called tracer, which can read XTR files and translate them to a human readable format. The library and the utility are released under the LGPL license and may thus be used as a starting point for writing custom trace analysis tools. More information about the library can be found on the UPPAAL web page.

      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/index.html b/toolsandapi/index.html index 2e97ff26..2632402d 100644 --- a/toolsandapi/index.html +++ b/toolsandapi/index.html @@ -1,11 +1,11 @@ Tools & API :: UPPAAL Documentation -

      Chapter 1

      Tools & API

      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/javaapi/index.html b/toolsandapi/javaapi/index.html index 8dfd1870..b55331ce 100644 --- a/toolsandapi/javaapi/index.html +++ b/toolsandapi/javaapi/index.html @@ -1,9 +1,9 @@ Java API :: UPPAAL Documentation -

      Java API

      UPPAAL models can be created, loaded, saved, simulated and checked using libs/model.jar library. There is also javadoc included libs/model-javadoc.jar.

      A demonstrating example is included in the demo/ModelDemo.java file.

      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/latex/index.html b/toolsandapi/latex/index.html index 8890341a..3cdc0bef 100644 --- a/toolsandapi/latex/index.html +++ b/toolsandapi/latex/index.html @@ -1,9 +1,9 @@ Latex :: UPPAAL Documentation -

      Latex

      UPPAAL web site includes links to uppaal.sty file — style for typesetting documents in LaTeX.

      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/socketserver/index.html b/toolsandapi/socketserver/index.html index 48643e29..f6426fa0 100644 --- a/toolsandapi/socketserver/index.html +++ b/toolsandapi/socketserver/index.html @@ -1,9 +1,9 @@ Socketserver :: UPPAAL Documentation -

      Socketserver

      To start a remote server, use the socketserver binary (included for Linux, SunOS and MacOS). To use a remote server, see the section on command line options for the GUI.

      The socketserver can be executed from the command line using one of the following commands:

      socketserver [-p] [-s]
      socketserver -h

      The available command line options are:

      -h
      Prints a brief description of the command line options.
      -p
      Set port in server mode (default is 2350).
      -s
      Set filename of server binary to P2.

      The socketserver will load the server from the directory where it was invoked, and act as a proxy.

      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/uppaal/index.html b/toolsandapi/uppaal/index.html index 8755bffb..75bc9203 100644 --- a/toolsandapi/uppaal/index.html +++ b/toolsandapi/uppaal/index.html @@ -1,9 +1,9 @@ UPPAAL :: UPPAAL Documentation -

      UPPAAL

      UPPAAL can be executed from the command line using the following command on unix:

      uppaal [OPTION] … [FILENAME]

      On windows, the following command can be used (for instance, using “Run” from the Start Menu):

      java -jar \path\uppaal.jar [OPTION] … [FILENAME]

      where path is the complete path to the uppaal.jar file (it might also be necessary to specify the complete path to the java executable).

      The optional filename refers to a model to be loaded at startup.

      The available command line options are:

      --antialias on|off
      (default on) turns antialiasing on or off in the automata rendering.
      --engineName
      The name of verification server (default is server on Unix and server.exe on Windows) to be used by the GUI.
      --enginePath
      The path to the verification server (e.g. bin-Windows) to be used by the GUI.
      --help
      Displays a summary of options.
      --serverHost
      Host name of remote machine running verification server.
      --serverPort
      Port number used by verification server on remote machine.
      --export templateName filename.ext
      Export the named template to a graphics file. The graphics format is determined by the filename extension, and EPS will be used instead if format is not recognized. Use system keyword to export all templates where the filenames will be taken from the template name.
      --psColors on|off
      Selects whether to export automata in color or greyscale EPS.
      \ No newline at end of file +
      \ No newline at end of file diff --git a/toolsandapi/verifyta/index.html b/toolsandapi/verifyta/index.html index fcef308a..11dd6086 100644 --- a/toolsandapi/verifyta/index.html +++ b/toolsandapi/verifyta/index.html @@ -1,9 +1,9 @@ verifyta :: UPPAAL Documentation -

      verifyta

      The verifier functionality is accessible through verifyta command line utility in bin-Windows or bin-Linux directory of the distribution. The supported options are displayed when running verifyta -h.

      \ No newline at end of file +
      \ No newline at end of file