1

Mode Selection

Determine when what component is running at what mode

Mode selection is non-trivial Scheduler will be overwhelmed to determine component modes at the

same time! Exploration space of all mode combinations is tremendous Greedy solution may fail mission timing-constraints or power

constraints

Mode selection is worthwhile Exploration spaces exist to improve power reduction and power-

awareness Energy saving ( 5-15%) Cost saving: (10-40%) Ease the task planning and give a more realistic picture

2

Methodology and Design Flow

The whole picture - the integration of: Power-aware scheduler Mode selector Power estimation/profiling tools

Static view

Scheduler

Power Estimator

Initial schedule

modified schedule

Power/timing numberpower profile Power/timing budget

Power/timing budget

Power profile

Mode Selector

3

Application - Mars Rover

Mission-critical embedded system Hard real-time system Composed of COTS component

Electronic: µprocessor, µcontroller, memory,camera, scientific devices, ... Mechanics/thermal: driving motor, steering motor, heaters, … Power sources: solar panel, battery

Power/energy and performance constraints Stringent max power constraint Flexible min power constraint Limited non-rechargeable energy sources Global timing requirement

Limited working window during sol daytime Timing constraint among tasks

Harsh and uncertain working environment Extremely low temperature - affects component behaviors Uncertain environment: winds/obstacles/rugged terrain

4

System Modeling

5

System constraints

System Modeling

Component power model Power modes with overheads

System timing model Constraint graph

Inter-component model Dependency graph

System parameters Environment temperature Surrounding terrain

Component power model

System timing model

Inter-component model

High-level tasks

Schedule w/mode selection

System parameters

6

Component Power Model

Component Power Modes Power modes

Each mode has its own power and timing attributes Constant Profile Function of system parameters

Complex component may have hierarchical modes Microprocessor active-> cache on (off) ->cache settings Microprocessor active-> voltage scaling Microprocessor doze-> clock scaling Microprocessor sleep

Overheads between mode changes Power/energy overhead, e.g. preheating a motor, voltage scaling Timing overhead between mode changes

Parameter-dependent overheads Power/timing overheads are functions of system parameters, e.g. temperature,

terrain Both power and timing overhead can be parameter-dependent

7

Component Model Examples

Examples of component model Driving motor

Microprocessor (PowerPC 603e)

off on0WPower: - 0.1225*T + 1.0

Power: 2.2WTime: (-1.875*T+10)*(T<0) +10*(t>=0)

Power: 0.5WTime: 3

Full power

Doze Nap Sleep

DPM4.0W 3.2W

1.0W 70mW 40mW

10 cycles -

10 cycles -

10 cycles -

10 cycles - 100us + 255 bus clocks + 10 cycles

100us + 255 bus clocks + 10 cycles

t1 + 3 cycles3 cycles t1 + 3 cycles

8

System Timing Model

Constraint graph Characterize the timing relationship

between tasks Model a task with two events

Start event End event

Representation Nodes: events of tasks Directed edges and weights : timing

relations between events Edges between two events:

From start to end From start to start From end to start From end to end

Weights on edges Positive: “no earlier than” Negative : “ no later than”

A.s B.e10

End event of B should be no earlier than 10 time units after the start event of A

A.s B.s-10

Start event of A should be no later than 10 time units after the start event of B

9

System Timing Modeling Example

haz.e drv.e5 cam.s1drv.s10

ppc1.sppc1.e

sci.s1

rf.e

str.s

1

str.e-5

1

-30

Haz: hazard detectorStr: steering motorDrv: driving motorCam: cameraPpc: processorSci: scientific deviceRf : radio frequency modem

Micro Rover example Multiple resources Timing constraints between tasks

5

-10

haz.s

-5 5

sci.e -5

5

rf.s-5 5

-5

cam.e-5

5

10

Inter-component Model

Dependency graph Characterize power modes dependencies among components

Why dependency graph? A distinction between functional modes v.s. resource modes

Functional modes:e.g. camera: high resolution, low resolution Resource modes: voltage/clock scaling modes

A model to bridge the gap between two kinds of modes Help prune out infeasible mode combinations from design space

Representation - directed graph Nodes

Mode level graph modes of component Conjunctive operators: AND, OR, XOR, MUE ( mutual exclusion)…

Component level graph components

Edges: dependencies

11

Inter-component Modeling Example I

Haz: hazard detectorStr: steering motorDrv: driving motor

haz.on

Drv.off

str.off

str.onHaz.off

drv.onOR

str.on

str.offMUE

drv.on

drv.offMUE

Rover Example Components: hazard detector,

driving motor, steering motor Constraints: hazard detector and

the motors should not be working at the same time

Mode combinations

Hazard detector Driving motor Steering motor

M0 Off Off Off

M1 Off On Off

M2 Off Off On

M3 Off On on

M4 On Off off

12

Inter-component Modeling Example II

Micro Sensor Example Components: processor, memory,

RF, sensor Constraints:

Processor is active when both radio and sensor is active

Memory is active only when processor is active

Microsensor architecture

A:ARMM:memoryR: radioS: sensor

S.off

R.offAND A.sleep

S.on

R.rx_txR.rx

XORA.sleepA.idle

A.active M.on

A.idleA.sleep

M.off

13

Inter-component Modeling Example II (cont’d)

Micro Sensor Example Mode combinations given by MIT

group: 5 combinations Mode combination generated from

dependency graph

Add constraint: When sensor is off, all other

component should be off (proactive)

Automatically obtain same results as MIT group

Mode S R A M

M0 On Tx,rx Active On

M1 On Rx Idle Off

M2 On Rx Sleep Off

M3 On Off Sleep Off

M4 Off Tx,rx Active On

M5 Off Rx Idle Off

M6 Off Rx Sleep Off

M7 Off Off Sleep Off

Not given by MIT group

S.offM.off

A.sleepM.off

14

Mode Combination Enumeration- Using Dependency Graph

Component level dependency graph

Obtain a component list by topological sorting Each component is dependent upon

predecessors only.

Enumerating modes

Working with cyclic graph Mode level graph can’t have cycles Break a cycle in component level

graph by removing an edge Topological sorting When a component is dependent on

its successors, let the last successor remember the component

Radio

Sensor

ARM Memory

RadioSensor ARM Memory

off off sleep off

on off sleep off

idle off

on idle off

active on

15

System Parameters and Constraints

Parameters in system model Temperature, terrain Used to characterize

components and their overheads

System Constraints Maximum Power constraint

Constant or power profile (function of time)

Minimum Power constraint Constant or power profile (

function of time) Total energy constraint ( under

working) Mission time (mission deadline)

Temperature (°C) Powe r (W)

0 1.0-40 5.9-80 9.6

Power consumption of Driving motor at different temperatures

16

System Power Representation

Schedule Gantt Chart

Time view Power view

Mode selection Gantt chart

Tasks marked with mode settings

Added non-operating tasks Idle intervals mode change

overheads Power profile view

17

Mode Selection

18

Problem Statement

Problem input A schedule Component library System constraints

Problem output Mode selection for the

components/tasks

Problem statement Find feasible mode selection for the

tasks/idle intervals for the components that meets system power and timing constraints

Mode selector

scheduleComponent library

System constraints

Mode selections

19

Methodology and Work Flow

Exploration techniques Backtracking Cutting exploration space with multi-dimensional constraints

Two steps in design exploration: Find feasible mode selection for operating tasks

Timing constraints Constraint graph Resource slacks Mission deadline

Dependency between tasks Dependency graph

Find feasible mode selections for idle intervals System power/energy constraints: min, max, or power profile Mode change overhead, both time and power overheads

Speedup techniques Sorting component modes with power numbers

20

Application Example

Mars Rover Behaviors and tasks

Moving around on Mars surface Hazard detection, driving and steering

Communicating with the Lander Taking pictures (IMP) Performing scientific experiments (APXS, ASI/MET)

Components in the entire system Hazard detector (HAZ), Driving motor (DRV) Steer motor (STR) Radio frequency modem (RF) Camera (CAM) Microprocessor (PPC), Micro-controller (MC)

A schedule of the electronic subsystem of micro rover

21

Results - I

Non-Mode Selection solutions Only two modes:On and off Relaxed constraints:

Modes are selected to satisfy timing constraints

Power constraints may be violated Mode change overheads are

considered

Compare mode selection with non-mode selection Mode selection energy saving:

From 3.7% to 11.9% Average 8.7%

power constraints Mode selection satisfies all max

power constraints (14W) Non-mode selection fails all max

power constraints

1300

1350

1400

1450

1500

1550

1600

1650

1700

1750

5 6 7 8 9 10

Mode Selection

On&Off

22

Result II

Compare mode selection with non-mode selection Cost saving:

Cost defined as energy above minimum power constraints

From 6.9% to 49.3% average 26.5%

23

Exploring Different Working Scenarios

Explore different working scenarios and compare results Three tasks

Moving around (MOV) Taking picture (CAM) Scientific experiment (SCI)

Three scenarios A: MOV, CAM, SCI B: CAM, MOV, SCI C: CAM, SCI, MOV

Temperature profile is given as:

Temperature

-90

-80

-70

-60

-50

-40

-30

-20

-10

0

1 2 3 4 5 6

123456

24

Result III

Different working scenarios have different energy consumption Scenario C consumes 12%

more energy than scenario A (by mode selection)

Mode selection always does better than simply two power modes( on&off)

0

5000

10000

15000

20000

25000

A B C

Mode SelectionOn&off

25

Tool Prototype

Language Python, Tkinter

Graphical User Interface Features

Time window and power window View tasks, overheads, power profile Interactive command line

Dynamically load schedule, component library, or even algorithm Interactive schedule modification Interactive constraints modification

Incorporate with the scheduler (to be completed) On-line help (to be completed)

26

Graphical User Interface