Specification: The Biggest Bottleneck in Formal Methods and Autonomy

Rozier, Kristin Yvonne

doi:10.1007/978-3-319-48869-1_2

Cited by 53 publications

(48 citation statements)

References 46 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Last, we should keep in mind that specifications, even if they produce formally equivalent models which can be fed to V&V tools, needs to correctly capture the intents of the system designer. As pointed by [Rozier, 2016] "there is no escaping the 'garbage in, garbage out' reality". For this problem, we think that for now, we should rely on good old testing of the system as to check that specifications are correct and synthesize the proper formal model.…”

Section: Conclusion and Prospectivesmentioning

confidence: 99%

Recent Trends in Formal Validation and Verification of Autonomous Robots Software

Ingrand

2019

2019 Third IEEE International Conference on Robotic Computing (IRC)

View full text Add to dashboard Cite

The consequences of autonomous systems software failures can be potentially dramatic. There is no need to darken the picture, but still, it seems unlikely that people, insurance companies and certification agencies will let autonomous systems fly or drive around without requiring their makers and programmers to prove that the most critical parts of the software are robust and reliable. This is already the case for aeronautic, rail transportation, nuclear plants, medical devices, etc. were software must be certified, which possibly involve its formal validation and verification (V&V). Moreover, autonomous systems go further and embed onboard deliberation functions. This is what make them really autonomous, but open new challenges. We propose to consider the overall problem of V&V of autonomous systems software and examine the current situation with respect to the various type of software used. In particular, we point out that the availability of formal models is rather different depending on the type of component considered. We distinguish these different cases and stress the areas where we think we need to focus our efforts as to improve the overall robustness of autonomous systems.

show abstract

Section: Conclusion and Prospectivesmentioning

confidence: 99%

Recent Trends in Formal Validation and Verification of Autonomous Robots Software

Ingrand

2019

2019 Third IEEE International Conference on Robotic Computing (IRC)

View full text Add to dashboard Cite

show abstract

“…We also critically need an MLTL satisfiability checker to enable specification debugging. Specification is a major bottleneck to the formal verification of mission-based, especially autonomous, systems [35], with a key part of the problem being the availability of good tools for specification debugging. Satisfiability checking is an integral tool for specification debugging: [38,39] argued that for every requirement ϕ we need to check ϕ and ¬ϕ for satisfiability; we also need to check the conjunction of all requirements to ensure that they can all be true of the same system at the same time.…”

Section: Introductionmentioning

confidence: 99%

Satisfiability Checking for Mission-Time LTL

Vardi

Rozier

2019

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Mission-time LTL (MLTL) is a bounded variant of MTL over naturals designed to generically specify requirements for mission-based system operation common to aircraft, spacecraft, vehicles, and robots. Despite the utility of MLTL as a specification logic, major gaps remain in analyzing MLTL, e.g., for specification debugging or model checking, centering on the absence of any complete MLTL satisfiability checker. We prove that the MLTL satisfiability checking problem is NEXPTIME-complete and that satisfiability checking MLTL0, the variant of MLTL where all intervals start at 0, is PSPACE-complete. We introduce translations for MLTL-to-LTL, MLTL-to-LTL f , MLTL-to-SMV, and MLTL-to-SMT, creating four options for MLTL satisfiability checking. Our extensive experimental evaluation shows that the MLTL-to-SMT transition with the Z3 SMT solver offers the most scalable performance.

show abstract

“…From the manual, we know that there are five possible faults that can occur. We read the relevant sensor data from the fluxgate magnetometer and other on-board sensors useful in cross-checking it from Figure 2: R2U2 configurations are sets of observation trees, like this one [23]. The possible failures a fluxgate magnetometer can suffer can be diagnosed by a Bayes Net with a health node corresponding to each type of failure.…”

Section: Key Features Of R2u2mentioning

confidence: 99%

“…In industrial systems, languages and formats for specification vary widely and are often tailored to specific applications. The question of how best to encapsulate specifications from real systems is an ongoing research question [23]. R2U2's Realizability requirement encapsulates the need for specifications that are cross-language, hierarchical, compositional, and extensible.…”

Section: Key Features Of R2u2mentioning

confidence: 99%

See 1 more Smart Citation

R2U2: Tool Overview

Rozier

Schumann

Kalpa Publications in Computing

Self Cite

View full text Add to dashboard Cite

R2U2 (Realizable, Responsive, Unobtrusive Unit) is an extensible framework for runtime System Health Management (SHM) of cyber-physical systems. R2U2 can be run in hardware (e.g., FPGAs), or software; can monitor hardware, software, or a combination of the two; and can analyze a range of different types of system requirements during runtime. An R2U2 requirement is specified utilizing a hierarchical combination of building blocks: temporal formula runtime observers (in LTL or MTL), Bayesian networks, sensor filters, and Boolean testers. Importantly, the framework is extensible; it is designed to enable definitions of new building blocks in combination with the core structure. Originally deployed on Unmanned Aerial Systems (UAS), R2U2 is designed to run on a wide range of embedded platforms, from autonomous systems like rovers, satellites, and robots, to human-assistive ground systems and cockpits.R2U2 is named after the requirements it satisfies; while the exact requirements vary by platform and mission, the ability to formally reason about Realizability, Responsiveness, and Unobtrusiveness is necessary for flight certifiability, safety-critical system assurance, and achievement of technology readiness levels for target systems. Realizability ensures that R2U2 is sufficiently expressive to encapsulate meaningful runtime requirements while maintaining adaptability to run on different platforms, transition between different mission stages, and update quickly between missions. Responsiveness entails continuously monitoring the system under test, real-time reasoning, reporting intermediate status, and as-early-as-possible requirements evaluations. Unobtrusiveness ensures compliance with the crucial properties of the target architecture:

show abstract

Specification: The Biggest Bottleneck in Formal Methods and Autonomy

Cited by 53 publications

References 46 publications

Recent Trends in Formal Validation and Verification of Autonomous Robots Software

Recent Trends in Formal Validation and Verification of Autonomous Robots Software

Satisfiability Checking for Mission-Time LTL

R2U2: Tool Overview

Contact Info

Product

Resources

About