Doina Bucur. Temporal Monitors for

Transcription

1 Doina Bucur / Temporal Monitors for 1

2 Application area: wireless sensor/actuator systems running TinyOS, a best-effort, asynchronous embedded OS In summary: 2

3 Application area: wireless sensor/actuator systems running TinyOS, a best-effort, asynchronous embedded OS Specifications: qualitative temporal (LTL) with: atomic propositions = { boolean expressions over variables; checkpoints, including interrupts } In summary: 2

4 Application area: wireless sensor/actuator systems running TinyOS, a best-effort, asynchronous embedded OS Specifications: qualitative temporal (LTL) with: atomic propositions = { boolean expressions over variables; checkpoints, including interrupts } Verifier: native TinyOS software component quantified overhead emulation: absolute RAM and CPU overhead per monitor is negligible; ROM overhead for a basic LTL pattern is ~5.5% of that available on a Telos revision B platform. In summary: 2

5 : A network embedded OS [1999] Born at UC Berkeley, under the DARPA Network Embedded Systems Technology (NEST) project. First public version in

6 : A network embedded OS [1999] Born at UC Berkeley, under the DARPA Network Embedded Systems Technology (NEST) project. First public version in [2000] Berkeley designs a platform; Crossbow, Inc., mass produces the hardware. 3

7 : A network embedded OS [1999] Born at UC Berkeley, under the DARPA Network Embedded Systems Technology (NEST) project. First public version in [2000] Berkeley designs a platform; Crossbow, Inc., mass produces the hardware. [2002] Network embedded system C (nesc) is developed, Intel Research / UC Berkeley. 3

8 RS2!-)+,/H&$!76<!"#$%"&'() O#,,%O$# RS2 (#,,%O$#) : A network embedded OS [1999] Born at UC Berkeley, under the DARPA Network Embedded Systems Technology (NEST) project. First public version in RS2!1%O%&'%!76<?U*&,!S^S O#,,%O$#) 76</ Y-:Z O#,,%O$#) RS2 "&O)#O#,$)#..%) [ ((?C?B 1+I&# <&D&$+.!/K&$O= wireless-sensor-networks/wireless- 8/#.+$&,D!RS2!F)#H H&O)#O#,$)#..%) modules.html ] -%V+/!8,/$)JH%,$/ "S5CEB![>W>> CGUP&$!/&.&O#, H&O)#O#,$)#..%) /%)&+.!8< S": :,$%,,+ (#,,%O$#)!"#$%"&'() [2000] Berkeley designs a platform; Crossbow, Inc., mass produces the hardware. [2002] Network embedded system C (nesc) is developed, Intel Research / UC Berkeley. RS2 [.+/=!0?\23 E?\X] #/O&..+$#) S-!(#I% [.+/=!0>"23! 0,1$+&'2'3'0+"/.'4/#'54*6'"7'.8&'9&%")':"#$%&' "#$%&'!(#)*#)+$&#,!! -%.#/!01%'!23!4!51678"89:1;!<+$+/=%%$!0>?@A@?BBC3! 3

9 O#,,%O$#!"#$%"&'() RS2!-)+,/H&$!76< RS2 (#,,%O$#) : A network embedded OS RS2!1%O%&'%!76< [1999] Born at UC Berkeley, under the DARPA Network Embedded Systems Technology (NEST) project. First public version in RS2 76</ ((?C?B S": [ "&O)#O#,$)#..%) 1+I&# :,$%,,+ <&D&$+.!/K&$O= Y-:Z wireless-sensor-networks/wireless(#,,%o$#) 8/#.+$&,D!RS2!F)#H O#,,%O$#)!"#$%"&'() H&O)#O#,$)#..%) modules.html ] -%V+/!8,/$)JH%,$/ "S5CEB![>W>> H&O)#O#,$)#..%) CGUP&$!/&.&O#, /%)&+.!8<?U*&,!S^S O#,,%O$#) [2000] Berkeley designs a platform; Crossbow, Inc., mass produces the hardware. [2002] Network embedded system C (nesc) is developed, Intel Research / UC Berkeley. "#$%&'!(#)*#)+$&#,!! 3 RS2 [.+/=!0?\23 E?\X] #/O&..+$#) S-!(#I% [.+/=!0>"23! 0,1$+&'2'3'0+"/.'4/#'54*6'"7'.8&'9&%")':"#$%&' -%.#/!01%'!23!4!51678"89:1;!<+$+/=%%$!0>?@A@?BBC3! [ lifeunderyourfeet.org / Microsoft Research Sensor Map ]

10 high-level logic nesc is modular TinyOS application TinyOS system components Hardware HPL 4

11 high-level logic nesc is modular TinyOS application TinyOS system components Hardware HPL 4

12 ...with interrupt-based concurrency calls command startperiodic() signals event fired() Event handlers execute with priority. A single interrupt level. Events may cascade on some platforms....with sequential event handlers, plus deferred computational tasks. 5

13 Native verifier in TinyOS TinyOS application TinyOS system components Runtime path verifier Hardware The verifier is a new OS component (offline, generated). 6

14 Instrumentation NesC instrumentation (offline, manual): events rooted in hardware interrupts, software conditions or checkpoints; tested with 60+ through the OS nesc events signaled to verifier; signaling time as per system load 7

15 configuration HplMsp430GeneralIOC { [..] } Instrumentation implementation { [..] components PaxLTLC; NesC [..] instrumentation (offline, manual): events rooted in hardware interrupts, software conditions or checkpoints; PaxLTLC.notify tested with <-60+ P10.pax_notify; through the OS PaxLTLC.notify <- P11.pax_notify; nesc PaxLTLC.notify events signaled <-to P12.pax_notify; verifier; signaling time as per system load } // where P10, P11, etc are instantiations of HplMsp430Gene [..] generic module HplMsp430GeneralIOP([..]) { [..] uses async event void notify(uint16_t ap, bool val); } implementation { [..] async command void IO.set() { [..] signal pax_notify((portx*10+pin), TRUE);} async command void IO.clr() { [..] 7

16 System specifications Low visibility of system faults in deployments. There exists a broad but incomplete set of system specifications, fault reports node-local / distributed 8

17 System specifications Low visibility of system faults in deployments. There exists a broad but incomplete set of system specifications, fault reports node-local / distributed Buffer and stack overflows, deadlocked/livelocked software, data races. 8

18 System specifications Low visibility of system faults in deployments. There exists a broad but incomplete set of system specifications, fault reports node-local / distributed Buffer and stack overflows, deadlocked/livelocked software, data races. No next-hop destination for routing in a multihop network; unexpected value, outlier or gradient in sensed data or battery level; incorrect order of use of the OS kernel s API. 8

19 LTL patterns (basic) # Universality. p is true : # (F01) Globally [](p) # (F02) Before r <>r -> (p U r) # (F03) After q [](q -> [](p)) # (F04) Between q and r []((q &!r & <>r) -> (p U r)) # (F05) After q until r [](q &!r -> (p W r)) # Precedence. s precedes p: # (F16) Globally!p W s # (F17) Before r <>r -> (!p U (s r)) # (F19) Between q and r []((q &!r & <>r) -> (!p U (s r))) # (F20) After q until r [](q &!r -> (!p W (s r))) Between an timer alarm and the next one there must be new sensor data. Every time a LED is on, it must have been preceded by the sending of a packet. 9

20 [..] g. 3. Wiring and instrumentation added to the HPL components which control t crocontroller pins on the TelosB; the logging is done by signalling the notify eve istence-after (E-A), etc, and we omit them from the evaluation results. ese, we add two composite properties which are practically useful: k_ i=1 LTL patterns (composed) Gp i and a generic event-sequence chain p 1 U(p 2 U(...Up k )) d also multiple basic monitors checking the same application. Into these property types, we randomly input combinations of atomic prop ions from our list of relevant system events. The resulting specifications a her violated or satisfied by the system software; our monitors will repo ether the checking In both has cases, finished randomly (thusgenerated a violation formulas. was encountered) in re e, at the end of each monitoring step variable finished checking e monitor implementation from Fig. 5 records the verification status, and orted Doina Bucur, to RV 12 the system users. 10

21 Monitor generation 2 r s 1!p &!r &!s p &!r &!s 1 3!r F r (!p U ( s r )) Fig. 4. Deterministic monitor generated for the speci- (Precedence pattern, Before scope) fication F r! (!p U ( s r )). Generated with a LTL-to-TGBA State 1 is the initial state, and translator (part of SPOT). each transition is accepting. Deterministic, all transitions accepting. implementation { async event void notify(uint16_t ap, bool val) { // store (ap, val) if (!finished_checking) post step(); } task void step() { atomic { // calculate new state with (ap, val) current_checking_steps++; current = next; next = -1; if (current == 1) { if ((call statebv.get(r)) (call statebv.get(s))) next = 2; else if ((call statebv.get(p)) &&!(call statebv.get(r)) &&!(call statebv.get(s))) next = 3; else if (!(call statebv.get(p)) &&!(call statebv.get(r)) && 11

22 r s p &!r &!s } Monitor 2 generation 2 r s 1 3!r Fig. 4. Deterministic monitor generated for the specification F r! (!p U ( s r )). State 1 is the initial state, and each transition is accepting. 1!p &!r &!s p &!r &!s 1 3!r F r (!p U ( s r )) Fig. 4. Deterministic monitor generated for the speci- (Precedence pattern, Before scope) fication F r! (!p U ( s r )). Generated with a LTL-to-TGBA State 1 is the initial state, and translator (part of SPOT). each transition is accepting. Deterministic, all transitions accepting. task void step() { atomic { // calculate new state with (ap, val) current_checking_steps++; current = next; next = -1; if (current == 1) { implementation { async event if ((call void notify(uint16_t statebv.get(r)) ap, (call statebv.get(s))) bool val) { // store next (ap, = val) 2; if (!finished_checking) else if ((call statebv.get(p)) && post step();!(call statebv.get(r)) && }!(call statebv.get(s))) next = 3; task void else step() if (!(call { statebv.get(p)) && atomic {!(call statebv.get(r)) && // calculate!(call new state statebv.get(s))) with (ap, val) current_checking_steps++; next = 1; current } = next; next = -1; else if (current == 2) { if (current next = 2; == 1) { } if ((call statebv.get(r)) else(call if (current statebv.get(s))) == 3) { if next (!(call = 2; statebv.get(r))) else next if ((call = 3; statebv.get(p)) && }!(call statebv.get(r)) && finished_checking!(call statebv.get(s))) = (next == -1); }}} next = 3; else if (!(call statebv.get(p)) && 11!(call statebv.get(r)) &&

23 Tool chain AP set LTL: [](q -> [](p)) SPOT r s 1!p &!r &!s p &!r &!s implementation { async event void notify(uint16_t bool val) { // store (ap, val) if (!finished_checking) post step(); } TinyOS application TinyOS system components AP set Hardware !r language translator Fig. 4. Deterministic monitor generated for the specification F r! (!p U ( s r )). State 1 is the initial state, and each transition is accepting. Runtime path verifier ncc binary task void step() { atomic { // calculate new state with ( current_checking_steps++; current = next; next = -1; if (current == 1) { if ((call statebv.get(r)) (call statebv.get(s))) next = 2; else if ((call statebv.get!(call statebv.get(r!(call statebv.get(s next = 3; else if (!(call statebv.ge!(call statebv.get(r!(call statebv.get(s next = 1; } else if (current == 2) { next = 2; } notification else if (current == 3) { and trace if (!(call statebv.get(r)) next = 3; } finished_checking = (next == emulator

24 Evaluation For CPU and stack overhead: emulator (MSPsim for TelosB). For (other) memory overhead: compilation to executable suffices (there is no dynamic allocation). 13

25 Monitor size Kilobytes ROM overhead (TelosB) RAM overhead (TelosB) Bytes Automaton size (no. states x no. transitions) 14

26 CPU overhead 1.25 CPU overhead (TelosB) Added load % Timeline in duty cycle x 20ms Accurate to the clock tick (advantage of emulating), modulo sampling rate. 15

27 Kilobytes ROM overhead (TelosB) ROM overhead (MicaZ) U-G U-B U-A U-W U-AB A-G A-B A-A A-W A-AB E-G E-B E-A E-W E-AB P-G P-B P-A P-W P-AB R-G R-B R-A R-W R-AB BE-G BE-B BE-A BE-W BE-AB LTL property pattern and scope ROM overhead 16

28 30 RAM overhead (TelosB) RAM overhead (MicaZ) Bytes U-G U-B U-A U-W U-AB A-G A-B A-A A-W A-AB E-G E-B E-A E-W E-AB P-G P-B P-A P-W P-AB R-G R-B R-A R-W R-AB BE-G BE-B BE-A BE-W BE-AB LTL property pattern and scope RAM overhead 17

29 18