Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107-125, February 1995.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to the length of the sequence. This is achieved by the dependent sum where index sets (nat) set denotes the set of all downward closed subsets of nat. This approach has been taken by Devillers and Griffioen [DG97] who also formalized I O automata meta theory. It has been carried out in PVS [ORSH95] ffl HOL Sum: Sequences are defined as the disjoint sum of finite and infinite sequences: ff) sequence = FinSeq( ff) list) j InfSeq(nat ff) This approach has been taken by Chou and Peled [CP96] in the verification of a partial order reduction technique for model checking and by Agerholm ....

....of HD and TL. A single axiom postulates that every function f on sequences is uniquely determined by the outputs of f successively observed by next. This coalgebraic approach has been taken by Hensel and Jacobs [HJ97a] based on the principles presented in [HJ97b] It has been carried out in PVS [ORSH95] Further coalgebraic sequence formalizations have been performed by Paulson [Pau97] in Isabelle HOL and by Leclerc and Paulin Mohring [LPM93] in Coq [DFH 93] ffl HOL LCF: In domain theory, sequences can be defined by the recursive domain equation (ff) sequence = nil j (ff) # (ff) sequence ....

[Article contains additional citation context not shown here]

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....patterns, inspired from Bandera [1] that allows higherlevel specifications and reasoning; a compositional proof system in the style of [16, 7, 9] that is used for proving correctness of property decompositions. This proof system has been proved sound w.r.t. the underlying model in PVS [15]. To illustrate the benefits of our method, we also detail an example of property decomposition in the setting of an industrial smartcard case study [3] Contents The remainder of the paper is organized as follows. The model, specification language and proof system are introduced in Sections 2, ....

....) A2 : active intersect(A1 ; A2 ) A1 : active; Delta Gamma; wf(A1) wf(A2 ) intersect(A1 ; A2 ) A1 : active; A2 : active; Delta Gamma; wf(A1 j A2 ) Delta Soundness. The program model has been formalized and the proof rules have been proven sound w.r.t. the underlying model in PVS [15]. 11 6 Example: Electronic Purse To illustrate the working of the proof system, we take the electronic purse smartcard example of [3] which we discussed in greater detail (by providing the program model) in [2] and we outline the correctness proof of the decomposition of its specification. In ....

S. Owre, J. Rushby, N. Shankar, and F von Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, 1995.

....with relational operators, and uses Alloy s SAT solver based automatic analysis technique to check Java programs. LOOP [10] is a project dedicated to verify JavaCard programs. LOOP adopts JML as its BISL for annotating Java modules and transforms annotated Java programs into a theorem prover, PVS [20], to formally verify JavaCard programs. Although the languages mentioned above can be used to specify programs written in various programming languages, they are not designed to specify programs written in AOP languages such as AspectJ. In summary, Pipa is the first BISL tailored to AspectJ that ....

S. Owre, J. M. Rushby, N. Shankar, and F. von Henke. Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering, Vol.21, No.2, pp.107-125, February 1995.

....uses it to prove an unrelated theorem, then he or she deserves the unpleasant fate that awaits. We suspect that the dangers of informal decision procedures would be more serious in a more powerful deductive framework such as Nqthm ACL2 [11] or the tightly integrated decision procedures of PVS [36] where complicated chains of inference can be performed without specific direction from the user. We are not arguing against the benefits of more powerful theorem provers; we simply note that the integration of new decision procedures can be more difficult when working with sophisticated theorem ....

S. Owre, J. Rushby, et al. Formal verification for fault tolerant architectures: Prolegomena to the design of pvs. IEEE Transactions on Software Engineering, 21(2):107-- 125, February 1995.

....that is TRUE when the input predicate dataflow is TRUE for the duration of the timeout. It is used at the requirements level to specify the real time behaviour of controllers in our setting. The definitions are implemented as reusable theories for SRI International s automated proof assistant PVS [1]. These definitions, when combined with PVS s support for the tabular methods [3] of Parnas et al. 4, 5] provide a useful environment for the specification and verification of basic real time control properties. We illustrate the use of PVS by formally specify and verify the real time behaviour ....

S. Owre, J. Rushby, N. Shankar, and F. von Henke, "Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS," IEEE Transactions on Software Engineering, vol. 21, pp. 107--125, Feb. 1995.

....address either one of these two activities independently, but not both. Several formal techniques have been developed for analysing requirements specifications, such as those based on theorem proving or model checking, and declarative logic based approaches. Techniques based on theorem proving [36] might not be decidable, thus not always terminating. On the other hand, techniques based on model checking facilitate automated analysis and generation of counter examples, when errors are detected [3, 19] They provide as counter examples long traces of system executions. In contrast, our ....

S. Owre et al. Formal verification for fault-tolerant architecture: Prolegomena to the design of pvs. IEEE Transactions on Sofwtare Engineering, 21(2):107-125, 1995.

....verification to disregard these differences and interpret al..l of these types as the unbounded, mathematical integers. This same approach has been followed until recently within the Java verification technology developed in Nijmegen around the LOOP translation tool [1] and the PVS theorem prover [12]. During the last few years the main application area for the LOOP tool is Java Card based smart cards. Within this setting the abovementioned abstraction of integral types is problematic, because of the following reasons. Given the limited resources on a smart card, a programmer chooses ....

S. Owre, J.M. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Trans. on Softw. Eng., 21(2):107-- 125, 1995.

....is given elsewhere in the specifications. However, this feature can only result in overly robust, rather then incorrect, specifications. If desired we can reapply the abductive procedure, with information about the initial state and a full time structure, to test for reachability. Theorem proving [24] provides an alternative way of analysing requirements specifications, even for infinite state systems. However, in contrast to our approach this does not provide useful diagnostic information when a verification fails, and computations may not always terminate. 5] uses a hybrid approach based on ....

Owre, S, et al. (1995). Formal verification for fault-tolerant architecture: Prolegomena to the design of PVS. IEEE Transactions on S.E, 21(2): 107-125.

....be sent if no failures had occurred. Step 3 above is to check whether a system in the presence of failures satisfies some requirements. Experience has shown that informal arguments here tend to be error prone and thus do not supply the desired level of assurance for mission critical systems [ORSvH95]. For example, although replication and voting might seem easy to justify informally, the extensive literature on Byzantine agreement protocols and errors like the one described in [LR93] suggest that e#cient coordination of non faulty replicas in the presence of arbitrary behavior by faulty ....

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....analysis method. Automated analysis methods address an important need, because informal arguments do not supply the desired level of assurance for critical systems, and practitioners often lack the background needed to construct the formal proofs required by proof based methods, such as those in [ORSvH95,CdR93,PJ94,JJ96,Sch96]. Automated verification techniques based on exhaustive exploration of finite statespaces [CGL94,Hol91,Kur94,CS96] have made great progress in the last decade. But relatively little work has been done on automated verification of faulttolerant software systems, partly because exhaustive search of ....

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....addresses the primary difficulty with using theorem proving for verification of real systems, which is the amount of human effort required to complete a proof, by making it easier to create appropriate abstraction functions. Although our work is based on using the PVS system from SRI International [33], the method is useful with other mechanical theorem provers, or manual proofs. Although finite state methods (e.g. 32] 10] 17] and [19] can solve many of the same problems with even less effort, they are basically limited to finite state protocols. Finite state methods have been applied ....

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....procedures is a challenging research issues in automated reasoning. Work on little engines of proof has been gathering steam lately Many groups are actively engaged in the construction of little proof engines, while others are putting in place the train tracks on which these engines can run. PVS [ORSvH95] itself can be seen as an attempt to unify many di#erent inference procedures: typechecking, ground decision procedures, simplification, rewriting, MONA [EKM98] model checking [CGP99] abstraction, and static analysis, within a single system with an expressive language for writing mathematics. 2 ....

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....interval clocks, rounds and faulty processing nodes are common to both types of algorithms and are needed in either formalization, whereas other concepts like triggering events or convergence functions are specific to one class of algorithms. This led to the development of a general theory in PVS [5, 4, 3] of clock synchronization algorithms that does not depend on the existence of an averaging function or triggering events and thus covers both averaging and non averaging algorithms. The parameters of the general theory are upper and lower bounds for the length of rounds and clock adjustments. ....

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal Verification for FaultTolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....performance. We describe the design choices underlying ICS and the capabilities it provides. 1 Introduction Formal deduction that is, automated theorem proving lies at the heart of all tools for formal analysis of software and system descriptions. In formal verification systems such as PVS [10], the deductive capability is explicit and visible to the user, whereas in tools such as test case generators it is hidden and often ad hoc. We believe that all tools for formal analysis would benefit both in performance and ease of construction if they could draw on a powerful embedded ....

....that is effective; we do not intend to extend ICS to a general theorem prover. However, just as our original decision procedures made it possible for PVS (and its NSA sponsored predecessor EHDM) to have a different architecture and style of interaction than previous interactive theorem provers [10], so the increased capability of ICS will allow future systems to support new and more productive styles of human interaction. We intend to explore these opportunities in our research with future versions of PVS, and to assist NSA to do the same with its own systems. ICS is freely available for ....

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

....in formal specification is the choice of system model. Here, the algorithm involves time in an essential way, and the most realistic system model will be one in which time is treated as a continuous variable. Timed automata [AD94] might therefore be a suitable model; these can be encoded in PVS [ORSvH95] and formally verified by hand or with the aid of specialized libraries and strategies such as those of TAME [Arc00] or we could use a model checker for timed automata such as Kronos [BDM 98] or UP PAAL [LPY97] or an experimental encoding in SAL ICS [dMRS] Lonn [Lon99a,Lon99b] considers ....

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107-125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rusby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of pvs. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Owre, S.; Rusby, J.; Shankar, N.; and von Henke, F.: Formal Verification for FaultTolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering , vol. 21, no. 2, February 1995, pp. 107--125.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS. IEEE Transactions on Software Engineering, 21(2), pages 107--125, Feb. 1995. 14

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, Feb. 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich ZSPLITZvon Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--25, February 1995. 2

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich ZSPLITZvon Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--25, February 1995. 2

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich ZSPLITZvon Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--25, February 1995. 2

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE TSE, 21(2):107--125, February 1995. Special Section---Best Papers of FME (Formal Methods Europe) '93.

No context found.

Owre, S., Rushby, J., Shankar, N. and von Henke, F. (1995) Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2), 107--125.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F.V. Henke. Formal Verification for Fault-tolerant Architectures: Prolegomena to the design of PVS. IEEE Transactions On Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal Verification for Fault-Tolerant Architectures: Prolegomena to the Design of PVS. IEEE Trans. on Software Engineering, 21(2):107--125, February 1995.

No context found.

S. Owre, J. Rushby, Shankar N., and F. von Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Trans. on Software Engineering, 21(2):107--125, 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Owre, S., Rushby, J., Shankar, N., and Henke, F. v. (1995). Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2).

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, Feb. 1995.

No context found.

S. Owre, J.M. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE TSE, 21(2):107--125, February 1995. Special Section---Best Papers of FME (Formal Methods Europe) '93.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, Feb. 1995.

No context found.

Sam Owre, John Rushby, Natarajan Shankar, and Friedrich von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107-- 125, February 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, 1995.

No context found.

S. Owre, J. Rushby, Shankar N., and F. von Henke. Formal verification for faulttolerant architectures: Prolegomena to the design of PVS. IEEE Trans. on Software Engineering, 21(2):107--125, 1995.

No context found.

S. Owre, J. Rushby, N. Shankar, and F. von Henke. Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS. IEEE Transactions on Software Engineering, 21(2):107--125, February 1995.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC