Cyber-Physical Programming

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

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)

Sensor Programming

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: http://www.tinyos.net/ Programming language: NesC (an extension of C) It features a component-based architecture. Supported platforms include Linux, Windows 2000/XP with Cygwin.

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

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

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

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.

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.

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.

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

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

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

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 

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(); }

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); }

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)

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

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

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 { ... }

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

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

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

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

TOS Active Messages (continue)

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]; }

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]; }

Further Reading TinyECC Go through the on-line tutorial: http://discovery.csc.ncsu.edu/software/TinyECC/ Go through the on-line tutorial: http://www.tinyos.net/tinyos-1.x/doc/tutorial/index.html Search the help archive: http://www.tinyos.net/scoop/special/support#mailing-lists NesC language reference manual: http://www.tinyos.net/tinyos-1.x/doc/nesc/ref.pdf Getting started guide http://www.xbow.com/Support/Support_pdf_files/Getting_Started_Guide.pdf Hardware manual: http://www.xbow.com/Support/Support_pdf_files/MPR-MIB_Series_Users_Manual.pdf

Install TinyOS and the ‘make’ Download http://www.tinyos.net/download.html 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

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

Android Overview

Android Architecture

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

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.

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

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

Activity Lifecycle

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

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

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().

Service Lifecycle

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.

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.

Broadcast receiver example Broadcast receiver definition Callback on Broadcast receive

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)

Content Provider Example Create database and run transactions on it

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

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

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

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

Reference “Programming TinyOS”, David Culler, Phil Levis, Rob Szewczyk, Joe Polastre University of California, BerkeleyIntel Research Berkeley “TinyOS Tutorial”, Chien-Liang Fok, http://www.princeton.edu/~wolf/EECS579/imotes/tos_tutorial.pdf “Computer Networks”, Badri Nath http://www.cs.rutgers.edu/dataman/552dir/notes/week2-one.pdf