07.01.2013 Views

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

Lecture Notes in Computer Science 3472

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

538 Séver<strong>in</strong>e Col<strong>in</strong> and Leonardo Mariani<br />

and the gate set on clos<strong>in</strong>g; is flash<strong>in</strong>g is evaluated to false, is off is evaluated<br />

true, is clos<strong>in</strong>g is evaluated to true and the f<strong>in</strong>al result is false, therefore the<br />

formula has been violated.<br />

Exercise 18.2 (Algorithm Application). Apply the BTT-FMS of Fig 18.4 on the<br />

follow<strong>in</strong>g traces and determ<strong>in</strong>e the result<strong>in</strong>g truth value:<br />

• flash<strong>in</strong>g, clos<strong>in</strong>g, closed, open<strong>in</strong>g, open, clos<strong>in</strong>g, off<br />

• flash<strong>in</strong>g, off, clos<strong>in</strong>g, closed, open<strong>in</strong>g, flash<strong>in</strong>g, open<br />

When a new event is received, a BTT-FSM only need to evaluate at most all<br />

the propositions to compute the next state, so at worst the run-time overhead<br />

is l<strong>in</strong>ear with respect to the number of dist<strong>in</strong>ct variables. The size of the BTT-<br />

FSMs can become a problem when storage is a scarce resource, hence particular<br />

attention is given to the generation of optimal BTT-FSMs. However, the number<br />

of propositions to be evaluated tends to decrease with the number of states, so<br />

the overall monitor<strong>in</strong>g overhead is also reduced. This algorithm is recommended<br />

<strong>in</strong> situations where the monitored LTL formulas are relatively small <strong>in</strong> size.<br />

Future time propositional LTL may not be the most appropriate formalism<br />

for logic based monitor<strong>in</strong>g due to the conceptual contradiction between the f<strong>in</strong>ite<br />

past traces and the logic expressiveness referr<strong>in</strong>g to <strong>in</strong>f<strong>in</strong>ite future. Past time LTL<br />

can be a more natural logic for run-time monitor<strong>in</strong>g, <strong>in</strong> fact safety requirements<br />

are usually expressed by means of past events.<br />

18.5.2 PathExplorer and Past Time LTL<br />

Before present<strong>in</strong>g the algorithm used by PathExplorer to verify requirements<br />

specified by past time LTL [HR02], we briefly rem<strong>in</strong>d the reader of the basic<br />

notions of f<strong>in</strong>ite trace l<strong>in</strong>ear past time temporal logic, and <strong>in</strong>troduce some<br />

operators used by PathExplorer.<br />

Past Time LTL Syntactically, PathExplorer allows the follow<strong>in</strong>g formulas,<br />

where A is a set of “atomic propositions”:<br />

F ::= true | false | A |¬F | FopF Propositional operators<br />

⊙F | ✸· F | ⊡F | F SS F | F SW F Standard past time operators<br />

↑ F |↓F | [F , F )S | [F , F )W<br />

Monitor<strong>in</strong>g operators<br />

The propositional b<strong>in</strong>ary operators op are the standard ones, and the other<br />

operators should be read :<br />

•⊙F as “previously F ”,<br />

• ✸· F as “eventually <strong>in</strong> the past F ”,<br />

• ⊡F as “always <strong>in</strong> the past F ”,<br />

• F1 SS F2 as “F1 strong s<strong>in</strong>ce F2”,<br />

• F1 SW F2 as “F1 weak s<strong>in</strong>ce F2”,<br />

•↑F as “start F ”,<br />

•↓F as “end F ”,<br />

• [F1, F2) as“<strong>in</strong>tervalF1, F2”.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!