1. Cyber-Physical Programming

2. Interacting With The Physical World
Physical Systems
Embedded Sensing and Actuation
Wireless Sensor Network
Cyber-Physical Systems (CPS) 2

3. CPS System Model Computing Requirements Reliability Accuracy
Computing System
Physical System
Continuous physical process
Computing Requirements
Reliability
Accuracy
Throughput
Security
Safety
Physical Requirements
Safety
Energy efficiency
Low carbon footprint
Multi-dimensional Partial Differential Equations
Discrete Control Algorithm
Actuator
Sensor
Dynamic contexts
Unintended Side Effects
Random Processes
Discrete Control Algorithm
Talk about CPSes
Software failure issues
Characterizing interactions
Fast simulations
Dynamic contexts
Theoretical gurantees
Cyber-Physical Interactions (CPI)
Spatio-Temporal
Aggregate Effects
Dynamic Contexts
Systems with context driven spatio-temporal, aggregate effects are cyber-physical systems (CPS)

4. Sensor Programming

5. What is TinyOS? An operation system
An open-source development environment
Not an operation system for general purpose, it is designed for wireless embedded sensor network.
Official website:
Programming language: NesC (an extension of C)
It features a component-based architecture.
Supported platforms include Linux, Windows 2000/XP with Cygwin.

6. Characteristics of Network Sensors
Small physical size and low power consumption
Concurrency-intensive operation
multiple flows, not wait-command-respond
Limited Physical Parallelism and Controller Hierarchy
primitive direct-to-device interface
Diversity in Design and Usage
application specific, not general purpose
huge device variation
=> efficient modularity
=> migration across HW/SW boundary
Robust Operation
numerous, unattended, critical
=> narrow interfaces
sensors
actuators
network
storage

7. A Operating System for Tiny Devices?
Main Concept
HURRY UP AND SLEEP!!
Sleep as often as possible to save power
provide framework for concurrency and modularity
Commands, events, tasks
interleaving flows, events - never poll, never block
Separation of construction and composition
Programs are built out of components
Libraries and components are written in nesC.
Applications are too -- just additional components composed with the OS components
Each component is specified by an interface
Provides “hooks” for wiring components together
Components are statically wired together based on their interfaces
Increases runtime efficiency

8. TinyOS Architecture HPL: Hardware Presentation Layer
Hardware Platform 1
Hardware Platform 2
Hardware Platform 3
HPL 1
HPL 2
HPL 3
HAL 1
HAL 2
HAL 3
HIL 1
HIL 2
HIL 3
Generic Hardware Interface
Platform Specific Applications
Cross Platform Applications
HPL: Hardware Presentation Layer
HAL: Hardware Adaptation Layer
HIL: Hardware Interface Layer

9. Hardware Presentation Layer
Start and stop commands for the powering up and down the hardware device,
get and set commands to read and write the registers associated with the hardware,
commands for enabling and disabling interrupts generated by the hardware,
service routines for the interrupts often called event handlers, and
customized functions for operating on flags specific to a given hardware component.

10. Hardware Adaptation Layer
The HAL layer of abstraction lies above the HPL layer which further abstracts the basic interfaces provided by HPL for a hardware to task specic interfaces.
For example, if two sensors provide the same Universal asynchronous receiver/ transmitter (UART) interface then, HAL groups them into one.

11. Hardware Interface Layer
HIL is a higher level of abstraction than HAL. It takes the interfaces provided by the HAL and represents them as application specific functionalities.
For example, a HIL can take a sensor and timer component and build a new component that allows interface to periodically query the sensor.

12. Programming TinyOs A component provides and uses interfaces.
A interface defines a logically related set of commands and events.
Components implement the events they use and the commands they provide:
There are two types of components in nesC:
Modules. It implements application code.
Configurations. It assemble other components together, called wiring
A component does not care if another component is a module or configuration
A component may be composed of other components via configurations
Component
Commands
Events
Use
Can call
Must implement
Provide
Can signal

13. Component Syntax - Module
A component specifies a set of interfaces by which it is connected to other components
provides a set of interfaces to others
uses a set of interfaces provided by others
module ForwarderM {
provides {
interface StdControl; }
uses {
interface StdControl as CommControl;
interface ReceiveMsg;
interface SendMsg;
interface Leds;
implementation {
…// code implementing all provided commands and used events
ForwarderM
StdControl
ReceiveMsg
provides
uses
CommControl
SendMsg
Leds

14. Component Syntax - Configuration
configuration Forwarder { }
implementation {
components Main, LedsC;
components GenericComm as Comm;
components ForwarderM;
Main.StdControl -> ForwarderM.StdControl;
ForwarderM.CommControl -> Comm;
ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG];
ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG];
ForwarderM.Leds -> LedsC; }
Component
Selection
Wiring the
Components
together
ForwarderM
StdControl
ReceiveMsg
provides
uses
CommControl
SendMsg
Leds
Main
LedsC
GenericComm
Forwarder

15. Configuration Wires
A configuration can bind an interface user to a provider using -> or <-
User.interface -> Provider.interface
Provider.interface <- User.interface
Bounce responsibilities using =
User1.interface = User2.interface
Provider1.interface = Provider2.interface
The interface may be implicit if there is no ambiguity
e.g., User.interface -> Provider 

16. Interface Syntax- interface StdControl
Look in <tos>/tos/interfaces/StdControl.nc
Multiple components may provide and use this interface
Every component should provide this interface
This is good programming technique, it is not a language specification
interface StdControl {
// Initialize the component and its subcomponents.
command result_t init();
// Start the component and its subcomponents.
command result_t start();
// Stop the component and pertinent subcomponents
command result_t stop(); }

17. Interface Syntax- interface SendMsg
Look in <tos>/tos/interfaces/SendMsg.nc
Includes both command and event.
Split the task of sending a message into two parts, send and sendDone.
includes AM; // includes AM.h located in <tos>\tos\types\
interface SendMsg {
// send a message
command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);
// an event indicating the previous message was sent
event result_t sendDone(TOS_MsgPtr msg, result_t success); }

18. Component implementation
module ForwarderM {
//interface declaration }
implementation {
command result_t StdControl.init()
{ call CommControl.init();
call Leds.init();
return SUCCESS;
command result_t StdControl.start() {…}
command result_t StdControl.stop() {…}
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{ call Leds.yellowToggle();
call SendMsg.send(TOS_BCAST_ADDR, sizeof(IntMsg), m);
return m;
event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success)
{ call Leds.greenToggle();
return success;
Command implementation (interface provided)
Event implementation (interface used)

19. TinyOS Commands and Events{
...
status = call CmdName(args) }
command CmdName(args) {
...
return status; }
event EvtName)(args) {
...
return status; } {
...
status = signal EvtName(args) }

20. TinyOs Concurrency Model
TinyOS executes only one program consisting of a set of components.
Two type threads:
Task
Hardware event handler
Tasks:
Time flexible
Longer background processing jobs
Atomic with respect to other tasks (single threaded)
Preempted by event
Hardware event handlers
Time critical
Shorter duration (hand off to task if need be)
Interrupts task and other hardware handler.
Last-in first-out semantics (no priority among events)
executed in response to a hardware interrupt

21. Tasks Provide concurrency internal to a component
longer running operations
Scheduling:
Currently simple FIFO scheduler
Bounded number of pending tasks
When idle, shuts down node except clock
Uses non-blocking task queue data structure
Simple event-driven structure + control over complete application/system graph
instead of complex task priorities and IPC {
...
post TaskName(); }
task void TaskName {
... }

22. TinyOS Execution Contexts
Hardware
Interrupts
events
commands
Tasks
Events generated by interrupts preempt tasks
Tasks do not preempt tasks
Both essential process state transitions

23. Event-Driven Sensor Access Pattern
command result_t StdControl.start() {
return call Timer.start(TIMER_REPEAT, 200); }
event result_t Timer.fired() {
return call sensor.getData();
event result_t sensor.dataReady(uint16_t data) {
display(data)
return SUCCESS;
SENSE
Timer
Photo
LED
clock event handler initiates data collection
sensor signals data ready event
data event handler calls output command
device sleeps or handles other activity while waiting
conservative send/ack at component boundary

24. Inter-Node Communication
General idea:
Sender:
Receiver:
Determine when
message buffer
can be reused
Fill message
buffer with data
Specify
Recipients
Pass buffer
to OS
OS obtains free
buffer to store
next message
OS Buffers
incoming message
in a free buffer
Signal
application with
new message

25. TOS Active Messages
Message is “active” because it contains the destination address, group ID, and type.
‘group’: group IDs create a virtual network
an 8 bit value specified in <tos>/apps/Makelocal
The address is a 16-bit value specified by “make”
– make install.<id> mica2
“length” specifies the size of the message .
“crc” is the check sum
typedef struct TOS_Msg {
// the following are transmitted
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t length;
int8_t data[TOSH_DATA_LENGTH];
uint16_t crc;
// the following are not transmitted
uint16_t strength;
uint8_t ack;
uint16_t time;
uint8_t sendSecurityMode;
uint8_t receiveSecurityMode;
} TOS_Msg;
Preamble
Header (5)
Payload (29)
CRC (2)
Sync

26. TOS Active Messages (continue)

27. Sending a message Define the message format
includes Int16Msg;
module ForwarderM {
//interface declaration }
implementation {
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{ call Leds.yellowToggle();
call SendMsg.send(TOS_BCAST_ADDR,
sizeof(IntMsg), m);
return m;
event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success)
{ call Leds.greenToggle();
return success;
destination
length
Define the message format
Define a unique active message number
How does TOS know the AM number?
struct Int16Msg {
uint16_t val; };
enum {
AM_INTMSG = 47
File: Int16Msg.h
configuration Forwarder { }
implementation
{ …
ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG];
ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; }

28. Receiving a message Define the message format
includes Int16Msg;
module ForwarderM {
//interface declaration }
implementation {
event TOS_MsgPtr ReceiveMsg.receive(TOS_MsgPtr m)
{ call Leds.yellowToggle();
call SendMsg.send(TOS_BCAST_ADDR,
sizeof(IntMsg), m);
return m;
event result_t SendMsg.sendDone(TOS_MsgPtr msg, bool success)
{ call Leds.greenToggle();
return success;
Message received
Define the message format
Define a unique active message number
How does TOS know the AM number?
struct Int16Msg {
uint16_t val; };
enum {
AM_INTMSG = 47
File: Int16Msg.h
configuration Forwarder { }
implementation
{ …
ForwarderM.SendMsg -> Comm.SendMsg[AM_INTMSG];
ForwarderM.ReceiveMsg -> Comm.ReceiveMsg[AM_INTMSG]; }

29. Further Reading TinyECC Go through the on-line tutorial:
Go through the on-line tutorial:
Search the help archive:
NesC language reference manual:
Getting started guide
Hardware manual:

30. Install TinyOS and the ‘make’
Download
Directory Structure
/apps
/Blink
/Forwarder
/contrib
/doc
/tools
/java
/tos
/interfaces
/lib
/platform
/mica
/mica2
/mica2dot
/sensorboard
/micasb
/system
/types
From within the application’s directory:
make (re)install.<node id> <platform>
<node id> is an integer between 0 and 255
<platform> may be mica2, mica2dot, or all
Example: make install.0 mica2
make pc
Generates an executable that can be run a pc for

31. Build Tool Chain Convert NesC into C and compile to exec
Modify exec with
platform-specific
options
Set the mote ID
Reprogram the
mote

32. Android Overview

33. Android Architecture

34. Application Components
Activities
Services
Broadcast Receivers
Content Providers
Intents
Activities and Tasks
Process and Threads
Remote Procedure Calls

35. Activities
An activity presents a visual user interface for one focused endeavor the user can undertake.
Activity is implemented as a subclass of the Activity base class.
The visual content of the window is provided by a hierarchy of views.
objects derived from the base View class.
A view hierarchy is placed within an activity's window by the Activity.setContentView() method.

36. Activity example Activity definition Create Method callback – For init
Button view inside the Activity

37. Activity Lifecycle An activity has essentially three states
Active or Running
Paused
Stopped
Activity Lifetime
Entire Lifetime [onCreate() to onDestroy()]
Visible Lifetime [onStart() to onStop()]
Foreground Lifetime [onResume() to onPause()]
An implementation of any activity lifecycle method should always first call the superclass version

38. Activity Lifecycle

39. Services
A Service does not have a visual interface and runs in the background.
Each service extends the Service base class.
It's possible to connect to an ongoing service and communicate it through the interface exposed by that service.
Services run in the main thread of the application process.
Examples
Network Downloads
Playing Music
TCP/UDP Server

40. Service example Service definition Message handler queue
Create Method callback – For init

41. Service Lifecycle A service can be used in two ways Service Lifetime
startService() – stopService()
bindService() – unbindService()
Service Lifetime
Entire Lifetime [onCreate() to onDestroy()]
Active Lifetime [onStart()]
The onCreate() and onDestroy() methods are called for all services.
onStart() is called only for services started by startService().

42. Service Lifecycle

43. Broadcast Receivers
A broadcast receiver receive and react to broadcast announcements.
All receivers extend the BroadcastReceiver base class.
Many broadcasts originate in system code.
Broadcast receivers do not display a user interface but they can start an activity or alert user.

44. Broadcast receiver Lifecycle
A broadcast receiver has single callback method
onReceive()
The lifetime of a broadcast receiver is only during the execution of onReceive() method.
A process with an active broadcast receiver is protected from being killed.

45. Broadcast receiver example
Broadcast receiver definition
Callback on Broadcast receive

46. Content Providers
A content provider makes a specific set of the application's data available to other applications.
It’s the only way to transfer data between applications in Android (no shared files, shared memory, pipes, etc.)
All content providers extends the ContentProvider base class.
Content Providers are accessed through ContentResolver object.
Content Providers and Content Resolvers enable inter-process communication (IPC)

47. Content Provider Example
Create database and run transactions on it

48. Intents
Intents are Asynchronous messages used to convey a request or message.
An intent is an object of Intent class that holds the content of the message.
Activities, Services and Broadcast Receivers are activated through Intents.
Intent can contain
Component name
Action
Data
Category
Extras
Flags

49. Intent Examples Intent to start Activity Intent to start Service
Intent to start Broadcast listener

50. Configurable Architectural Model Specification
Health-Dev
Sensor code
Configurable Architectural Model Specification
Model Parser
Code
Generator
Download
Smart phone code
Code Database

51. Trustworthy Data Manager (TDM)
A middleware to provide critical interfaces to MMA.
Intercepts inter-app and external device communication and
Dynamically checks S3 requirements
Mobile OS
App 1
App 2
App3
TDM
Runtime Requirements Validator
Figure showing the databases and model current status
Safety Simulator
Security Simulator
Sustainability Simulator
Current System State
Requirements Database
Sensors
Actuator
Cloud

52. Reference
“Programming TinyOS”, David Culler, Phil Levis, Rob Szewczyk, Joe Polastre University of California, BerkeleyIntel Research Berkeley
“TinyOS Tutorial”, Chien-Liang Fok,
“Computer Networks”, Badri Nath