20
Automating Commutativity Analysis at the Design Level Greg Dennis, Robert Seater, Derek Rayside, Daniel Jackson MIT CSAIL [email protected]

Automating Commutativity Analysis at the Design Level

  • Upload
    lucus

  • View
    34

  • Download
    0

Embed Size (px)

DESCRIPTION

Automating Commutativity Analysis at the Design Level. Greg Dennis, Robert Seater, Derek Rayside, Daniel Jackson MIT CSAIL [email protected]. Therac-25 (1985-1987). race conditions when operator typed too quickly lacked hardware interlocks in previous versions - PowerPoint PPT Presentation

Citation preview

Page 1: Automating Commutativity Analysis at the Design Level

Automating Commutativity Analysis at the Design Level

Greg Dennis, Robert Seater,Derek Rayside, Daniel Jackson

MIT [email protected]

Page 2: Automating Commutativity Analysis at the Design Level

Therac-25 (1985-1987)

• race conditions when operator typed too quickly

• lacked hardware interlocks in previous versions

• X-rays delivered without metal target in place

• problems eluded testing

• 6 major overdoses, 2 deaths

Page 3: Automating Commutativity Analysis at the Design Level

Panama (2001)

• déjà vu all over again

• unexpected data entry

• 20%-100% more radiation than prescribed

• 28 overdoses, at least 6 attributable deaths

Page 4: Automating Commutativity Analysis at the Design Level

Northeast Proton Therapy Center

• proton therapy machine at MGH

• unlike the Therac or Panama

• extensive hardware interlocks

• abundant runtime checks

• thoroughly reviewed and tested

Page 5: Automating Commutativity Analysis at the Design Level

TCR 2

NPTC Overview

TCR 1 TCR 3

room 2

cyclotron Master Control Room (MCR)

Page 6: Automating Commutativity Analysis at the Design Level

room 2room 3

Automatic Beam Scheduler (ABS)

room 1

room 3

Request Queue

allocated

pending

room 1

Page 7: Automating Commutativity Analysis at the Design Level

TCR Operations

• RequestBeam• RequestBeamHighPriority• CancelBeamRequest• ReleaseBeam

Request(1) ReqHigh(3)Request(2) Cancel(1) Release(3)

3

2

1

1

2

1 3

2

2

Page 8: Automating Commutativity Analysis at the Design Level

2

1

3

MCR Operations

• StepUp• StepDown• Flush• FlushAll

StepUp(1) Flush(3)StepDown(1) FlushAll()

2

1

22

1

3

2

1

3

Page 9: Automating Commutativity Analysis at the Design Level

Interfering Commands

FlushAll() Request(1)

2

1

3

2

3

2

1

Request(1)

Request(1)

FlushAll()

FlushAll()

2

2

Page 10: Automating Commutativity Analysis at the Design Level

Commutativity

• if not, results can be surprising when commands issued simultaneously.

Page 11: Automating Commutativity Analysis at the Design Level

Violations of Commutativity

Violation ofDiamond Equivalence:

Violation ofDiamond Connectivity:

Page 12: Automating Commutativity Analysis at the Design Level

What We Did

AlloyModel

AlloyModel

OCL Spec ofBeam Scheduler

OCL Spec ofBeam Scheduler

Commutativity Properties

Commutativity Properties

CommutativityMatrix

AlloyAnalyzer

commutativity properties for each pair of operations

Page 13: Automating Commutativity Analysis at the Design Level

OCL Spec

context BeamScheduler::cancelBeamRequest(req: BeamRequest) pre: -- BeamRequest is inside the pending request queue self.pendingRequests@pre->exists(r | r == req)

post: -- BeamRequest is not inside the pending requests queue not self.pendingRequests->exists(r | r == req)

key differences between OCL and Alloy?

Page 14: Automating Commutativity Analysis at the Design Level

open util/ordering[OrderID]

sig Request { room: Room, priority: Priority}

sig Room {}

abstract sig Priority {}one sig Service, Normal, High extends Priority {}

sig Queue { alloc, pending, requests : set Request, order: requests -> one OrderID}{ requests = alloc + pending}

sig OrderID {}

Page 15: Automating Commutativity Analysis at the Design Level

Operations

pred CancelBeamRequest(q, q': Queue, req: Request) { preCancelBeamRequest(q, req) q'.pending = q.pending - req q'.alloc = q.alloc q'.order = (q.requests – req) <: (q.order)}

pred preCancelBeamRequest(q: Queue, req: Request) { req in q.pending} we factored out the precondition of each

operation into a separate predicate

effect of operation as constraint on pre- and post-state

Page 16: Automating Commutativity Analysis at the Design Level

assert A_B_Equiv { all si, sa, sb, sab, sba: Queue { A(si,sa) && B(sa,sab) && B(si,sb) && A(sb,sba) => sab = sba } }

assert Cancel_StepUp_Equiv { all si, sa, sb, sab, sba: Queue, rq1, rq2: Request { (Invariants(si) && CancelBeamRequest(si, sa, rq1) && StepUp(sa, sab, rq2) && StepUp(si, sb, rq2) && CancelBeamRequest(sb, sba, rq1)) => equivQueues(sab, sba) }}

Commutativity Properties

Page 17: Automating Commutativity Analysis at the Design Level

Results

Request ReqHigh Cancel Release

Request x x

ReqHigh x x

Cancel x

Release x x x

3-100 seconds/analysis, Pentium III 600 MHz, 192 MB RAM

StepUp x x

StepDown x x

Flush x x x x

FlushAll x x x x

TCR Operations

TC

R O

per

atio

ns

MC

R O

per

atio

ns

Page 18: Automating Commutativity Analysis at the Design Level

Non-commutativity Example

Release(2) ReqHigh(1)

1

2

2

1

ReqHigh(1)

ReqHigh(1)

Release(2)

Release(2)

cannot execute

Page 19: Automating Commutativity Analysis at the Design Level

Pure Logic Modeling

• Could we have modeled commutativity in OCL with built-in state transitions?

• "Pure Logic Modeling":– explicit states allows us to "rewind" time and

ask about different execution traces

• Similar difficulty analyzing these properties with traditional model checker.

Page 20: Automating Commutativity Analysis at the Design Level

Conclusions

• Practical results from lightweight formal methods

• Commutativity analysis is useful– when humans manipulate shared data

• Constraint solver effective for this analysis– didn't stretch limits of tool or modelers

• Analyzability is important in practice

• Pure logic modeling is powerful