1. 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

2. Outline
Project Goals
TinyOS Architecture
Demo 1
Demo 2
Conclusions

3. 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.

4. 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

5. 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

6. 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;

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

8. 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.

9. Conclusions
DE/FSM
TM/FSM
Future Work