A model of cooperative noninterference for integrated modular avionics

Vito, Ben L. Di

doi:10.1109/dcfts.1999.814300

Cited by 9 publications

(4 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To name a few areas of application, PVS has been used to verify interactive consistency algorithms that handle Byzantine faults (Lincoln & Rushby, 1993, 1994 and clock synchronization algorithms (Pfeifer et al, 1999). In aerospace, an area that is heavily regulated, PVS has been used for fault tolerance in aircraft control systems (RW, 1996;Dutertre & Stavridou, 1997;Di Vito, 1999), and manned and interplanetary spacecrafts (Di Di Vito & Roberts, 1996;Crow & Di Vito, 1998). To the best of our knowledge, no work attempts to use PVS's type system to capture unhandled faults or provide a partitioning of the fault space based on the fault tolerance mechanisms of the subsystems used.…”

Section: Related Workmentioning

confidence: 99%

Fault-tolerant functional reactive programming (extended version)

Perez¹,

Goodloe²

2020

J. Funct. Prog.

View full text Add to dashboard Cite

Highly critical application domains, like medicine and aerospace, require the use of strict design, implementation, and validation techniques. Functional languages have been used in these domains to develop synchronous dataflow programming languages for reactive systems. Causal stream functions and functional reactive programming (FRP) capture the essence of those languages in a way that is both elegant and robust. To guarantee that critical systems can operate under high stress over long periods of time, these applications require clear specifications of possible faults and hazards, and how they are being handled. Modeling failure is straightforward in functional languages, and many functional reactive abstractions incorporate support for failure or termination. However, handling unknown types of faults, and incorporating fault tolerance into FRP, requires a different construction and remains an open problem. This work demonstrates how to extend an existing functional reactive framework with fault tolerance features. At value level, we tag faulty signals with reliability and probability information and use random testing to inject faults and validate system properties encoded in temporal logic. At type level, we tag components with the kinds of faults they may exhibit and use type-level programming to obtain compile-time guarantees of key aspects of fault tolerance. Our approach is powerful enough to be used in systems with realistic complexity, and flexible enough to be used to guide system analysis and design, validate system properties in the presence of faults, perform runtime monitoring, and study the effects of different fault tolerance mechanisms.

show abstract

Section: Related Workmentioning

confidence: 99%

Fault-tolerant functional reactive programming (extended version)

Perez¹,

Goodloe²

2020

J. Funct. Prog.

View full text Add to dashboard Cite

show abstract

“…To name a few areas of application, PVS has been used to verify interactive consistency algorithms that handle Byzantine faults [Lincoln and Rushby [n. d.], 1993] and clock synchronization algorithms [Pfeifer et al 1999]. In aerospace, an area that is heavily regulated, PVS has been used for fault tolerance in aircraft control systems [Di Vito 1999;Dutertre and Stavridou 1997;RW 1996], and manned and interplanetary spacecrafts [Crow and Di Vito 1998;Di Vito 1996;DiVito and Roberts 1996]. To the best of our knowledge, no work attempts to use PVS's type system to capture unhandled faults or provide a partitioning of the fault space based on the fault tolerance mechanisms of the subsystems used.…”

Section: Ivan Perezmentioning

confidence: 99%

Fault tolerant functional reactive programming (functional pearl)

Perez

2018

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Highly critical application domains, like medicine and aerospace, require the use of strict design, implementation and validation techniques. Functional languages have been used in these domains to develop synchronous dataflow programming languages for reactive systems. Causal stream functions and Functional Reactive Programming capture the essence of those languages in a way that is both elegant and robust. To guarantee that critical systems can operate under high stress over long periods of time, these applications require clear specifications of possible faults and hazards, and how they are being handled. Modeling failure is straightforward in functional languages, and many Functional Reactive abstractions incorporate support for failure or termination. However, handling unknown types of faults, and incorporating fault tolerance into Functional Reactive Programming, requires a different construction and remains an open problem. This work presents extensions to an existing functional reactive abstraction to facilitate tagging reactive transformations with hazard tags or confidence levels. We present a prototype framework to quantify the reliability of a reactive construction, by means of numeric factors or probability distributions, and demonstrate how to aid the design of fault-tolerant systems, by constraining the allowed reliability to required boundaries. By applying type-level programming, we show that it is possible to improve static analysis and have compiletime guarantees of key aspects of fault tolerance. Our approach is powerful enough to be used in systems with realistic complexity, and flexible enough to be used to guide their analysis and design, to test system properties, to verify fault tolerance properties, to perform runtime monitoring, to implement fault tolerance during execution and to address faults during runtime. We present implementations in Haskell and in Idris. CCS Concepts: • Software and its engineering → Functional languages; • Hardware → Fault tolerance; • Theory of computation → Streaming models;

show abstract

“…NASA Langley Research Center presented a research (Di Vito, B.L.) 11 aimed at ensuring safe partitioning and logical noninterference among separate applications running on a shared Avionics Computer Resource (ACR).…”

Section: Literature Overviewmentioning

confidence: 99%