Integration of model checking into software development processes
Download
1 / 81

- PowerPoint PPT Presentation


  • 145 Views
  • Uploaded on

Integration of Model Checking into Software Development Processes. Fei Xie. Outline. Problem Dissertation research overview Focus: Integration of model checking into CBD Conclusion and future work. Validation of Software. Testing is the most commonly used technique

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about '' - chelsia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Outline l.jpg
Outline Processes

  • Problem

  • Dissertation research overview

  • Focus: Integration of model checking into CBD

  • Conclusion and future work


Validation of software l.jpg
Validation of Software Processes

  • Testing is the most commonly used technique

  • Software complexity has overwhelmedconventional testing methods

    • Test case coverage

    • Lack of automation

    • Concurrency makes testing even harder

  • Software must be validated

  • Advanced validation techniques are needed


Model checking mc l.jpg
Model Checking (MC) Processes

  • A formal verification method

  • Able to explore all possible states (or execution paths) of a system

  • Enjoys substantial automation support

  • Has been quite successful for hardware

    [Clarke and Emerson 81, Queille and Sifakis 82]


Research goal and problem l.jpg
Research Goal and Problem Processes

  • Goal: Seamlessly integrate MC into software development processes

  • Problem: Address two major challenges

    • Applicability

    • State space explosion


Challenge i applicability l.jpg
Challenge I: Applicability Processes

  • Syntax and semantics gaps between

    • Software specification languages

    • Input languages of model checkers

      • Often specify finite-state systems

  • Difficulties in property specification

    • For instance, software engineers are not familiar with temporal logics


Challenge ii state space explosion l.jpg
Challenge II: State Space Explosion Processes

  • 5 components, 1000 states/component

  • Worst case: 1000 trillion states


Overview of my research l.jpg

Model-Driven Processes

Development (MDD)

Component-Based

Development (CBD)

Model Checking

Model Checking

Overview of My Research

+


Model driven development l.jpg

Analysis Processes

and

Design

Executable

Design

Model

Design

Validation

Predefined

Templates

Code

(C/C++, Java)

Code

Generation

Validated

Executable

Design

Model-Driven Development

Requirement

Increasingly popular for

Embedded Systems and

Web-Based Systems


Executable uml xuml l.jpg
Executable UML (xUML) Processes

  • Has well-defined Execution Semantics

  • Utilizes UML Action Semantics recently adopted by OMG

  • Can be compiled to procedural codes

  • Tools provided by:

    • Project Technologies

    • Kennedy Carter

    • Hyperformix (SES)


Integration of mc into mdd l.jpg
Integration of MC into MDD Processes

How to address applicability?

  • Executable design-level models are key to MDD

    • Executable:amenable to model checking

    • Design-level: lower complexities

  • Model Checking Software Designs via Translation[FASE’04, FASE’02a, ASE’01]

    • Translate designs into model-checkable languages

    • Reuse state-of-the-art model checkers

    • Support design-level property formulation


The objectcheck toolkit l.jpg

Designer Processes

Property

xUML Model

Error Report

S/R Query

S/R Model

Error Track

The ObjectCheck Toolkit

Property Specification Interface

xUML IDE

Error Visualizer

xUML-to-S/R Translator

Error Report Generator

COSPAN Model Checker


Cospan hardin har el and kurshan 96 l.jpg
COSPAN Processes[Hardin, Har’El, and Kurshan 96]

  • Automata-theoretical approach to model checking[Kurshan 94]

    • Model a system and its property as -automata, P and T

    • Check the language containment, L(P)  L(T)

  • Many state space search and reduction algorithms

    • Explicit state enumeration

    • Symbolic model checking

    • Localization reduction

    • Homomorphism reduction

    • (and more)


Integration of mc into mdd cont l.jpg
Integration of MC into MDD (cont.) Processes

How to reduce state spaces?

  • Model Checking Software Designs via Translation[FASE’04, FASE’02a, ASE’01]

    • Many reduction algorithms applied in translation

  • Integrated State Space Reduction[FASE’02b]

    • Reduction algorithms applied in an integrated way

  • Translation-Based Compositional Reasoning[FME’03]

    • Application of CR in model checking via translation


Integrated state space reduction framework l.jpg

Verification Task Processes

Compositional Reasoning

Abstraction

Symmetry Reduction

User-Driven State Space Reduction

Verification Subtasks

Reduced

xUML Model

Reduced xUML

Level Query

Partial Order Reduction

Symbolic Verification

Localization Reduction

Basic Model Checking Process

Integrated State Space Reduction Framework

xUML Model

xUML Level Query

xUML-to-S/R Translation

S/R Model

S/R Level Query

Model Checking with COSPAN

Success Report / Error Track


Translation based compositional reasoning l.jpg
Translation-Based Compositional Reasoning Processes

  • Compositional Reasoning (CR)[Misra and Chandy 81, …]

    • Decompose a system into modules

    • Verify module properties

    • Derive system properties from module properties

  • To apply CR, what need be done

    • Establish a compositional reasoning rule

    • Prove the correctness of the rule

    • Implement the rule

  • How to apply CR in model checking via translation?


Rule establishment and proof l.jpg

(4) Processes

Prove the rule based on

the mapping and proof

of the corresponding

rule in formal semantics

(2)

Map the rule to

its corresponding

rule in the formal

semantics

Semantics Translation

Rule Establishment and Proof

  • Establish a compositional

    reasoning rule

Software Semantics

Formal Semantics

(3) Prove the corresponding

rule or reuse existing proof


Rule implementation and application l.jpg

(4) Processes

Establishment

of conclusion

according to

the proven rule.

(2)

Translation of

the premises.

Rule Implementation and Application

  • Formulation of premises for

    applying the rule

Software System

Formal Representation

(3) Discharge of the premises


Real world systems verified l.jpg
Real-World Systems Verified Processes

  • The control subsystem of a NASA robotics system[FMSD’03]

    • Code size 45,000 lines of C++

    • 22 properties checked: safety and liveness

    • 6 bugs found

  • Instances of TinyOS run-time system for networked sensors [ESEC/SIGSOFT FSE’03]


Today s focus integration of mc into cbd l.jpg

Component-Based Development (CBD) Processes

Model Checking

Today’s Focus:Integration of MC into CBD

How are Applicability and State Space Explosion addressed?

Verified Systems by Composition from Verified Components[ESEC/SIGSOFT FSE’03]


Integration of mc into cbd l.jpg
Integration of MC into CBD Processes

  • Motivation

  • Overview

  • Component Model for Verification

  • Case Study: TinyOS

  • Verification of Components


What is cbd l.jpg
What is CBD? Processes

  • Compose systems via component assembly

  • Pre-fabricate many components

  • Reuse components as much as possible

  • Increasingly popular for

    • Embedded systems

    • Web-based systems

  • Analogies: Automotive and Avionics


Research goal l.jpg
Research Goal Processes

  • Goal:

    • To construct safe, secure, and reliable systems from safe, secure, and reliable components

  • Framework:

    • Composition of verified systems from verified components


Research challenges l.jpg
Research Challenges Processes

  • How to verify primitive components?

    • How to represent the environment?

    • How to conduct the verification?

  • How to compose verified components to build larger verified components effectively?

    • How to verify the larger components?

    • How to reuse verified properties?

Both applicability and state space management


Synergy between cbd and mc l.jpg
Synergy between CBD and MC Processes

  • Component-based development

    • Introduces compositional structures to software

    • Helps minimize state spaces to be explored

  • Model checking

    • Provides exhaustive state space coverage

    • Strong at detection of composition errors

Explore this synergy to address these challenges


Integration of mc into cbd26 l.jpg
Integration of MC into CBD Processes

  • Motivation

  • Overview

  • Component Model for Verification

  • Case Study: TinyOS

  • Verification of Components


Our approach l.jpg

+ Processes

=

Verified

Properties

Verified

Properties

Verified

Properties

Our Approach

Verification of a property on a composite component

  • Reuses verified properties of its sub-components

  • Is based on compositional reasoning

  • Follows an abstraction-refinement paradigm


Compositional reasoning l.jpg
Compositional Reasoning Processes

To model check a property on a software system

  • Step 1: Decompose the system into modules and model-check module properties

  • Step 2: Derive the system property from the verified module properties

Assume-guarantee style of compositional reasoning[Misra and Chandy 81, Abadi and Lamport 93, Alur and Henzinger 99, McMillan 99, Amla, Emerson, Namjoshi and Trefler 01, …]

  • Model check properties of a module assuming properties of other modules hold


Integration of mc into cbd29 l.jpg
Integration of MC into CBD Processes

  • Motivations

  • Overview

  • Component Model for Verification

  • Case Study: TinyOS

  • Verification of Components


Component l.jpg

Functional Processes

Interface

External Visible

Variables

Verified Temporal

Properties

Executable Representation

(Design Models or Sources)

Component


Component property l.jpg

Environment of ProcessesC

(Components interacting with C )

Component Property

  • A property of C is a pair (p, A(p))

    • p is a temporal property

    • A(p) is a set of assumptions on environment of C

    • pis verified assumingA(p)holds.

A(p) p holds on C

A(p)

Assumptions

= Assumed Properties

p

C


Component composition l.jpg

Executable of C Processes1

Connect via interfaces

Executable of C

Executable of Cn

Interface of C1

Selectively merge

Interface of C

Interface of Cn

(Visible variable sets are treated in the same way.)

?

Properties of C1

Properties of C

Properties of Cn

Component Composition


Instantiation of component model on aim computation model l.jpg
Instantiation of Component Model on ProcessesAIM Computation Model

  • Asynchronous Interleaving Message-passing

    • A system consists of a finite set of processes

    • Processes execute asynchronously

    • At any moment, only one process executes

    • Interactions via asynchronous message-passing

  • Semantics of xUML conforms to the AIM model.


Instantiation of component model on aim computation model cont l.jpg

External Visible Processes

Variables

Verified Temporal

Properties

Instantiation of Component Model on AIM Computation Model (cont.)

  • Compose components by establishing mappings among their input and output message types

Messaging

Interface

Design models in xUML


Integration of mc into cbd35 l.jpg
Integration of MC into CBD Processes

  • Motivation

  • Overview

  • Component Model for Verification

  • Case Study: TinyOS

  • Verification of Components


Tinyos hill et al 00 l.jpg
TinyOS Processes[Hill, et al., 00]

  • A run-time system for networked sensors from UC Berkeley

  • Component-based

    • Different requirements of sensors

    • Physical limitations of sensors

  • High reliability required

    • Concurrency-intensive operations

    • Installation to many sensors


Integration of mc into cbd37 l.jpg
Integration of MC into CBD Processes

  • Motivation

  • Overview

  • Component Model for Verification

  • Case Study: TinyOS

  • Verification of Components


Background verification of closed aim system l.jpg

Designer Processes

Property

xUML Model

Error Report

S/R Query

S/R Model

Error Track

Background:Verification of Closed AIM System

Property Specification Interface

xUML IDE

Error Visualizer

xUML-to-S/R Translator

Error Report Generator

COSPAN Model Checker


Verification of primitive components l.jpg

2. Constrain the closed system Processes

1. Create a closed system

p

Env

(AIM Process)

Assumptions in A(p)

3. Check p on the constrained system

Verification of Primitive Components

To check a property (p, A(p)) :

Addressing both applicability and state space explosion in model checking primitive components

With a matching interface,

but non-deterministic

Primitive

Component

Step 1 of Compositional Reasoning: Verification of Module Property


Sensor component l.jpg

AIM Processes

Process

Input Message

Type

Component

Boundary

Output Message

Type

Sensor Component


Sensor component cont l.jpg
Sensor Component (cont.) Processes

Properties:

(Output repeatedly and handle output handshakes correctly.)

Repeatedly (Output);After (Output) Never (Output) UntilAfter (OP_Ack);After (Done) Eventually (Done_Ack);Never (Done_Ack) UntilAfter (Done);After (Done_Ack) Never (Done_Ack) UntilAfter(Done);

Assumptions:

(Output handshakes are correctly ack-ed.)

After (Output) Eventually (OP_Ack);Never (OP_Ack) UntilAfter (Output);After (OP_Ack) Never (OP_Ack) UntilAfter (Output);After (Done) Never (Done) UntilAfter (Done_Ack);


Verification of sensor component l.jpg

Output Processes

Env

Output_Ack

Done

Done_Ack

Assumptions

Verification of Sensor Component

Sensor

Component



Network component cont l.jpg
Network Component (cont.) Processes

Properties:

(Transmit repeatedly if input repeatedly, and handle input handshakes correctly.)

IfRepeatedly (Data) Repeatedly (RFM.Pending);

IfRepeatedly (Data) Repeatedly (Not RFM.Pending);

After (Data) Eventually (Data_Ack); Never (Data_Ack) UntilAfter (Data);

After (Data_Ack) Never (Data_Ack) UntilAfter (Data);

After (Sent) Never (Sent) UntilAfter (Sent_Ack);

Assumptions:

(Input handshakes are correctly ack-ed.)

After (Data) Never (Data) UntilAfter (Data_Ack);

After (Sent) Eventually (Sent_Ack); Never (Sent_Ack) UntilAfter (Sent);

After (Sent_Ack) Never (Sent_Ack) UntilAfter (Sent);


Verification of composite components l.jpg

(3) Refinement Processes

(2) Verification

Verification of Composite Components

Addressing both applicability and state space explosion in model checking composite components

To model check a property on a composite component:

(1) Abstraction


Abstraction refinement paradigm l.jpg

Refine through Processes

adding details

Refined Abstraction

Good Enough Abstraction

Abstraction-Refinement Paradigm

Abstraction

What is the abstraction?

Verified properties

of sub-components

Component


Verified properties as abstraction l.jpg
Verified Properties as Abstraction Processes

A property = a behavior of a component

Sensor

Component

Property 1: Outputs repeatedly

Property 2: Handles output handshakes correctly

The component can be represented by the property if only the behavior is of interest.



Sensor to network component49 l.jpg
Sensor-to-Network Component Processes

Properties:

(Transmit repeatedly on physical network.)

Repeatedly (RFM.Pending);

Repeatedly (Not RFM.Pending);

Assumptions:

(Assumptions on hardware platform are ignored. )


Abstraction l.jpg

Verified Properties Processes

Verified Properties

SP

(Sensor)

NP

(Network)

Non-deterministic

AIM Processes

Assumptions

Abstraction

Env

(Environment)


Abstraction cont l.jpg
Abstraction (cont.) Processes

  • A sub-component property is included if it is

    • Related by dependencies

    • Not involved in invalid circular dependencies

    • Enabled: Its environment assumptions hold on

      • Other sub-components in the composition

      • Environment of the composition

Verified properties of Sensor and Network are included in the abstraction of Sensor-to-Network.


Abstraction verification l.jpg
Abstraction Verification Processes

  • The properties of Sensor-to-Network:

    Transmit repeatedly on physical network

    were successfully verified on the abstraction

Step 2 of Compositional Reasoning: Derivation of System Property

  • Conclusion: Sensor-to-network has the properties

Step 1 of Compositional Reasoning: Verification of Module Property




Abstraction refinement l.jpg
Abstraction Refinement Processes

  • An abstraction can be refined by

    • (Introducing, verifying, and) enabling additional sub-component properties

  • A property can be enabled by

    • Enabling its assumptions on other components

  • Currently requires user interactions


Refinement example l.jpg

To verify a Processesnew property, P1, on Sensor-to-Network (SN):

Property P1:SN transmits any sensor reading exactly once

Property P2: Network transmits any input exactly once.Assumption:A new input arrives only after Network acks the last input with a Sent message

Refinement Example

Sensor-to-Network

Sensor

Network


Refinement example cont l.jpg

Property P3: ProcessesSensor outputs any sensor reading exactly once;

After an output, Sensor will not output until a Done message is received.

Refinement Example (cont.)

Sensor-to-Network

P1

P3

P2

Sensor

Network

  • A real bug was found in Sensor and fixed. Property P3 was verified on the revised Sensor

  • Inclusion of P2 and P3 into the abstraction  P1




Related work to component verification l.jpg
Related Work to Component Verification Processes

  • Compositional Reasoning

    • Previous work: in top-down system decomposition

    • Our approach: in bottom-up component composition

  • The Inscape Environment [Perry 89]

    • Consistency checking in software composition models

  • Compositional Reachability Analysis (CRA)

    [Graf and Steffen 90, Yeh and Young 91, Cheung and Kramer 93]

    • Composition and minimization of Label Transition Systems

  • Modular Feature Verification [Fisler and Krishnamurthi 01]

    • Verification of layered composition of features


Contributions of my research l.jpg
Contributions of My Research Processes

  • Seamless integration of MC into MDD

    • Verification of real-world systems of significant size

  • Seamless integration of MC into CBD

    • Verification of real-world component-based systems

  • Addresses of both challenges in software MC

    • Applicability

    • State space explosion

  • Synergistic combination of the two integrations

    • Further alleviation of state space explosion


Immediate future research l.jpg

Scalable Verification Processes

of Component-Based

Systems

Software

Safety

Security Guarantee

through Formal Verification

Knowledge Driven

Adaptive Model

Checking System

Interactions

Hardware/Software

Co-design and

Co-verification

Security

Reliability

Immediate Future Research


Conclusions l.jpg
Conclusions Processes

  • Software must be safe, secure, and reliable

  • Advanced validation methods are needed

  • My research integrates MC into MDD and CBD

  • Systems of significant size have been verified

  • Many challenging problems are still ahead


Publications l.jpg
Publications Processes

  • Fei Xie, Vladimir Levin, Robert P. Kurshan, and James C. Browne. Translating Software Designs for Model Checking. In Proc. of FASE, to appear, 2004.

  • Thomas Ball, Vladimir Levin, and Fei Xie. Automatic Creation of Environment Models via Training. In Proc. of TACAS, to appear, 2004.

  • Fei Xie and James C. Browne. Verified Systems by Composition from Verified Components.  In Proc. of ESEC/FSE, 2003.

  • Fei Xie, James C. Browne, and Robert P. Kurshan. Translation-Based Compositional Reasoning for Software Systems. In Proc. of FME, 2003. 


Publications cont l.jpg
Publications (cont.) Processes

  • Natasha Sharygina, James C. Browne, Fei Xie, Robert Kurshan, and Vladimir Levin. Lessons Learned from Model Checking a NASA Robot Controller. Journal of FMSD, 2003.

  • Fei Xie and James C. Browne. Integrated State Space Reduction for Model Checking Executable Object-oriented Software System Designs, In Proc. of FASE, 2002. 

  • Fei Xie, Vladimir Levin, and James C. Browne. ObjectCheck: A Model Checking Tool for Executable Object-oriented Software System Designs, In Proc. of FASE, 2002. 

  • Fei Xie, Vladimir Levin, and James C. Browne. Model Checking for an Model Checking for an Executable Subset of UML. In Proc. of ASE, 2001.


For more information l.jpg
For More Information Processes

  • Useful links

    http://www.cs.utexas.edu/users/feixie

    http://www.cs.utexas.edu/users/ObjectCheck

  • Email:

    [email protected]

    Questions?


How mc works l.jpg

Example temporal properties: Processes

Buffer A will never overflow;

System outputs repeatedly

Temporal

Property

System

Model

Exhaustive and intelligent search over the state space of the system model

Model Checker

How MC works?

This is great. Let’s model-check software systems.

Farewell, bugs


Case study an online ticket sale system otss l.jpg

Branching Point 1 Processes

Request

Branching Point 2

Assignment

TryLater

Hold

Held/Later/Out

Branching Point 3

TicketHeld/TryLater/SoldOut

Branching Point 4

Payment

Buy/Release

Ticket

Reset

Case Study: An Online Ticket Sale System (OTSS)

Agent (A)

Ticket_Server (TS)

Customer (C)

Dispatcher (D)


Property to be checked on otss l.jpg
Property to be Checked on OTSS Processes

  • In English,

    After a Request message from a customer is processed by the dispatcher, eventually the system will reply the customer with a TicketHeld message, or a TryLater message, or a SoldOut message

  • In the xUML level query specification logic,

    P0 : After Request (i) Eventually TicketHeld(i) or TryLater (i) or SoldOut(i)


Reduction steps for checking p 0 l.jpg

Customers, Dispatcher Processes

Agents, Ticket Sever

Step 1: Symmetry Reduction

P1

Customers, Dispatcher

Agents, Ticket Sever

Step 2: Decomposition

P21 , P22

P31 , P32 P33 , P23

Customers

Dispatcher

Agents, Ticket Server

P41 , P42 P43 , P44

Step 3: Symmetry Reduction

Agents, Ticket Server

Step 4: Decomposition

P41 , P42 P43 , P44

P5

Agents

Ticket Server

P41 , P42 P43 , P44

Step 5: Case Splitting

Agent

P6

Ticket Server

Reduction Steps for Checking P0

P0

Step 6: Symmetry Reduction


Evaluation of user driven state space reduction l.jpg
Evaluation of User-driven State Space Reduction Processes

  • Directly model checking P0on OTSS

    • Two customer instances and two agent instances

    • SPOR and SMC are both applied

    • Memory usage: 152.79M

    • Time usage: 16273.7S

  • Memory and time usages for discharging subtasks at the leaf nodes of the reduction tree


Translation context l.jpg

AIM Processes

Semantics

Semantics Translation

-automaton

Semantics

Semantics

Conformance

Semantics

Conformance

xUML-to-S/R Translation

xUML

S/R

xUML: An executable dialect of UML

S/R: Input language of COSPAN model checker

Translation Context


Rule aent a mla e merson n amjoshi and t refler 01 l.jpg

Conclusion Processes

Premises

Rule AENT[Amla, Emerson, Namjoshi, and Trefler 01]

  • Has been adapted to AIM semantics

    To show P1//P2 |= Q, find Q1 and Q2 that satisfy:

    C1: P1//Q2 |= Q1 and P2 //Q1 |= Q2

    {Verifying component properties assuming properties of other components hold}

    C2: Q1//Q2 |= Q

    {Deriving system property from component properties}

    C3: Either P1//CL(Q) |= (Q + Q1 + Q2) Or P2//CL(Q) |= (Q + Q1 + Q2)

    {Validating circular dependencies among component properties}


Translation from aim semantics to automaton semantics l.jpg
Translation from AIM Semantics to Processes-automaton semantics

AIM Semantics

I/O-automaton Semantics

-automaton Semantics


Preservation of language containment l.jpg
Preservation of Language Containment Processes

  • L(A)  L(B) iff L(Trans(A))  L(Trans(B))

  • Theorem 1:

    • Translation from AIM semantics to I/O-automaton semantics preserves language containment

  • Theorem 2:

    • Translation from I/O-automaton semantic to -automaton semantics preserves language containment

  • Theorem 3:

    • Translation from AIM Semantic to -automaton semantics preserves language containment


Proof via semantics translation l.jpg
Proof via Semantics Translation Processes

  • Proof sketch for Rule AENT:

    • Assume that C1, C2, and C3 hold

    • By Theorem 3, -automatontranslations of C1, C2, C3 hold

    • By -automaton counterpart of Rule AENT, -automatontranslation of P1//P2 |= Q holds

    • By Theorem 3, P1//P2 |= Q holds


Why validate circular dependencies among component properties l.jpg

C1 Processes

C2

Eventually (A)

Eventually (B)

Eventually (B)  Eventually (A)

Eventually (A)  Eventually (B)

A = FALSE

B = FALSE

X

X

?

Eventually (A) and Eventually (B)

Why validate circular dependenciesamong component properties?

Think about Deadlocks.

A: C1 releases Lock A.

B: C2 releases Lock B.


Property and assumption formulation l.jpg
Property and Assumption Formulation Processes

  • Properties

    • Currently manually guided

    • Derived from component specifications

    • Added incrementally in component reuses

  • Assumptions

    • Manual formulation

    • Automatic generation

      • Often lead to complex assumptions

  • Automatic generation heuristics in progress


Immediate future directions l.jpg
Immediate Future Directions Processes

  • Scalable verification of component-based systems

    • Large-scale components conforming to CORBA, .NET, or other platforms

    • Systems involving multiple component paradigms

  • Software security guarantee via formal verification

    • Integration of security policies into design models

    • Formulation of security properties, e.g., information flow

    • Effective verification of security properties


Immediate future directions cont l.jpg
Immediate Future Directions (cont.) Processes

  • Domain knowledge driven state space reduction

    • Extending integrated state space reduction framework

    • Exploring domain knowledge

    • Developing adaptive model checking systems

  • Hardware/software co-verification

    • Translating both software and hardware into a model checkable language

    • Or modeling hardware as transaction models


Long term research plan l.jpg
Long-Term Research Plan Processes

  • Goal: methods and tools

    • For development of safe, secure, and reliable software systems of increasing complexity

    • Integrated into routine development efforts

  • Approach: synergistic integration of

    • Testing

    • Formal Verification

    • Static Analysis

    • Run-Time Monitoring


ad