Towards a Hybrid Verification Approach

Abstract

Verification methods have limitations rooted in their methodological approach. Different methods can be more appropriate in verifying some type of properties than others. We propose a “Hybrid Verification” scheme that verifies different properties using different verification methods and supports a unified specification interface, based on a suitable coordination model. Identifying appropriate verification methods for each property to be verified is a necessary prerequisite for this approach. This work introduces a categorization of properties to be verified and a corresponding mapping to suitable verification methods in accordance with and discussing existing literature. A unified modeling methodology for various assertions based on a coordination model is presented. A generic use cases from the railway domain is used to show the applicability of the proposed Hybrid Verification scheme.

Appendices

Appendix A: Peer Model/Graphical Notation in a Nutshell

The following is a brief overview – assembled from [31, 33, 37] – of the features of the Peer Model needed for the use case presented in this paper. The Peer Model is a coordination model that relies on known foundations like shared tuple spaces [20, 21, 34], Actor Model [3], and Petri Nets [41]. It separates coordination logic from business logic and is intended to model reusable coordination solutions. A peer relates to an actor in the Actor Model [3]. It is an autonomous worker with a name; it receives entries (representing messages, events etc.) in an incoming mailbox termed “peer input container” (PIC). Optionally it also possesses a “peer output container” (POC). A container is a tuple space that stores entries that are written, read, or taken (i.e., read and removed) in local transactions. Entries are the units of information passed between peers. An entry has system- and application-defined properties. The coordination behavior of a peer is explicitly modeled with wirings, which have some similarity with Petri Net transitions [41]. A wiring has guards that retrieve entries from containers, and actions that write entries to containers or send them to other peers. In addition, a wiring may call a service which encapsulates application logic. All wirings run concurrently. The arrival of entries in containers triggers the execution of wirings.

Property $prop = (label, val)$. label is a name, and val denotes a value. The property is named after its label.

Entry $e = \mathbb {E}prop$. $\mathbb {E}prop$ is a set of properties $\{prop_1,$ $prop_2,$ $\ldots ,$ $prop_n\}$.

Container $c = (cid, \mathbb {E}, \mathbb {C}oord, \mathbb {C}prop)$. A container stores entries. cid is a unique name, $\mathbb {E}$ a set of entries, $\mathbb {C}oord$ a set of coordinators (see Query below), and $\mathbb {C}prop$ a set of system properties. A container relates to an XVSM container [34]. We differentiate between space containers and internal containers. The former ones support transactions and blocking behavior. Entries are retrieved by a query that necessarily requires the coordination type of the entry.

Query $q = (type, cnt, \mathbb {S}el)$. type is an entry coordination type. cnt is a number, a range, or the keyword ALL or NONE, determining the amount of entries to be selected; default is 1. $\mathbb {S}el$ is a sequence of AND/OR connected selectors. A selector is lent from the XVSM query mechanism [14]. It refers to a container coordinator (e.g. fifo, key, label, any) or is a selection expression involving entry properties, variables and system functions.

Link $l = (c_1, c_2, op, q, \mathbb {E}xpr, \mathbb {L}prop)$. $c_1$ refers to a source and $c_2$ to a target container. op possibilities are³: create (creates new entries and writes them to $c_2$), read (reads entries from $c_1$ and writes them to $c_2$), take (reads and deletes entries from $c_1$ and writes them to $c_2$), delete (reads and deletes entries from $c_1$), and test (checks entries in $c_1$). All operations must fulfill the query q, if it is not empty, on $c_1$. $\mathbb {E}xpr$ is a sequence of expressions that set or get properties of selected entries and/or of variables. $\mathbb {L}prop$ is a set of system properties, like e.g. using flow correlation.

Wiring $w = (wid, \mathbb {G}, \mathbb {S}, \mathbb {A}, wic, \mathbb {W}prop)$. wid is a unique name, $\mathbb {G}$ is a sequence of guard links, $\mathbb {S}$ is a sequence of service links to external services, $\mathbb {A}$ is a sequence of action links, wic is the id of an internal container, and $\mathbb {W}prop$ is a set of system properties. All links are numbered, specifying an execution order which has impact on concurrency and performance. Entries selected by guards are written into wic. Then w calls the services in the specified sequence. Finally, the wiring executes the action links. $c_2$ of a guard and $c_1$ of an action link is wic. There is one dedicated wiring in a peer termed init wiring with its first guard having the identifier “*”; it is fulfilled exactly once, namely when the peer is activated.

Service $s = (sid, app)$. sid is the name of the service and app a reference to the implementation of its application logic (method). A service gets entries from its wiring’s wic as input and emits result entries there (via service links).

Peer $p = (pid, pic, poc, \mathbb {W}id, \mathbb {S}pid, \mathbb {P}prop)$. pid is a unique name, pic and poc are the ids of incoming and outgoing space containers where p receives and delivers entries, $\mathbb {W}id$ is a set of wiring ids, $\mathbb {S}pid$ is a set of ids of sub-peers, and $\mathbb {P}prop$ is a set of system properties.

Peer Model $PM = (\mathbb {P}, \mathbb {W}, \mathbb {C})$. $\mathbb {P}$ is the set of all peers including sub-peers, $\mathbb {W}$ is the set of all wirings, and $\mathbb {C}$ is the set of all containers in the system.

Runtime Assertion Mechanism: In [37], invariant assertions for the Peer Model have been introduced. They are statements about container states. They consist of intra-peer assertions connected to a logic formula by NOT, AND, OR and $\rightarrow$. Intra-peer assertions contain a context and a statement part. The context defines number, type and properties of peers for which the statement must be fulfilled. The statement is a logic formula of container assertions connected by NOT, AND, OR and $\rightarrow$. Container assertions refer to a container where they must hold and a container statement. The container can be the PIC or the POC. The container statement basically is a query on the respective container which may involve local variables (written with a starting $ character). Clearly, due to the nature of runtime assertions, it cannot be guaranteed that all failures are detected. If a strict verification is need, a so-called “history container” HIC can be involved which remembers all events. The mechanism allows for asynchronous distributed runtime reasoning about distributed states with small messaging overhead. The Peer Model supports also the specification of timing properties, but the assertions as presented in [37] cannot yet define constraints on them.

The here proposed Hybrid Verification approach relies on this assertion language to formulate properties and to verify them with respective integrated verification methods. For this, we extend the assertion language by a “future container”, which is a similar concept like the history container. The difference is that assertions using the future container refer to future system states. It is denoted by PIC $^{[t1; t2]}$. This way assertions can refer to entries in the PIC between current time plus t1 and current time plus t2. The implementation of future runtime assertion checking for assertions is part of our future work.

Real-Time Wirings: The Peer Model supports the combination of event- and time-triggered coordination. For the latter, time-triggered wirings and real-time exceptions are defined (see [31] for more details). Time triggered wirings are activated at a specified absolute time (tt.start), and have a defined period (tt.period) and duration(tt.duration).

Graphical Notation: The graphical representation of the Peer Model is shown in Fig. 3, outlining one peer with one wiring that has two links and calls one service (the depiction of service links is skipped in Fig. 3). The guard link connects the peer’s pic with the wirings’s wic, and the action link connects the wiring’s wic with the peer’s poc. Note that the source space container of a guard can also be the peer’s poc or the poc of a sub-peer. Analogously the target space container of an action link can also be the peer’s pic or the pic of a sub-peer. A wiring can have many links that are numbered with G$_1$, $\ldots$, G$_k$, S$_1$, $\ldots$, S$_m$, A$_1$, $\ldots$, A$_n$ (the link ids are not depicted in Fig. 3). A peer can have many wirings.

Sub-wirings that are called as synchronous sub-transactions [33] are denoted with dashed lines.

Fig. 3.

Example peer [33].

Fig. 4.

Time triggered protocol in general.

Appendix B: Excerpt from Railway Use Case Model

(See Fig. 5).

Fig. 5.

EndMoteA M$_1$ (left) and FwdMote M$_2$ (right) models (see Fig. 4).