Temporal logic query checking: a tool for model exploration

Abstract

Temporal logic query checking was first introduced by W. Chan in order to speed up design understanding by discovering properties not known a priori. A query is a temporal logic formula containing a special symbol ? 1 , known as a placeholder. Given a Kripke structure and a propositional formula ', we say that ' satisfies the query if replacing the placeholder by ' results in a temporal logic formula satisfied by the Kripke structure. A solution to a temporal logic query on a Kripke structure is the set of all propositional formulas that satisfy the query. Query checking helps discover temporal properties of a system and, as such, is a useful tool for model exploration. In this paper, we show that query checking is applicable to a variety of model exploration tasks, ranging from invariant computation to test case generation. We illustrate these using a Cruise Control System. Additionally, we show that query checking is an instance of a multi-valued model checking of Chechik et al. This approach enables us to build an implementation of a temporal logic query checker, TLQSolver, on top of our existing multi-valued model checker 1Chek. It also allows us to decide a large class of queries and introduce witnesses for temporal logic queries-an essential notion for effective model exploration.

Automatically Discovering Properties That Specify the Latent Behavior of UML Models

“…Dynamic inference approaches infer likely properties, called invariants, from execution traces generated by code specifications (e.g., [9,10,15]). Temporal logic query checking (e.g., [8,12]) finds the strongest formulae adhered to by the model that satisfy the temporal logic query, which is a temporal logic formula with placeholders.…”

“…Next, we discuss the specification generation techniques that generate temporal logic properties [8,9,12,14,15]. Perracotta [15], a dynamic inference approach, generates eight variations of the temporal logic response pattern from imperfect execution traces, where the developer instruments the program to monitor events and states of interest that constitute the possible propositions.…”

“…Refinement-based approaches (e.g., [6]) infer properties from formally specified goals or requirements. Lastly, specification generation techniques (e.g., [7][8][9][10][11][12][13][14][15]) infer properties from a representation of a system (e.g., a model or code) or a derivative of the system (e.g., execution traces). Several previously developed specification generation approaches are able to infer temporal logic properties from a model [8,12], code [14], or execution traces [9,15].…”

“…Lastly, specification generation techniques (e.g., [7][8][9][10][11][12][13][14][15]) infer properties from a representation of a system (e.g., a model or code) or a derivative of the system (e.g., execution traces). Several previously developed specification generation approaches are able to infer temporal logic properties from a model [8,12], code [14], or execution traces [9,15]. For these approaches, the developer identifies a part of the system behavior to explore, either by restricting the exploration to a portion of the code [14], or by explicitly selecting the states, events, and variables that are of interest [8,9,12,15].…”

“…Several previously developed specification generation approaches are able to infer temporal logic properties from a model [8,12], code [14], or execution traces [9,15]. For these approaches, the developer identifies a part of the system behavior to explore, either by restricting the exploration to a portion of the code [14], or by explicitly selecting the states, events, and variables that are of interest [8,9,12,15]. One ramification of having the developer guide the exploration is that the unexplored portions of the system may still conceal latent unwanted behavior.…”