Zetav is a tool for verification of systems specified in RT-Logic language.
Verif is a tool for verification and computation trace analysis of systems described using the Modechart formalism. It can also generate a set of restricted RT-Logic formulae from a Modechart specification which can be used in Zetav.
With default configuration file write the system specification (SP) to the sp-formulas.in file and the checked property (security assertion, SA) to the sa-formulas.in file. Launch zetav-verifier.exe to begin the verification.
With the default configuration example files and outputs are load/stored to archive root directory. But using file-browser you are free to select any needed location. To begin launch run.bat (windows) or run.sh (linux / unix). Select Modechart designer and create Modechart model or load it from file.
All verifier configuration data are stored in XML file named zetav.cfg. Content of this file is loaded during verifier core initialization, more precisely during configuration subsystem initialization.
Table below contains used data types description.
| Entry data type | Description |
|---|---|
| string | Standard string type. |
| multi-string | Compound string type. It consists of multiple strings separated by semicolons (;), commas (,) or vertical slashes (|). |
| sid | String identifier. Standard string type which identifies plugin or module. |
| bool | Boolean type. Value could be either 0 (false) or 1 (true). |
All possible configuration entries are listed in tables below with entry description, data type, possible values and default value if entry is missing. Possible values column could contain enumeration of possible values, with special value other, which means that other values than values present might be possible, interval, value any which means that no specific restrictions has been placed on the value (only the data type restriction) or sid (String ID) value, standard string data type which identifies internal or external plugins. Configuration entry can contain <entry> string as part of its name. The <entry> string represents custom part of entry name and is mostly replaced by values from other configuration entries.
Basic configuration (must be present in zetav.cfg xml configuration file).
| Configuration entry | Entry data type | Possible values | Default value | Description |
|---|---|---|---|---|
| subsystem/extensions/path | multi-string | any | ./plugins;./modules | Specifies path to directories with Zetav verifier plugins and modules. |
| subsystem/configuration/load | multi-string | any | Specifies other configurations which shall the configuration subsystem load. Each multi-string value specifies one configuration <entry> with informations about specific configuration. | |
| subsystem/configuration/config/<entry>/name | sid | any | Specifies <entry> configuration processing plugin (internal or external). <entry> value is multi-string value from subsystem/configuration/load configuration entry. | |
| subsystem/configuration/config/<entry>/source | string | any | empty-string | Specifies <entry> configuration source passed to class implementing the shared::IConfigReader interface. <entry> value is multi-string value from subsystem/configuration/load configuration entry. |
| subsystem/configuration/config/<entry>/force-priority | bool | 0 or 1 | 0 | Specifies if <entry> configuration should be loaded with maximum priority in contrast to currently loaded configurations. <entry> value is multi-string value from subsystem/configuration/load configuration entry. |
Additional configuration (could be loaded from informations in basic configuration).
| Configuration entry | Entry data type | Possible values | Default value | Description |
|---|---|---|---|---|
| subsystem/logging/messages/logger | sid | internal-stdout internal-stderr internal-file other |
internal-stdout | Specifies class which will log information messages. Verifier contains three internal logging classes, which log to standard output (stdout), standard error output (stderr) and file (file). Other classes can be used through the extension system, identified by string returned by shared::IPlugin::sid() method. |
| subsystem/logging/messages/shared | bool | 0 or 1 | 1 | Specifies if information messages logging class should be created as shared object. Logging target is set only once after the shared object is created, so the target configuration is ignored by other entries which request shared object with the same specified sid. |
| subsystem/logging/messages/target | string | any | ./zetav.log | Specifies target file or other location, where shall the logging class write the information messages. |
| subsystem/logging/warnings/logger | sid | internal-stdout internal-stderr internal-file other |
internal-stdout | Specifies class which will log messages classified as warnings. Verifier contains three internal logging classes, which log to standard output (stdout), standard error output (stderr) and file (file). Other classes can be used through the extension system, identified by string returned by shared::IPlugin::sid() method. |
| subsystem/logging/warnings/shared | bool | 0 or 1 | 1 | Specifies if warning messages logging class should be created as shared object. Logging target is set only once after the shared object is created, so the target configuration is ignored by other entries which request shared object with the same specified sid. |
| subsystem/logging/warnings/target | string | any | ./zetav.log | Specifies target file or other location, where shall the logging class write the warning messages. |
| subsystem/logging/errors/logger | sid | internal-stdout internal-stderr internal-file other |
internal-stderr | Specifies class which will log messages classified as errors. Verifier contains three internal logging classes, which log to standard output (stdout), standard error output (stderr) and file (file). Other classes can be used through the extension system, identified by string returned by shared::IPlugin::sid() method. |
| subsystem/logging/errors/shared | bool | 0 or 1 | 1 | Specifies if error messages logging class should be created as shared object. Logging target is set only once after the shared object is created, so the target configuration is ignored by other entries which request shared object with the same specified sid. |
| subsystem/logging/errors/target | string | any | ./zetav.log | Specifies target file or other location, where shall the logging class write the error messages. |
| subsystem/logging/log-level | integer | 0 (none) 1 (errors) 2 (warnings) 3 - 7 (information) |
3 | Specifies how much informations will be logged. Each log level specifies what additional informations will be logged in addition to information from level below. Level 3 to 7 specify amount of details in information messages, where greater number means more detailed informations. External modules should decide itselves to which level each log message belongs. Note that level 7 should be taken as debug level which shouldn't be normally used. Default level is 3, which will log errors, warnings and most important informations, for example computation progress. |
| verification/run/chain | multi-string | any | Specifies module chaining which designates verification process. Each multi-string value represents <value> module, modules are executed in specified order sequentially. The chain can be viewed as pipelined command, e.g. module1|module2|module3 will first run <module1> module, then run <module2> module with <module1> module's output as input and at last run <module3> module with <module2> module's output as input. Verifier will search the config file for <value> module configuration section under verification/module/<value>, if the section is not found, the multi-string value will be interpreted as module sid. | |
| verification/module/<value>/name | sid | any | Specifies <value> module sid. Verifier will try to find an external module, which have the specified sid and execute it. | |
| verification/module/<value>/input/info | string | any | String describing input string passed to the <value> module in specified chain. Value of this string is stored in shared::tInputData.info structure item. | |
| verification/module/<value>/input/data | string | any | Input string passed to the <value> module in specified chain. Value of this string is stored in shared::tInputData.data structure item. |
Tool is based on JPF (Java Plugin Framework). To make it work properly, Java at least in version 1.4 must be installed and system paths for Java must be set. All tool plugins are located in plugins directory and newly released plugins can be placed here. At the moment Modechart designer (mddesigner) and Modechart verifier (mdverif) plugins are avalaible to use.
The Zetav verifier expects the input RRTL formulae to be in the following form:
<rrtlformula> : <formula> [ CONNECTIVE <formula> ] ... <formula> : <predicate> | NOT <formula> | <quantifiedvars> <formula> | ( <formula> ) <predicate> : <function> PRED_SYMB <function> <function> : <function> FUNC_SYMB <function> | @( ACTION_TYPE ACTION , term ) | CONSTANT <quantifiedvars> : QUANTIFIER VARIABLE [ QUANTIFIER VARIABLE ] ...Where predicate symbols (PRED_SYMB) could be inequality operators <, =<, =, >=, >, function symbols (FUNC_SYMB) could be basic + and - operators, action type (ACTION_TYPE) could be starting action (^), stop action ($), transition action (%) and external action (#). Quantifier symbols (QUANTIFIER) could be either an universal quantifier (forall, V) or an existential quantifier (exists, E). Connectives (CONNECTIVE) could be conjunction (and, &, /\), disjunction (or, |, \/), or implication (imply, ->). All variables (VARIABLE) must start with a lower case letter and all actions (ACTION) with an upper case letter. Constants (CONSTANT) could be positive or negative number. RRTL formulae in the input file must be separated using semicolon (;).
V t V u (
( @(% TrainApproach, t) + 45 =< @(% Crossing, u) /\
@(% Crossing, u) < @(% TrainApproach, t) + 60
)
->
( @($ Downgate, t) =< @(% Crossing, u) /\
@(% Crossing, u) =< @($ Downgate, t) + 45
)
)
Verif tool does not deal with direct input. Examples are load from files with extension MCH. Those files are in XML and describes model modes structure and transition between modes. There is no need to directly modify those files. But in some cases it is possible to make some small changes manualy or generate Modechart models in another tool.
If you have further questions, do not hesitate to contact authors ( Jan Fiedor and Marek Gach ).
This work is supported by the Czech Science Foundation (projects GD102/09/H042 and P103/10/0306), the Czech Ministry of Education (projects COST OC10009 and MSM 0021630528), the European Commission (project IC0901), and the Brno University of Technology (project FIT-S-10-1).