Verification and Power Analysis of TinyOS with Hybrid Automata

1. Verification and Power Analysis of TinyOS with Hybrid Automata Sinem Coleri Mustafa Ergen EECS EECS csinem@eecs.berkeley.edu ergen@eecs.berkeley.edu

2. Outline • Introduction • TinyOS • TinyOS characteristics • Hytech • Hytech Description • Verification of TinyOS • Power Analysis of a TinyOS sensor node • SHIFT • SHIFT description • Power Analysis of a Sensor Network • Conclusion

3. Introduction • Why need sensor networks? • Monitoring environment • What is the characteristic of sensor networks? • Deploy once and leave without future maintenance • Why need verification? • Guaranteed correct operation in every circumstance. • Why need power analysis? • Predict the lifetime. • What type of modelling? • Discrete events and continuous activities: Hybrid Automata • What are the tools? • HyTech for verification, SHIFT for simulation • What are the metrics? • Power consumption of a single node • Lifetime of the network

4. TinyOS • Component-based • Modularity by assembling just the software components to synthesize app. from hardware components • Components as reentrant cooperating state machines • Event-based • Components communicating through events and commands • Power efficient • Spending unused CPU cycles in sleep • Turning radio off when not is use

5. Complete TinyOS application • Scheduler • Graph of components • Each component has • Interface(.comp) • Internal Implementation(.c)

6. Complete TinyOS application: Component • Interface comprises of synchronous commands and asynchronous events • Upper Interface • Commands it implements • Events it signals • Lower Interface • Commands it uses • Events it handles • Internal Storage • Fixed-size frame containing the state of component • Internal Implementation • Light-weight threads – tasks • Command and event handlers

7. Description of Application • Describes the wiring of the interfaces • Efficient modularity • Optimization by static info

8. sensing application application packet Radio Packet Radio byte byte SW photo HW RFM ADC bit clocks Application Graph of Components

9. Scheduling • Events have higher priority • Events preempt tasks • Almost instantaneous event execution • Not wait for long latency actions • Small amount of work related to component state

10. Scheduling • Tasks have lower priority • Tasks do not preempt events or other tasks • Scheduled by FIFO scheduler • Handled rapidly without blocking or polling • Unused CPU cycles in sleep state

11. Packet Level Byte Level RFM Bit Level Ex. Communication … post a task Event handling Put processor sleep Task handling

12. Hytech • Hytech inputs • System description • Composition of linear hybrid automata • Temporal Logic Requirement • Hytech outputs • Safety check • Debugging traces

13. From TinyOS to Hytech • TinyOS component -> Hytech automaton • TinyOS event, commands -> Hytech discrete events • TinyOS clock cycle -> Hytech discrete time step • TinyOS energy -> Hytech variable

14. sensing application application transmit_pack receive_pack packet Radio Packet rx_byte_ ready tx_byte_ ready tx_ byte packet_ done_neg packet_ done_pos post_encode byte post_decode Radio byte Task handler rfm_rx_comp rfm_ rx_ev rfm_rx_ comp rfm_ tx_ev rfm_tx_ comp rfm_tx_comp bit RFM rfm_clock rfm_clock Packet generation Overall View of TinyOS Automata

15. Packet Generation and Application Automata Application Packet_generation idle rt>=cbit_time/ rt’=0, pt’=pt+1, sync rfm_clock rt=0,pt=0 at=0 at>=cbetween/ at’=0, sync transmit_pack rt<=cbit_time pt<=cidle drt=1 pt>=cgeneration/ rt’=0, bit’=0, pt’=0, sync rfm_clock at<=cbetween dat=1 pt>=cidle/ rt’=0, bit’=1, pt’=0, sync rfm_clock rt<=cbit_time pt<=cgeneration drt=1 sync receive_pack/ sync trans_packet rt>=cbit_time/ rt’=0, pt’=pt+1, sync rfm_clock generate

16. RFM receive transmit sync rfm_rx_comp/ sync rfm_tx_comp/ drfmt=0 drfmt=0 sync rfm_clock/ rfmt’=0, energy’=energy+crec sync rfm_rx_comp/ sync rfm_clock/ rfmt’=0, energy’=energy+ctrans sync rfm_tx_comp/ rfmt<=crec_handler drfmt=1 drfmt=0 drfmt=0 rfmt<=ctrans_handler drfmt=1 rec_energy rfmt>=crec_handler/ sync rfm_rx_ev rec_wait trans_wait trans_energy rfmt>=crec_handler/ sync rfm_tx_ev RFM Automata

17. Task Handler Automata Task Handler exec dht=0 dct=0 denergy=cactive sync rfm_rx_comp | sync rfm_tx_comp / idle ht<=0/ op dht=0 dct=0 denergy=cinactive ht>=0 dht=-1 dct=0 denergy=cactive sync rfm_clock/ sync rfm_clock/ sync decode/ ht’=cdecode, ct’=0 sync encode/ ht’=cencode, ct’=0 sync decode/ ht’=ht+cdecode, ct’=0 sync rfm_rx_comp | sync rfm_tx_comp / ct<=ctask_post dht=0 dct=1 denergy=cactive dht=0 dct=0 denergy=cactive sync encode/ ht’=ht+cencode, ct’=0 op_wait op_exec ct>=ctask_post/ sync post_task_done

18. Packet Level Byte Level RFM Bit Level Verification of TinyOS with Hytech: Motivation Application … Application assumes that packet is sent successfully transmitting packet level idle idle receiving receiving byte level

19. Verification of TinyOS with Hytech • Analysis commands for verification: init_reg := …..; final_reg := loc[rpacket]=transmit & loc[rbyte]=receive; reached := reach forward from init_reg endreach; if empty(reached & final_reg) then prints “working fine” else print trace to final_reg using reached; endif;

20. Power Analysis of TinyOS with Hytech • Power analysis through variable energy by using trace generation feature of Hytech • by setting • final_reg = t>300000; • by checking variable energy at the end

21. Power Analysis of TinyOS with Hytech • As the number of children increases, • time to wait before transmitting increases due to backoff • number of packets to be forwarded increases BS

22. Power Consumption vs. # of Children

23. SHIFT • Describes dynamic networks of hybrid automata • Components created, interconnected, destroyed as the system evolves • Components interact through their inputs, outputs and exported events

24. Clustering of the Network • Uniform Distribution • 100 node • 100m x 100m • 4 Macro Clusters • Children determined according to position distribution

25. Modeling of a sensor network • 4 Types of Node Automata. • Create an instance for each node. • Destroy the instance when the node dies. • Distribute the load to its group. • Notify upper group when there is a death.

26. Model of a node X – Energy F – from the HyTech result.

27. Result • Need powerful nodes in group 1. • Group 1 suffers from high load and backoff time. • Group 4 dies at the same time.

28. Conclusion • Sensor nodes are aimed to be left without maintenance. • Power is a detrimental concern in sensor world. • Verification is needed for reliability. • Power analysis is needed for the lifetime of the node. • Network power analysis is needed for the lifetime of the network. • Verification and Power analysis with HyTech . • Network power analysis with SHIFT.