1. Modeling Event-Based Systems in Ptolemy II EE249 Project Status Report
Elaine Cheong
Yang Zhao
November 20, 2001

2. Diversity in Design and Usage
Introduction
Networked sensors
Small physical size
Low power consumption
Concurrency-intensive operation
Diversity in Design and Usage
Application specific, not general purpose
Efficient modularity
Robust Operation
Numerous, unattended, critical
Narrow interfaces
TinyOS
Smart Dust
Prof. Pister
Can be deeply embedded in the physical world and spread throughout the environment.
Passively watching for a significant change (or event) in the environment or system.
Bursts of activity (concurrency intensive) during operation.
Design space
Current general-purpose operating systems are not good enough for networked sensors.
TinyOS is an event-based operating environment designed for use with embedded networked sensors.
Designed to support concurrency intensive operations with minimal hardware requirements. 
(v. thread-based).

3. TinyOS Architecture
TinyOS contains a two-level scheduler and a graph of components
Component:
Frame
Event handlers
Command handlers
Tasks
Constrained storage model
Frame per component, shared stack, no heap
Relationship
Event: commands, tasks, events
Command: commands, tasks
Task: commands, tasks
TinyOS uses a component model that is based on the system’s initial concept of wiring software components together to produce a working program.
Frame (storage)
Components can issue commands to lower-level components.
Events can signal higher-level events or call lower-level commands.
A component presents three abstractions of computation: Events, Commands, and Tasks.
At the lowest level, an event occurs because of an interrupt; it is executed synchronously.
A command represents a function call; it is executed synchronously.
A task represents a long-running computation; it is executed asynchronously.
The calling relationship among these three computations is the following:
Events may call commands, post tasks, or signal other events.
Commands may call other commands or post tasks, but may not signal events.
Tasks may call commands or post other tasks, but may not signal events.
Two-level scheduler
Schedule “short” computations (Events and Commands) immediately
Posts “long” computations (Tasks) in a queue
Runs tasks when finished with all higher-level (Events and Commands) scheduling.
A running task may be preempted by events.
A task may not preempt other tasks.

4. Our Goal Study the architecture of TinyOS Model it in Ptolemy II
Explore new models of computation
The Big Picture:
Code Generation

5. How we model it in Ptolemy
RTOS domain with FSM
RTOS domain (Timed Multitasking)
Periodic tasks
Priorities
Modeling TinyOS
Actor for each component
Inputs: Event handlers, Command Handlers
Outputs: Events, Commands
Set the priority of Event Handlers and Command Handlers to be high
Set the priority of Tasks to be low.

6. Next Step
SR domain
Logically, there is an instantaneous dialog between Event handlers and Command handlers.
SR domain has same semantics as Esterel

7. Questions?