Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HOA path formulas #129

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

kleinj
Copy link
Member

@kleinj kleinj commented Mar 26, 2020

With this PR, PRISM learns a new mechanism for specifying path formulas: Directly via a deterministic automaton in HOA format.

PRISM already supports HOA automata, when they are constructed by an external tool from an LTL path formula. Now, one can write properties like
P=?[ HOA: {"filename.hoa"} ]
which computes the probability of the paths that are accepted by the given HOA automaton. In this short form, the atomic propositions (APs) from the automaton are matched with the corresponding labels in the model. Alternatively, one can specify state expressions for labels, e.g.,
P=?[ HOA: {"filename.hoa", "a" <- s=3, "b" <- (s=1|s=2) }
Here, the automaton has two APs, a and b, which are mapped to the set of states satisfying s=3 and (s=1|s=2), respectively.

This has a few advantages:

  • It might be easier to generate a HOA automaton with an external tool directly, then store it as a file and use it in the property than to have to write wrapper scripts for the external tool.
  • With the above, the generation time for the automaton can be amortized over multiple runs.
  • It facilitates easier debugging and testing of the HOA functionality, as we don't have to rely on tools to produce the automata.
  • It allows to use path specifications outside of LTL, i.e., the full omega-regular languages by either writing/generating the automaton directly or using tool support, e.g., Spot's support for PSL formulas.

This is the first time that properties can refer to external filenames, which raises the issue how to deal with relative filenames (similar to things like #include in C++, etc). Here, we propose to do resolution as follows:

  1. First, if the property is part of a property file, we resolve relative to it's directory
  2. Otherwise, if the model is from a file, we resolve relative to the model's directory
  3. As a last resort, we resolve relative to the working directory

We also propose a mechanism to explicitly specify the directory for resolution by 3 macros, i.e., for following would be valid filenames for a HOA path expression:

  1. $PROPERTY_DIR/filename.hoa
  2. $MODEL_DIR/filename.hoa
  3. $WORKING_DIR/filename.hoa

Note that these macros are only considered if they are at the beginning of the location string.

This extension was published in "Advances in Symbolic Probabilistic Model Checking with PRISM" (TACAS'16) and has been in use at TU Dresden for quite some time.

TODOs:

  • Documentation for the manual
  • Does this interfere with prism-games? (quoted string refactoring, new expression type)

kleinj added 8 commits March 26, 2020 17:57
The support for computing end components was already there, so we just
have to allow STREETT acceptance in the product construction/LTL
generation.
…ssible

If we know the filename of a ModulesFile or PropertiesFile, we store
it and make it accessible.  Note that we don't necessarily have a
filename, e.g., when dealing with model code from the GUI that has not
yet been saved.

Additionally, for symbolic/explicit StateModelChecker, we provide
access to the ModulesFile / PropertiesFile stored in the model
checker.
…model or properties file.

This helper can be used to resolve paths given in PRISM properties,
e.g., the location of an automaton file in a path expression.

If the path is relative, we will resolve it relative to
 1) the properties file location (if there is one)
 2) the model file location (if there is one)
 3) the working directory.

Additionally, it's also possible to specify paths using the following three macros:
 $MODEL_DIR/filename
 $PROPERTY_DIR/filename
 $WORKING_DIR/filename
which resolve relative to the directory where the model file or the property file is
located or the working directory.
Before, double quotes were an individual lexical symbol and only
syntactic, i.e., inside the quotes only identifier characters were
allowed and thus no actual quoting was going on. As we want to support
properly quoted string (e.g., for file system locations), we refactor
here by providing a rule for QuotedIdentifiers.
Support arbitrary quoted strings.

As REG_QUOTED_IDENT takes precedence over REG_QUOTED_STRING,
QuotedString matches QuotedIdentifier as well.
* ExpressionHOA and visitor adaption
* Add Expression.isHOA to check for (negated) HOA expression
* PathSpecification supports LTL and HOA-style path specifications
  e.g. P=?[ HOA: { "automatonfile", "ap1" <- "label1", "ap2" <- "label2" } ]
* LTL2DA: readHOA and fromExpressionHOA helpers
* Add support in LTLModelCheckers (ex/sym) to support HOA path specifications
* some testcases

Additionally, protect multi-objective model checking and checkRewardCoSafeLTL against HOA path specifications.
Later on, we can add handling for that.
@davexparker davexparker force-pushed the master branch 2 times, most recently from ca12ca0 to 6bf73df Compare January 12, 2024 14:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant