# Towards Realizability Checking of Contracts using Theories

## Abstract

Virtual integration techniques focus on building architectural models of systems that can be analyzed early in the design cycle to try to lower cost, reduce risk, and improve quality of complex embedded systems. Given appropriate architectural descriptions and compositional reasoning rules, these techniques can be used to prove important safety properties about the architecture prior to system construction. Such proofs build from “leaf-level” assume/guarantee component contracts through architectural layers towards top-level safety properties. The proofs are built upon the premise that each leaf-level component contract is realizable; i.e., it is possible to construct a component such that for any input allowed by the contract assumptions, there is some output value that the component can produce that satisfies the contract guarantees. Without engineering support it is all too easy to write leaf-level components that can’t be realized. Realizability checking for propositional contracts has been well-studied for many years, both for component synthesis and checking correctness of temporal logic requirements. However, checking realizability for contracts involving infinite theories is still an open problem. In this paper, we describe a new approach for checking realizability of contracts involving theories and demonstrate its usefulness on several examples.

## 1 Introduction

In the recent years, virtual integration approaches have been proposed as a means to lower cost and improve quality of complex embedded systems. These approaches focus on building architectural models of systems that can be analyzed prior to construction of component implementations. The objective is to discover and resolve problems early during the design and implementation phases when cost impact is lower. Several architecture description languages such as AADL [SAE:AADL], SysML [Friedenthal08:sysml], and AUTOSAR [AUTOSAR] are designed to support such an engineering process, and there has been significant effort to analytically determine system performance [Gomez11:AADL, Bozzano:2011:AADL], fault tolerance [Bozzano:2011:AADL], security [Apvrille13:security], and safety [Bozzano14:AADL] using these techniques.

In an ongoing effort at Rockwell Collins and The University of Minnesota, we have been pursuing virtual integration using compositional proofs of correctness. The idea is to support hierarchical design and analysis of complex system architectures and co-evolution of requirements and architectures at multiple levels of abstraction [Whalen13:WhatHow:TwinPeaksIEEESoftware]. This was based on two observations about software development for commercial aircraft: first, that component-level errors are relatively rare and that most problems occur during integration [rushby2011new], and second, that requirements specifications often contain significant numbers of omissions or errors [Miller06:Shalls] that are at the root of many of the integration problems. Specifically, the problem involves demonstrating satisfaction arguments [Hammond01:WiW], i.e., that the requirements allocated to components and the architecture connecting those components is sufficient to guarantee the system requirements. We have created the AGREE reasoning framework [NFM2012:CoGaMiWhLaLu] to support compositional assume/guarantee contract reasoning over system architectural models written in AADL.

Such proof systems build from “leaf-level” assume/guarantee component contracts through architectural layers towards proofs of top-level safety properties. The soundness of the argument is built upon the premise that each leaf-level component contract is realizable; i.e., it is possible to construct a component such that for any input allowed by the contract assumptions, there is some output value that the component can produce that satisfies the contract guarantees.

Unfortunately, without engineering support it is all too easy to write leaf-level components that can’t be realized. When applying our tools in both industrial and classroom settings, this issue has led to incorrect compositional “proofs” of systems; in fact the goal of producing a compositional proof can lead to engineers modifying component-level requirements such that they are no longer possible to implement. In order to make our virtual integration approach reasonable for practicing engineers, tool support must be provided to check whether components are realizable.

Realizability checking for propositional contracts has been well-studied for many years (e.g., [Pnueli89, Bohy12, Hamza10, Chatterjee07]), both for component synthesis and checking correctness of temporal logic requirements. Checking realizability for contracts involving theories, on the other hand, is still an open problem. In this paper, we describe a new approach for checking realizability of contracts involving theories and demonstrate its usefulness on several examples. Our approach is similar to k-induction over quantified formulas. We describe two algorithms. The first is sound for both proofs and counterexamples, but computationally intractable. The second algorithm is not sound for counterexamples (i.e., it may return a ‘false counterexample’ to a problem that is in fact realizable), but we have found it fast and accurate in practice.

The rest of the paper is structured as follows. In Section 2 we will describe our motivation and an example to illustrate realizability, and will define realizability formally in Section 3. We next describe two algorithms for checking realizability in Section 4, our implementation in the AGREE tool suite in Section 5, and our experience using the realizability check in Section 6. Section LABEL:sec:related_work describes related work and Section LABEL:sec:future_work concludes.

## 2 Motivation and Example

We have been pursuing a proof-based virtual integration approach for building complex systems using the architecture description language AADL [SAE:AADL] and the AGREE compositional reasoning system [NFM2012:CoGaMiWhLaLu]. We have demonstrated the effectiveness of the approach on a variety of industrial-scale systems, including the software controller for a patient-controlled analgesia (PCA) infusion pump [hilt2013], a dual flight-guidance system [NFM2012:CoGaMiWhLaLu], and several more recent models, such as a quad-redundant flight control system and a quadcopter control system. We are using this approach on the DARPA HACMS program to build secure vehicles and to demonstrate how to apply virtual integration on industrial scale systems to facilitate technology transfer.

As part of the HACMS project, we attempted a feasibility test via a classroom exercise. We used the AADL and AGREE tools in a class assignment in a graduate-level software architecture class. The students were organized into six teams of four students. Each team was asked to specify the control software for a simplified microwave oven in AADL using a virtual integration approach. The software was split into two subsystems: one for controlling the heating element and another for controlling the display panel, with several requirements for each subsystem. The goal was to formalize these component-level requirements and use them to prove three system-level safety requirements.

The results of the initial experiment were sobering. All student groups were
able to prove the system-level requirements starting from formalizations of the component requirements. Unfortunately, in many cases, the proofs succeeded because the components were incorrectly specified. In fact, only one of the teams had written component-level requirements that could be implemented. The other teams had requirements which were inconsistent under certain input conditions. For example, one team produced the following informal component-level requirements:
{mdframed}[roundcorner=10pt,backgroundcolor=gray!20]
Microwave-1 - While the microwave is in cooking mode,
seconds_to_cook shall decrease.
{mdframed}[roundcorner=10pt,backgroundcolor=gray!20]
Microwave-2 - If the display is quiescent (no buttons pressed) and the
keypad is enabled, the seconds_to_cook shall not change.
and then produced the following formalized
requirements^{1}

These formalized guarantees fail to avoid the conflict in the seconds_to_cook variable between the Microwave-1 and Microwave-2 requirements, as they cannot be both satisfied in a case where the microwave is cooking and the keypad is enabled. This error was not caught despite an analysis built into an early version of AGREE that checks contracts for consistency, i.e., whether the conjunction of a system’s guarantees is satisfiable. We realized that consistency checking does not actually provide a trustworthy answer because it only checks whether the system works in some external environment, not in all environments. Realizability checking determines whether or not the component works in all input environments that satisfy the component assumptions.

From this experience, we decided that realizability checking was necessary for successful tech transfer of a virtual integration approach. The analysis was not only necessary for classroom settings. We also found problems with component-level requirements in two of our large-scale analysis efforts. Further, existing approaches for checking realizability do not allow predicates over infinite theories such as integers and reals, which are native to our AGREE contracts.

In the following sections, we formally define realizability over transition systems, as well as algorithms for checking realizability over infinite-state systems that are efficient and accurate in practice. A machine-checked formalization of the definitions and proofs in Coq can be found in a companion paper [Katis:machine].

## 3 Realizability

We assume the types and for states and inputs. We use for variables of type and for variables of type . State represents both internal state and external outputs. A transition system is a pair where holds on the initial states states and holds on when the system can transition from state to state on receipt of input . We assume the usual notion of path with respect to a transition relation.

A contract specifies the desired behavior of a transition system. A contract is a pair of an assumption and a guarantee. The assumption specifies for a given system state which inputs are valid. The guarantee is a pair of an initial guarantee and a transitional guarantee. The initial guarantee specifies which states the system may start in, that is, the possible initial internal state and external outputs. The transitional guarantee specifies for a given state and input what states the system may transition to.

We now define what it means for a transition system to realize a contract. This requires that the system respects the guarantee for inputs which satisfying the contract. Moreover, the system must always remain responsive with respect to inputs that satisfying the assumptions. In order to make this definition precise, we first need to define which system states are reachable given some assumptions on the system inputs.

###### Definition 1 (Reachable with respect to assumptions)

Let be a transition system and let be an assumption. A state of is reachable with respect to if there exists a path starting in an initial state and eventually reaching such that all transitions satisfying the assumptions. Formally, is defined inductively by

###### Definition 2 (Realization)

A transition system is a realization of the contract when the following conditions hold

The first two conditions in Definition 2 ensure that the transition system respects the guarantees. The second two conditions ensure that the system is non-trivial and responsive to all valid inputs.

###### Definition 3 (Realizable)

A contract is realizable if there exists a transition system which is a realization of the contract.

Definitions 2 and 3 are useful for directly defining realizability, but not very useful for checking realizability. We now develop an equivalent notion which is more suggestive and amenable to checking. This is based on a notion called viability. Intuitively, a state is viable with respect to a contract if being in that state does not doom a realization to failure. We can capture this notion without reference to any specific realization, because condition 2 in the definition of realization tells us that is an over-approximation of any .

###### Definition 4 (Viable)

A state is viable with respect to a contract , written , if can keep responding to valid inputs forever, starting from . Informally, one can say that a state is viable if it satisfies the infinite formula:

Formally, viability is defined coinductively by the following equation

###### Theorem 3.1 (Alternative realizability)

A contract is realizable if and only if .

###### Proof

For the “only if” direction the key lemma is . This lemma is proved by coinduction and follows directly from conditions 2 and 4 of Definition 2. Then by conditions 1 and 3 we have some state such that and . Thus holds and applying the lemma we get .

For the “if” direction, let be such that and . Define and . Conditions 1, 2, and 3 of Definition 2 are clearly satisfied. Condition 4 follows from the observation that and from the definition of viability.

## 4 An Algorithm for Checking Realizability

In this section we develop two versions of an algorithm for automatically checking the realizability of a contract. The first version is based on Theorem 3.1 together with under- and over-approximations of viability. An over-approximation is useful to show that a contract is not viable, while an under-approximation is useful to show that a contract is viable. The second version of the algorithm follows from the mitigating the intractability of the first version.

We first define an over-approximation of viability called finite viability based on a finite unrolling of the definition of viability. Because this is an over-approximation, if a contract does not have an initial state which is finitely viable, then the contract is not viable. We formalize this when we prove the correctness of the realizability algorithm.

###### Definition 5 (Finite viability)

A state is viable for steps, written if can keep responding to valid inputs for at least steps. That is,

All states are viable for 0 steps.

We next define an under-approximation of viability based on one-step extension. This notion looks if can respond to valid inputs given a finite historical trace of valid inputs and states.

###### Definition 6 (One-step extension)

A state is extendable after steps, written , if any valid path of length from can be extended in response to any input. That is,

We now use these two notions to formally define our realizability algorithm. The core of the algorithm is based on two checks called the base and extend check.

###### Definition 7 (Realizability Algorithm)

Define the checks:

The following algorithm checks for realizability or unrealizability of a contract.

###### Theorem 4.1 (Soundness of “unrealizable” result)

If then the contract is not realizable.

###### Proof

First we show by induction on . The result then follows from Theorem 3.1.

###### Theorem 4.2 (Soundness of “realizable” result)

If then contract is realizable.

###### Proof

First we show how can be used to shift forward. The following is proved by induction on .

Using this lemma we can show the following by coinduction.

The result then follows from Theorem 3.1.

###### Corollary 1 (Soundness of Realizability Algorithm)

The Realizability Algorithm is sound.

Due to the approximations used to define the base and extends check, the algorithm is incomplete. The following two examples show how both realizable and unrealizable contracts may send the algorithm into an infinite loop.

###### Example 1 (Incompleteness of “realizable” result)

Suppose the type is integers. Consider the contract:

This contract is realizable by, for example, a system that starts in state and always transitions into the same state. Yet, for all , fails since one can take a path of length which ends at state . This path cannot be extended.

###### Example 2 (Incompleteness of “unrealizable” result)

Suppose the type is integers. Consider the contract:

This contract is not realizable since in any realization the state would be reachable, but the contract does not allow a transition from state . However, holds for all by starting in state .

Implementing this algorithm requires a way of automatically checking the formulas and for validity. This can be done in an SMT-solver that supports quantifiers over the language the contract is expressed in. Checking is rather nice in this setting since it has only a single quantifier alternation. Moreover, using an incremental SMT-solver one can reuse much of the work done to check to also check . However, is problematic. First, it has quantifier alternations which puts even small cases outside the reach of modern SMT-solvers. Second, the quantifiers make it impractical to reuse the results of in checking . Finally, due to the quantifiers, a counterexample to would be difficult to relay back to the user. Thus we need a simplification of in order to make our algorithm practical.

###### Definition 8 (Simplified base check)

Define a simplified base check which checks that any path of length from an initial state can be extended one step.

First, note that this check has a single quantifier alternation. Second, this check can leverage the incremental features in an SMT-solver to use the results of in checking . Finally, when this check fails it can return a counterexample which is a trace of a system realizing the contract for steps, but then becoming stuck. This provides very concrete and useful feedback to system developers. The correctness of this check is captured by the following theorem.

###### Theorem 4.3 (One-way soundness of simplified base check)

###### Proof

We first prove the following by induction on :

The final result follows using this and induction on .

Thus replacing in the realizability algorithm with preserves soundness of the “realizability” result. However, because the implication in Theorem 4.3 is only in one direction, the algorithm is no longer sound for the “unrealizable” result. That is, it may return a counterexample showing steps of a realization of the contract that gets into a stuck state. The following example makes this point explicit.

###### Example 3

Consider again Example 1 where the type is integers and the contract is:

As before, this contract is easily realizable. However, fails for all since it will consider a path starting at state and transitioning steps to state where no more transitions are possible.

The benefits of this second version of the algorithm outweigh its costs. The cases where a contract is realizable, yet fails the modified base check seems unlikely in practice. We have encountered none in our case studies. Moreover, when a contract does spuriously fail the simplified base check, it can almost always be rewritten into a form which would pass.

## 5 Implementation

We have built an implementation of the realizability algorithm as an extension to JKind [jkind], a re-implementation of the KIND model checker [Hagen08:kind] in Java. Our tool is called JRealizability and is packaged with the latest release of JKind. The model’s behavior is described in the Lustre language, which is the native input language of JKind and is used as an intermediate language for the AGREE tool suite.

We unroll the transition relation defined by the Lustre model into SMT problems (one for the base check and another for the extend check) which can be solved in parallel. We use the SMT-LIB Version 2 format which most modern SMT solvers support. The most significant issue for SMT solvers involves quantifier support, so we use the Z3 SMT solver [DeMoura08:z3] which has good support for reasoning over quantifiers and incremental search. The tool is often able to provide an answer for models containing integer and real-valued variables very quickly (in less than a second). Because of the use of quantifiers over a range of theories, it is possible that for one of the checks, Z3 returns unknown; in this case, we discontinue analysis. In addition, because our realizability check is incomplete, the tool terminates analysis when either a timeout or a user-specified max unrolling depth (default: 200) is reached. In this case we are able to report how far the base check reached which may provide some confidence in the realizability of the system.

## 6 Case Studies

As a part of testing the algorithm in actual components, we examined three different cases: a quad-redundant flight control system, a medical infusion pump, and a simple microwave controller. In this section, we provide a brief description of each case study and summarize the results in Table LABEL:table:case-studies at the end of the section.

### 6.1 Quad-Redundant Flight Control System

We ran our realizability analysis on a Quad-Redundant Flight Control System (QFCS) for NASA’s Transport Class Model (TCM) aircraft simulation. We were provided with a set of English language requirements for the QFCS components and a description of the architecture. We modeled the architecture in AADL and the component requirements as assume/guarantee contracts in AGREE. As the name suggests, the QFCS consists of four redundant Flight Control Computers (FCCs). Each FCC contains components for handling faults and computing actuator signal values. One of these components is the Output Signal Analysis and Selection component (OSAS). The OSAS component is responsible for determining the output gain for signals coming from the control laws and going to the actuators. The output signal gain is determined based on the number of other faulty FCCs or based on failures within the FCC containing the OSAS component. The OSAS component contains 17 English language requirements including the following: {mdframed}[roundcorner=10pt,backgroundcolor=gray!20] OSAS-S-170 – If the local Cross Channel Data Link (CCDL) has failed, OSAS shall set the local actuator command gain to 1 (one). {mdframed}[roundcorner=10pt,backgroundcolor=gray!20] OSAS-S-240 – If OSAS has been declared failed by CCDL, OSAS shall set the actuator command gain to 0 (zero). We formalized these requirements using the following guarantees:

These guarantees are contradictory in the case when the local CCDL has failed and the local CCDL reports to the OSAS that the OSAS has failed. This error eluded the engineers who originally drafted the requirements as well as the engineers who formalized them. In this case, there should be an assumption that if the CCDL has failed then it will not report to the OSAS that the OSAS has failed. This was not part of the original requirements. However, AGREE’s realizability analysis was able to identify the error and provide a counterexample.

### 6.2 Medical Device Example

Our realizability tool was also used to verify the realizability of the components in the Generic Patient Controlled Analgesia infusion pump system that was described in [Murugesan2014]. The controller consists of six subcomponents that were given as input for the tool to verify the requirements described inside. While five of the models were proven to be realizable, a subtly incorrect requirement definition was found in the contract for the controller’s infusion manager.

[roundcorner=10pt,backgroundcolor=gray!20] GPCA-1 - The mode range of the controller shall be one of nine different modes. If the controller is in one of the first two modes the commanded flow rate shall be zero.

(1) | ||||

[roundcorner=10pt,backgroundcolor=gray!20] GPCA-2 - Whenever the alarm subsystem has detected a high severity hazard, then Infusion Manager shall never infuse drug at a rate more than the specified Keep Vein Open rate.

(2) | ||||

### Footnotes

- We have translated this property and others from the higher level AGREE syntax into a two-state form that is used throughout this paper.