Verifying AI Plan Models Even the best laid plans need to be verified Margaret Smith – PI Gordon Cucullu Gerard Holzmann Benjamin Smith Prepared for the.

Slides:



Advertisements
Similar presentations
Abstraction and Modular Reasoning for the Verification of Software Corina Pasareanu NASA Ames Research Center.
Advertisements

Chpter#5 -part#1 Project Scope and Human Resource Planning
May 2, May 2, 2015May 2, 2015May 2, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa, CA.
WPI CS534 Showcase Jeff Martin. * Computer Software on Deep Space 1 * Used to execute plans/mission objectives * Model based * Constraint based * Fault.
Inspection (c) 2007 Mauro Pezzè & Michal Young Ch 18, slide 1 Photo credit jurvetson on Flickr.com; creative commons attribution license.
The Marketing Research Process
Unit 211 Requirements Phase The objective of this section is to introduce software system requirements and to explain different ways of expressing these.
The Model Checker SPIN Written by Gerard J. Holzmann Presented by Chris Jensen.
Formal verification Marco A. Peña Universitat Politècnica de Catalunya.
SOFTWARE PROJECT MANAGEMENT Project Quality Management Dr. Ahmet TÜMAY, PMP.
Software Process and Product Metrics
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Automation for System Safety Analysis: Executive Briefing Jane T. Malin, Principal Investigator Project: Automated Tool and Method for System Safety Analysis.
System Testing There are several steps in testing the system: –Function testing –Performance testing –Acceptance testing –Installation testing.
S/W Project Management
Artificial Intelligence CIS 479/579 Bruce R. Maxim UM-Dearborn.
Why use RequisitePro RequisitePro is a comprehensive tool that supports any of today's requirements management processes. The predominant requirements.
Applying the Inspection Process. What Software Artifacts Are Candidates for Inspection? Software Requirements Software Designs Code Test Plans.
S oftware Q uality A ssurance Part One Reviews and Inspections.
Chapter 4 The Project. 2 Learning Objectives Third phase starts after a contract is drawn up and ends when the project objective is accomplished; final.
Writing Quality Requirements Karl E. Wiegers Presented by: Ricardo Carlos.
Requirements Engineering CSE-305 Requirements Engineering Process Tasks Lecture-5.
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
1 5.1 Software Engineering Practice  Provide value to the user  KIS—keep it simple!  Maintain the product and project “vision”  What you produce,
Process Improvement. Improving the Test Process In the Software V&V course, Prof. Uwe asked the question: How to improve the Testing Process?
1 Requirements Management - General concepts - Noureddine Abbadeni King Saud University College of Computer and Information Sciences Based on “Software.
California Institute of Technology Requirements Decomposition Analysis, Model Based Testing of Sequential Code Properties Allen P. Nikora, John D. Powell.
Verifying Autonomous Planning Systems Even the best laid plans need to be verified Prepared for the 2005 Software Assurance Symposium (SAS) DS1 MSL EO1.
Test Drivers and Stubs More Unit Testing Test Drivers and Stubs CEN 5076 Class 11 – 11/14.
Formal Methods in Software Engineering
Fault-Tolerant Parallel and Distributed Computing for Software Engineering Undergraduates Ali Ebnenasir and Jean Mayo {aebnenas, Department.
Validating Requirements Determining Completeness and Correctness of Requirements Using the System Reference Model IV&V Workshop 16 September 2009.
Reviews and Inspections. Types of Evaluations Formal Design Reviews conducted by senior personnel or outside experts uncover potential problems Inspections.
Evaluating a UI Design Expert inspection methods Cognitive Walkthrough
The Software Development Process
(SRS) SOFTWARE REQUIREMENT SPECIFICATION(SRS) 1. Topics to be discussed.. What is an SRS? Purpose of an SRS Who reads the SRS? Who writes the SRS? Characteristics.
Explain the Marketing Research Process
Reusing Modeling Elements in IV&V Thomas Otani Naval Postgraduate School 2009 NASA Independent Verification and Validation (IVV) Annual Workshop John Ryan.
Intelligent Systems Software Assurance Symposium 2004 Bojan Cukic & Yan Liu, Robyn Lutz & Stacy Nelson, Chris Rouff, Johann Schumann, Margaret Smith July.
Software Engineering Lecture # 1.
The Marketing Research Process. The Marketing Research Process: 11 Steps Step One:Establishing the Need for Marketing Research Step Two:Defining the Problem.
Aquarius Mission Simulation A realistic simulation is essential for mission readiness preparations This requires the ability to produce realistic data,
Software Quality Assurance SOFTWARE DEFECT. Defect Repair Defect Repair is a process of repairing the defective part or replacing it, as needed. For example,
1 The Requirements Problem Chapter 1. 2 Standish Group Research Research paper at:  php (1994)
Markland J. Benson, Computer Systems Manager, White Sands Complex, (575) , Technology Infusion of CodeSonar into the Space.
Ahmed Hassan Ghulam Murtaza Umar Farooq M Mannan Razzaq BSEF08A011 BSEF08A031 BSEF08A034 BSEF08A050.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Quality Assurance in the Presence of Variability Kim Lauenroth, Andreas Metzger, Klaus Pohl Institute for Computer Science and Business Information Systems.
SRR and PDR Charter & Review Team Linda Pacini (GSFC) Review Chair.
1 The Software Development Process ► Systems analysis ► Systems design ► Implementation ► Testing ► Documentation ► Evaluation ► Maintenance.
SAS_05_Contingency_Lutz_Tal1 Contingency Software in Autonomous Systems Robyn Lutz, JPL/Caltech & ISU Doron Tal, USRA at NASA Ames Ann Patterson-Hine,
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
Automated Formal Verification of PLC (Programmable Logic Controller) Programs
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
Project Management Strategies Hidden in the CMMI Rick Hefner, Northrop Grumman CMMI Technology Conference & User Group November.
ARTIFICIAL INTELLIGENCE include people, procedures, hardware, software, data and knowledge needed to develop computer systems and machines that demonstrated.
Why do we study algorithms?. 2 First results are about bats and dolphins.
Chapter 8-1 Chapter 8 Accounting Information Systems Information Technology Auditing Dr. Hisham madi.
More SQA Reviews and Inspections. Types of Evaluations  Verification Unit Test, Integration Test, Usability Test, etc  Formal Reviews  aka "formal.
Software Design and Development Development Methodoligies Computing Science.
COBIT. The Control Objectives for Information and related Technology (COBIT) A set of best practices (framework) for information technology (IT) management.
Millennium Engineering and Integration Company A NEW DOCUMENTATION PROCESS TO STREAMLINE RANGE SAFETY PROCEDURES 0 O. “Rusty” Powell, Allan Smith, Jeff.
The PLA Model: On the Combination of Product-Line Analyses 강태준.
Software Engineering – Fall 2015 (CSC 4350/6350) TR. 5:30 pm – 7:15 pm Rao Casturi 09/01/2015
CS 4700: Foundations of Artificial Intelligence
Intelligent Systems Software Assurance Symposium 2004
QGen and TQL-1 Qualification
Software Verification, Validation, and Acceptance Testing
Activities of Formal Methods
Presentation transcript:

Verifying AI Plan Models Even the best laid plans need to be verified Margaret Smith – PI Gordon Cucullu Gerard Holzmann Benjamin Smith Prepared for the 2004 Software Assurance Symposium (SAS) DS1 MSL

Problem How do you know that an Artificial Intelligence (AI) Onboard Planner will produce only good plans when it is flown? goals state variables resources activities AI Planner Input model Plans Once the planner selects a plan, with a simple check we can show that the plan is consistent with the input model provided to the planner. But there is currently no method to check that the input model will allow only good plans.

Problem, 2 How are AI models tested currently? 1.Construct the model from Science or other requirements. 2.Inspect the model for correctness against requirements. 3.Input the model to the AI planner and ask for a specified number of plans. 4.Manually inspect plans to identify bad plans Adjust constraints and other model elements to exclude bad plans. bad plan(s) all good plans(s) End testing try again

Approach Test plan models exhaustively to determine whether an input model allows bad plans. Construct the model from Science or other requirements. Inspect the model for correctness against requirements. Formulate ‘good plan’ properties Express model in Promela and exhaustively check using Spin. Adjust constraints and other model elements to exclude bad plans. bad plan (error trace) no errors End testing try again

Benefits Retire an important class of risks inherent to all missions using AI Planners. –by replacing a sampling test method with an exhaustive test method Enable autonomous systems that are needed by NASA projects to meet budget and science return requirements.

Relevance to NASA High mission operations costs are pushing NASA funded missions toward more autonomous planning capabilities. Communication delays for Deep Space missions are a poor match with traditional commanded spacecraft. Methods for testing must keep pace with the highly complex, autonomous systems we are developing.

Accomplishments Work on this project began in January, Team members (Affiliation: JPL): Margaret Smith (PI) – model checking, property specification Gordon Cucullu – model checking, spacecraft domain expert Gerard Holzmann – author of the Spin model checker, model checking expert Ben Smith – member of the JPL AI community, AI expert

Accomplishments, 2 Scoped the problem: worked with the JPL AI community to identify an important class of risks associated with AI planners. –The risk identified is that AI input models, which are built by hand, may permit a AI planner to select a bad plan. Using ‘toy’ problems, demonstrated that the Spin model checker can find bad plans allowed by the input model. –The input model is expressed in Promela, the language of the Spin model checker. –A good plan is expressed formally as a property –Spin finds an exception to the good plan (i.e. a bad plan) and reports it as an error.

Accomplishments, 3 Using a real example, the now cancelled DS4/ST4 Champollion mission, demonstrated that Spin can find bad plans on real AI input models. –The model, when expressed in Promela, is tractable (can be exhaustively checked within memory constraints of a desktop PC with 2 GB of memory in a few minutes). We analyzed the bad plan produced by Spin, and fixed the AI input model, by adding a missing constraint. An exhaustive recheck with Spin showed that the fixed model can only produce good plans.

Next Steps Test additional properties of the DS4/ST4 input model. Repeat the process on other AI models we have acquired to see if we get similar positive results. Repeat the process recently launched or soon to be launched missions: –Earth Orbiter 1 –3 Corner Sat