Survey on Runtime Monitoring
based on Formal Specification
WPE-II Presentation
By
Usa Sammapun
Oct 28, 2005
Software Programs
Car
ATM
Heart Device
Aircraft
Safe Programs ??
Safe Programs
Verification
Security
Program Development
all-leg-down
!walk
leg2-up, leg3-up
walk & !fall
leg1-up, leg4-up
walk & !fall
Model
leg1-up, leg2-up
walk & fall
walk
and not fall
Requirement
class AIBO {
Leg leg1,leg2,leg3,leg4;
main() {
leg1 = new Leg(1);
leg2 = new Leg(2);
leg3 = new Leg(3);
leg4 = new Leg(4);
}
}
class Leg {
void walk() {
}
void stop() {
}
}
Implementation
Program Safety Techniques
Goal: Ensuring that implementation satisfies requirement
Model
Model Checking
Model Carrying Code
Model Carrying Code
Requirement
Runtime Monitoring
Implementation
Outline


Overview of runtime monitoring
Runtime Verification



Security




Temporal Assertions using AspectJ [Stolz,Bodden05]
Eagle [Barringer et al. 04]
Edit Automata [Bauer et al. 03]
Eagle for Intrusion Detection [Naldurg et al. 2004]
Discussion
Conclusion
Runtime Monitoring
Formal Specification
class AIBO {
Leg leg1,leg2,leg3,leg4;
main() {
leg1 = new Leg(1);
send(checker,leg1);
leg2 = new Leg(2);
send(checker,leg2);
leg3 = new Leg(3);
send(checker,leg3);
leg4 = new Leg(4);
send(checker,leg4);
}
}
class Leg {
void walk() {
send(checker,walk);
}
void stop() {
send(checker,stop);
}
}
Programs
Satisfied
Instrumentation
leg1
Trace Extraction
leg2
leg3
leg4
Monitor
Feedback
Not
Satisfied
Runtime Monitoring

Formal specification language

Based on Mathematics


Instrumentation



Manual & Automatic
Bytecode & Sourcecode
Specification Evaluation Process

Transform spec language into a checking automaton



Takes a trace as an input
Returns result: Satisfied, Not Satisfied
Direct algorithm



Logics, Automata, Calculi
Takes both spec language and a trace as inputs
Returns result: Satisfied, Not Satisfied
Feedback


Optional
Fixed or user-defined
Outline


Overview of runtime monitoring
Runtime Verification



Security




Temporal Assertions using AspectJ [Stolz,Bodden05]
Eagle [Barringer et al. 04]
Edit Automata [Bauer et al. 03]
Eagle for Intrusion Detection [Naldurg et al. 2004]
Comparison and Analysis
Conclusion
Temporal Assertions using
AspectJ (SB’05)



Specification Language: LTL
Spec Evaluation Process: Alternating
Automata
Instrumentation:



Automatic: AspectJ
Bytecode
Feedback: AspectJ
SB’05 Language


LTL – Linear Temporal Logic
Reason about time-dependent truth value


Classical: 1 < 2
Temporal: it’s raining
Proposition

Syntax

f :: = p | ¬ f | f1 ∧ f2 | f1 ν f2
|
Next
○f
| ◊f
Eventually
| □ f | f1 U f2 | f1 R f2
Always
Until
Release
LTL
○f
-- Next
f
◊ f -- Eventually
f ν ○(◊f)

f
□ f – Always (Global) 
f
f
f1 U f2 -- Until
f1
f

f1
f ∧ ○(□f)
f
f
f
f2 ν (f1 ∧ ○(f1 U f2))
f1
f1
f2
f2 ∧ (f1 ν ○(f1 R f2))
f1 R f2 -- Release 
f2
f2
f2
f2
f1
f2
f2
f2
f2
f2
f2
LTL

◊ f = true U f
true


true
true
true
f
□ f = false R f
f
f
f
f
false
f
f
f
f
f
Concise Syntax

f :: = p | ¬ f | f1 ∧ f2 | f1 ν f2
| X f | f1 U f2 | f1 R f2
f
SB’05 Spec Evaluating Process

Translate LTL formulae to Alternating Automata


Use Alternating Automata to check a trace
Alternating Finite Automata (AFA)


Generalization of Non-deterministic Finite Automata (NFA)
 NFA – existential automaton
  -automaton
A combination of both
AFA
s5
e
a
s2
e
s1
e
s3
s4

s6

s7

s8

a
e
On input a :
s9
T(s1, a) = {s2, s5, s8, s9}
NFA: Accept
- automata: Reject
AFA: Depends

a
s10





AFA = (S, S, s0, T, F)
The only difference from NFA is the transition function
TNFA(s1, a) = {s2, s5, s8, s9}
= s2 ν s5 ν s8 ν s9
TAFA(s1,a) = (s2 ν s5) ∧ (s8 ν s9)
 Choose to go to {s5, s9}, then accept
TAFA(s1,a) = s2 ∧ (s5 ν s8 ν s9)
 Reject, no matter what you choose
AFA


Formally, AFA = (S, S, s0, T, F)
T: S x S  B+(S)

B+(S) is a set of positive Boolean formulae over S
 Positive Boolean Formulae: Boolean formulae built from
elements in S using ∧ and ν

We say a set S’ satisfies a positive Boolean formula f in B+(S) if
the truth assignment assigns true to S’ and false to S-S’
 For example,


the set S’ = {s5, s9} satisfies the formula f = (s2 ν s5) ∧ (s8 ν s9)
the set S’ = {s2, s5} does not satisfy f
AFA


A run r’ of NFA is linear because you only choose one path
A run r of AFA is a tree



For disjunction, you choose one path
For conjunction, you have to take all paths
A run r of AFA on a finite word w = a1, a2, …, an is a finite tree such that


if s is a node in the tree r and T(s, ai) = f, where f is positive Boolean
formula
then s has k children for some k ≤ |S|, and {s1, s2, …, sk} satisfies f





Transition therefore determines what are possible next states
TAFA(s1,a) = (s2 ν s5) ∧ (s8 ν s9)
Possible states are {s2,s8}, {s2, s9}, {s5,s8}, {s5,s9}
E.g., you can’t go to state {s2,s5}
AFA accepts a run r if all leaves of a run r are final states
s1
s5
s9
Translation: LTL  AFA

Translating an LTL formula f to an AFA Af



Af accepts, then f satisfies
Af rejects, then f doesn’t satisfy
Af = (S, S, s0, T, F)





S = a set of propositions in f
S = all sub-formulae of f and true, false
s0 = original formula f
F = all formulae in S of the form (f1 R f2) and true
T  next slide
Translation: LTL  AFA

States: Formulae, sub-formulae, true, false

Transition: T(state, input) = state











T(p, Prop) = true if p  Prop
T(p, Prop) = false if p
Prop
T(¬p, Prop) = true if p
Prop
T(¬p, Prop) = false if p
Prop
T(true, Prop) = true
T(false, Prop) = false
T(f1 ν f2, Prop) = T(f1 ,Prop) ν T(f2 ,Prop)
T(f1 ∧ f2, Prop) = T(f1 ,Prop) ∧ T(f2 ,Prop)
T(Xf, Prop) = f
T(f1 U f2, Prop) = T(f2, Prop) ν (T(f1, Prop) ∧ (f1 U f2))
T(f1 R f2, Prop) = T(f2, Prop) ∧ (T(f1, Prop) ν (f1 R f2))



SB’05 Evaluation Summary

Given an LTL formula and an execution trace (set of
propositions)

LTL f is translated into AFA Af

Af checks an execution trace

At anytime, if transit to the state



true, satisfied
false, falsified
At the end of the trace,


If at final state, satisfied
Otherwise, falsified
SB’05 Instrumentation /
Feedback:
AspectJ
Head
void look()
void move()
void stop()


Leg
void kick()
void move()
void stop()
At move and stop, create a log file or calculate safe location
AspectJ helps you modularize by writing once: specify


Where to do operations  Pointcut
What kind of operations  Advice
Aspect
AspectJ

LTL formulae are transformed into an aspect

Pointcut as propositions
requiresInit() shall not be called unless init() has been called prior
(!call(requiresInit()))
U (call(init())

Advice: AFA takes transitions and checks a trace
AspectJ
aspect InitPolicy {
pointcut p1(): call(requiresInit());
pointcut p2(): call(init());
pointcut
int p1 = 1; int p2 = 2;
Formula state = Until( Not(p1), p2);
Set<int> currentPropositions = new Set<int>();
declaration
after(): p1() { currentPropositions.add(p1); }
after(): p2() { currentPropositions.add(p2); }
after(): p1() || p2() {
state = state.AFAtransition(currentPropositions);
if (state.equals(Formula.True)) {
// report the formula as satisfied
} else if (state.equals(Formula.False)) {
// report the formula as falsified
}
currentPropositions.clear(); // reset proposition vector
}
}
advice
Overall Architecture –
Instrumentation
AspectJ
Compiler
Specification
aspect F1 {...
p1 U p2... CodeGen
AFAtransition
Weaving
Instrumented
Java bytecode
if(!p1) notify{...
Outline


Overview of runtime monitoring
Runtime Verification



Security




Temporal Assertions using AspectJ [Stolz,Bodden05]
Eagle [Barringer et al. 04]
Edit Automata [Bauer et al. 03]
Eagle for Intrusion Detection [Naldurg et al. 2004]
Comparison and Analysis
Conclusion
EAGLE




Specification Language: Eagle
Specification Evaluation: Direct algorithm
Instrumentation: Feedback: -

Motivated by the need for small, general, but powerful framework
for specifying languages for runtime monitoring

Eagle can be used to specify LTL, Metric Temporal Logic (MTL),
Regular expression, limited form of Context Free language
Eagle Language

Illustrated by an example LTL
Next
Evaluate to true
at the end of the
trace
Evaluate to
false at the end
of the trace
○ is built-in syntax
○ Always(F)
min Eventually(Form F) = F ν ○ Eventually(F)
min Until(Form F , Form F ) = F ν (F ∧ ○ Until(F , F ))
max Always(Form F) = F ∧
1
2
2
1
mon M1 = Always(x > 0  Eventually(y > 0))
1
Rules
2
Properties
Syntax


R :: = {max | min} N(T1 x1, …, Tn xn) = F
F :: = expression | true | false
| ¬F | F1 ∧ F2 | F1 ν F2 | F1  F2
|


○F | N(F1, …, Fn) | xi
M ::= mon N = F
S ::= R* M*
Metric Temporal Logic (MTL)

Temporal logic parameterized by some
clock(s)

Ex. ◊[t1,t2] f


Means that f must hold true sometime when a clock
value is between t1 and t2
Eagle Rule
min EventAbs(Form F, float t1, float t2) =
(F ∧ t1 ≤ clock ∧ clock ≤ t2) ν
((clock < t1 ν ( ¬F ∧ clock ≤ t2)) ∧ ○ EventAbs(F,t1,t2))
Eagle Spec Evaluation Process

At every state, the runtime monitor evaluates formulae, and
generates a new set of formulae to hold in the next state

By using eval function









eval: F x state  F
Its result is a new set of formulae to hold in the next state
eval(true, s) = true
eval(false, s) = false
eval(exp, s) = value of exp in s
eval(¬F, s) = ¬eval(F, s)
eval(F1 op F2, s) = eval(F1, s) op eval(F2, s)
eval(○F, s) = F
eval(N(F,P), s) = eval(B[f  F, p  P], s)
where op is ∧ , ν , 
if {max | min} N(Form f,T p) = B
Eagle Evaluation Summary

A list of monitored properties

At any time during the trace





The runtime monitor evaluate formulae, and generate a
new set of formulae to hold in the next state
If any formula is evaluated to true, that formula is removed
from the monitoring list
If any monitor is evaluated to false, a violation is issued
Remaining formulae will be checked at the next state
At the end of the trace


Remaining max rule  evaluate to true
Remaining min rule  evaluate to false
Eagle
Instrumentation/Feedback

No instrumentation & Feedback

Need a third-party program to supply an
execution trace
Outline


Overview of runtime monitoring
Runtime Verification



Security




Temporal Assertions using AspectJ [Stolz,Bodden05]
Eagle [Barringer et al. 04]
Edit Automata [Bauer et al. 03]
Eagle for Intrusion Detection [Naldurg et al. 2004]
Comparison and Analysis
Conclusion
Edit Automata

A slightly different goal, but similar technique
 Goal: run untrusted code without harming our machine

Specification Language & Spec Evaluating Process:
 Security Policies is defined in terms of Edit Automata
 Edit Automata is a monitor running in parallel with the untrusted
program


Instrumentation:


It monitors the untrusted program and enforces security policies
Manual, sourcecode
Feedback:
 Feedback (enforcement) is integrated into the language
Enforcing Policy in Edit
Automata

List of monitored actions or operations


Specify what to do when an application is about to invoke
a monitored action
When it recognizes a dangerous action, it may



halt the application
suppress (skip) the operation but allow the application to
continue
insert (perform) some computation on behalf of the
application
Edit Automata
app’s requested action
executed action:
allowed, inserted
Example: Atomicity


Program: Apple Market-Client
Policy: Atomicity Apple Market
3 Works on Edit Automata

Edit automaton is a high-level concept for
evaluating process with feedback


Policy Calculus is a language based on the edit
automaton concept


Analogous to Alternating Automata in SB’05
Analogous to LTL in SB’05, ex. ¬p1 U p2
Polymer is a prototype language based on Policy
Calculus for monitoring Java programs

Analogous to Until( Not(p1), p2);
Policy Calculus

Policy: Memory quota
fun mpol(quota:int). {
actions: malloc();
policy:
next 
case * of
malloc(n) 
if (quota > n) then
ok; run (mpol (quota-n))
else
halt
end
}
List of actions
Policy
Polymer

Policy: Limit # of opened files and its path
policy limitWriter(int maxopen) =
actions = { java.io.FileWriter(String path);
java.io.FileWriter.close(); }
state =
{ int cur = 0; }
policy = {
aswitch {
case java.io.FileWriter(String path) :
if (cur >= maxopen) suppress;
if (path.startsWith(``\tmp'')) {
cur++; ok;
}
else {
emit(System.err.println(``Can't open.''));
suppress;
}
case java.io.FileWriter.close() :
cur--;
}
}
List of actions
Variables
Policy
Polymer Instrumentation

Method Warpper


All calls (actions) to monitored methods are redirected to
the runtime monitor
The runtime monitor then evaluates the action


If ok, the original method call is made and returned
If suppress, it throws a SuppressionException



Program must handle the exception
If insert, it executes inserted operation
If halt, it terminates the program
Outline


Overview of runtime monitoring
Runtime Verification



Security




Temporal Assertions using AspectJ [Stolz,Bodden05]
Eagle [Barringer et al. 04]
Edit Automata [Bauer et al. 03]
Eagle for Intrusion Detection [Naldurg et al. 2004]
Comparison and Analysis
Conclusion
Intrusion Detection using
EAGLE

Intrusion Detection



Anomaly-based
 Define normal behaviors
 Any behavior deviates from normal behaviors is an
intrusion
Signature-based
 Define patterns of bad behaviors or attacks
 Anything fits the patterns is an intrusion
Naldurg et al. use Eagle


Signature-based Intrusion Detection
Use Eagle to specify attack patterns
DoS Attack

Create DoS attack by sending a forged “ping”
message with a victim’s IP address as a
sender to a broadcast IP address


Large number of response can cause DoS
Eagle


max Attack() = (type = “ping”) ∧ isBroadcast(ip)
mon DoSSafety = Always(¬ Attack())
Summary
Language
Spec
Evaluation
Instrument
Feedback
SB’05
LTL
Alternating
Automata
AspectJ:
Automatic,
Bytecode
AspectJ, Userdefined
Eagle
Eagle (LTL,
Regular
Expression, MTL,
Context Free
language)
Direct Algorithm
-
-
Edit
Automata
Security Policies
DFA – Edit
Automata
Method wrapper:
Manual,
Sourcecode
Fixed: suppress,
insert, halt
Language

Expressiveness




SB’05 LTL
Eagle
Edit Automata DFA
 Eagle
Abstraction Level

Implementation: SB’05 (pointcut), Edit Automata (Java method
call)


Specific particular programming language
Design: Eagle (variable)

General and for any programming language
Spec Evaluation Process

Execution time depends on specification language


More expressive, higher complexity
For each input, for a formula f of size m (m subformulae)

Edit Automata: O(m)


DFA
SB05: ≈ O(2m)


Number of states in the AFA Af is O( m )
SB05 translates AFA (which is essentially NFA) into DFA


Translating NFA into DFA exponentially blows up the number of DFA states
Eagle:

LTL: ≈ O(2m)



Transforming an LTL f to another LTL f’ to hold in the next state
At most 2m possibilities to combine m subformulae in a conjunction or disjunction for f’
General: (with data-values) depends on both


the size of the formula.. At least W(2m)
the length of the trace
Why Checking LTL is ≈ O(2m)

Checking Past-LTL is O(m)




Look at history
Can say satisfied, or not satisfied
Deterministic
Checking Future-LTL is ≈ O(2m)



Waiting for future trace
Cannot say now whether satisfied, or not satisfied
 Need to keep track of what we have seen and what we are
waiting for
Non-deterministic
Why Eagle general checking time
depends on length of trace

Ex. “whenever at some point x > 0, then eventually y = x".

Eagle:



After x becomes > 0 and keeps changing its value, e.g.,








min R(int k) = Eventually(y = k)
mon M = Always (x > 0  R(x))
s0 = {x = 0, y = 0}
s1 = {x = 1, y = 0}
s2 = {x = 2, y = 0}
s3 = {x = 3, y = 0}
s4 = {x = 4, y = 0}
s5 = {x = 5, y = 0}
s6 = {x = 6, y = 2}
At s6, the result of the eval function (what need to hold next state) becomes

Eventually(y=1) /\ Eventually(y=3) /\ Eventually(y=4) /\ Eventually(y=5) /\
Eventually(y=6) /\ Always(x>0  R(x))
Other Runtime Monitoring

Various Specification Language



LTL, MTL, regular expression, Real-Time Logic,
Timed-LTL, probabilistic, etc…
Multithreaded and Distributed Monitoring
Toward First-Order Logics
Conclusion

Runtime monitoring based on formal
specification



Runtime verification
 SB’05 checking LTL using AspectJ
 Eagle checking LTL, MTL, RE, no instrumentation
Security
 Edit Automata enforcing security policies
 Eagle for signature-based intrusion detection
Discussion
Reference

[Eagle]


[SB05]


Volker Stolz and Eric Bodden. Temporal Assertions using AspectJ. In
Proceedings of the 5th International Workshop on Runtime Verification, 2005
[Edit Automata]


Howard Barringer, Allen Goldberg, Klaus Havelund and Koushik Sen. RuleBased Runtime Verification. In Proceedings of the 5th International
Conference on Verification, Model Checking, and Abstract Interpretation,
2004
Jay Ligatti, Lujo Bauer, and David Walker. Edit Automata: Enforcement
Mechanisms for Run-time Security Policies. Technical report, Princeton
University, Computer Science Department, May 2003.
[Intrusion Detection]

Prasad Naldurg, Koushik Sen, and Prasanna Thati. A Temporal Logic Based
Approach to Intrusion Detection. In Proceedings of the International
Conference on Formal Techniques for Networked and Distributed Systems
(FORTE 2004), 2004.
Q&A
Q: Eagle Toward CFL

Eagle also provide concatenation

F :: = expression | true | false
| ¬F | F1 ∧ F2 | F1 ν F2 | F1  F2
|

○F
| N(F1, …, Fn) | xi | F1 · F2
Example: match a sequence of login, logout

Define a rule Match, and monitor Match(login,logout)
min Match(Form F1, Form F2) =
F1 · Match(F1,F2) · F2 · Match(F1,F2) ν Empty()
max Empty() = ¬○ true
True when evaluated on an
empty (suffix) sequence
Q: Eagle Regular Expression

Eagle also provide concatenation


E ::= Ø | e | a | E · E | E + E | E*


F :: = expression | true | false
| ¬F | F1 ∧ F2 | F1 ν F2 | F1  F2
| ○F | N(F1, …, Fn) | xi | F1 · F2
Write each syntax using Eagle formula
Let Tr(E) denote the regular expression E’s corresponding Eagle Formula
max Empty() = ¬○ true
Tr(Ø) = false
Tr(e) = Empty()
Tr(a) = a ∧ ○Empty()
Tr(E1 · E2) = Tr(E1) · Tr(E2)
Tr(E1 + E2) = Tr(E1) ν Tr(E2)
Tr(E*) = X() where max X() = Empty() ν (Tr(E) · X())

Example: a* · (b + c)


mon M = AStar() · (b ν c)
max AStar() = Empty() ν (a · AStar())
True when evaluated on an
empty (suffix) sequence
Q: Eagle m-Calculus

Eagle can be use to specify m-Calculus

Example

m-Calculus


n x. (p ∧ ○○x ∧ m y.( q ∧ ○x))
Eagle

max X() = p ∧ ○○X() ∧ Y()
min Y() = q ∧ ○X()
Q: LTL  AFA Example
{p}
{p}
T((false R p),{p})
{p}
(false R p) U q
T(p,{p})
{p}
T(q,{p})



{p}

true
{p}
{p}
(false R p) U q
false R p
false
T(p, Prop) = true if p Prop
T(p, Prop) = false if p  Prop
T(f1 U f2, Prop) = T(f2, Prop) ν (T(f1, Prop) ∧ (f1 U f2))
T(f1 R f2, Prop) = T(f2, Prop) ∧ (T(f1, Prop) ν (f1 R f2))
false R p
= (T(f2, Prop) ∧ T(f1, Prop)) ν (T(f2, Prop) ∧(f1 R f2))
= (T(p, {p}) ∧ T(false, {p})) ν (T(p, {p}) ∧(false R p))
Q: Eagle Eval Example

The result of eval function is a new set of formulae to be held in the next state

eval( Always(x > 0  Eventually(y > 0)), s )

eval( (x > 0  Eventually(y > 0)) ∧ ○Always(x > 0  Eventually(y > 0)), s )
eval( x > 0  Eventually(y > 0), s )
∧


eval( ○Always(x > 0  Eventually(y > 0)), s )
( eval( x > 0, s )  eval( Eventually(y > 0), s ) )
Always(x > 0  Eventually(y > 0))

(x > 0  eval( (y > 0) ν ○Eventually(y>0), s) )
Always(x > 0  Eventually(y > 0))


∧
∧
(x > 0  ( eval(y > 0, s) ν eval( ○Eventually(y>0), s ) ) )
Always(x > 0  Eventually(y > 0))
(x > 0  (y > 0 ν Eventually(y>0))) ∧
Always(x > 0  Eventually(y > 0))
∧
Q: Eagle Eval Example
(continue..)

The result of eval function is a new set of formulae to be held in the next
state

(x > 0  (y > 0 ν Eventually(y>0))) ∧
Always(x > 0  Eventually(y > 0))

If state s = { x = -1, y = 0}, then




(false  (false ν Eventually(y >0))) ∧ Always(x > 0  Eventually(y > 0))
true
∧ Always(x > 0  Eventually(y > 0))
Always(x > 0  Eventually(y > 0))
If state s = { x = 1, y = 0}, then



(true  (false ν Eventually(y >0))) ∧ Always(x > 0  Eventually(y > 0))
(false ν Eventually(y >0))
∧ Always(x > 0  Eventually(y > 0))
Eventually(y >0)
∧ Always(x > 0  Eventually(y > 0))
Q: Eagle Execution Time –
Depending on Trace Length

Ex. “whenever at some point x = k > 0 for some k, then eventually y = k".

Eagle:



After x becomes > 0 and keeps changing its value, e.g.,








min R(int k) = Eventually(y = k)
mon M = Always (x > 0  R(x))
s0 = {x = 0, y = 0}
s1 = {x = 1, y = 0}
s2 = {x = 2, y = 0}
s3 = {x = 3, y = 0}
s4 = {x = 4, y = 0}
s5 = {x = 5, y = 0}
s6 = {x = 6, y = 2}
At s6, the result of the eval function (what need to hold next state) becomes

Eventually(y=1) /\ Eventually(y=3) /\ Eventually(y=4) /\ Eventually(y=5) /\
Eventually(y=6) /\ Always(x>0  R(x))
Q: Overhead

Instrumentation


Depending on how often the extraction is
Evaluation Process

Depending on the specification language
Q: Multithreaded and
Distributed Monitoring

Multithreaded





Formula on shared variables
Thread T1 { … x++;
… y = x+1; … }
Thread T2 { … z = x+1; … x++;
…}
(x > 0)  [ (x = 0), y > z)
Distributed



No shared variables, only asynchronous messages
Operator @: evaluate a formula in the last known state of a remote process
Ex. “the server accepts the command to reboot only after knowing that each
client is inactive and aware of the warning about pending reboot”


Local to server
rebootAccepted  ∧client (@client (inactive ∧ @server rebootWarning))
Q: Actual Eagle LTL Checking
Time

Time: O(m4 22m log2m)

Transforming an LTL f to another LTL f’ to hold in the next state
Assume | f | = m



f has m subformulae
Space:

The size of the LTL f’ can be O(2m)




There are at most 2m possibilities to combine them in a conjunction or disjunction
Space requirement for each conjunction is O(m2 log m)
Hence, space complexity is O(m2 2m log m)
Time:


At each node, it can possibly spend O(m2 2m log m) time to do conjunction and
disjunction
Since the space complexity is O(m2 2m log m), the time complexity is O(m2 2m log m) x
O(m2 2m log m) = O(m4 22m log2 m)
Q:

Placement of Specification Language


All: Separate entities
 Modular
If embedded within the specification language
 For example, specification is embedded as comments,
which require a special compiler