Elaine Cheong Yang Zhao December 8, 2001 Modeling Event-Based Systems in Ptolemy II EE249: Design of Embedded Systems: Models, Validation, and Synthesis Elaine Cheong Yang Zhao December 8, 2001

Outline Project Goals TinyOS Architecture Demo 1 Demo 2 Conclusions

Our Goals Problem: Our Project: TinyOS applications can be difficult to program and debug. Our Project: Understand TinyOS architecture. Model TinyOS in Ptolemy II. Investigate different models of computation. If you want to change a connection between 2 components, must modify 3 files. Concurrency means it is hard to figure out what portion of the code is currently executing. Simulation and debugging support very primitive.

TinyOS Architecture Component Frame Command handlers Event handlers Messaging Component init Power (mode) TX_packet (buf) TX_packet_done (success) RX_packet_done (buffer) Internal State power(mode) (addr, type, data) send_msg msg_rec (type, data) msg_send_done (success) send_msg_thread Commands Events Component Frame Command handlers Event handlers Tasks

Sample TinyOS Application Component B Internal State event2 Component A Internal State Task 1 Here is a sample application again. The HW clock will trigger event1, the event1 handler of Component A then post task1 to run later and signal event2 to Component B. Then the event 2 handler of Component B will issue a LEDs_ON command down to Component C, which will control a LED to blink. So the function of this app. is pretty simple: once there is a clock interrupt, the LED will have a blink after a short time delay due to the propagation through the components graph. event1 Component C Clock Internal State Internal State LEDs HW clock

Sample TinyOS Code // Component A char TOS_EVENT (Event_1) () { TOS_POST_TASK (Task_1); TOS_SIGNAL_EVENT (Event_2); return 1; }   TOS_TASK () { delay (2s); // Component B char TOS_EVENT (Event_2) () { TOS_CALL_COMMAND (LEDS_on)(); // Component C char TOS_COMMAND (LEDS_on)() { VAR(LEDS_on) = 1;

Demo 1: DE/FSM Discrete Event (DE) domain New actor: PreemptableTask Inputs: Input, Interrupt Output: Output Finite State Machine (FSM) domain Models component logic

Demo 2: TM/FSM Timed Multitasking (TM) domain Formerly known as RTOS Priority-driven multitasking Prioritized event queue Preemption Finite State Machine (FSM) domain Models component logic The timed multitasking (TM) domain, offers a model of computation based on priority-driven multitasking, as common in real-time operating systems. The domain assumes there is a single resource, the CPU, shared by the execution of all actors. At one particular time, only one of the actors can get the resource and execute. The domain provides an event dispatcher, which maintains a prioritized event queue. In TM, one can specify <i>executionTime</i> and <i>priority</i> of an actor. Execution of one actor may be preempted by another eligible actor with a higher priority. If an actor is preempted, it will take some extra time, which equals to the interruption time, to complete. // Showing the model in TM Each component in TinyOS can be modeled by an actor or composite actor. The clock has a period of 2 unit time. It triggers the event1 handler in component A, which post a task in it and signal event2 to component B. Component B then call the LEDs_ON command of component C to control the led to blink. (look inside of Component A), The actor Event_1 models the event1 handler of Cpt A, it is a FSM actor. In fact, generally speaking, each Command or event handler can be modeled by a FSM actor. here we assume command or event handle takes 0.1 unit time to post a task or signal a event or call a command. By setting a higher priority to event handler actors and command actors, setting a lower priority to task actors, we can easily model the feature of the two level scheduling, and the preemption of tasks. It is also able to have a more sophisticated priority-based scheduler for tasks rather than a simple FIFO scheduler currently used in TinyOS.

Conclusions DE/FSM TM/FSM Future Work