Towards a Reactive Model for the Power-AwareControl of an Embedded Platform

(Work in progress. . . )

Nicolas Berthier

October 23, 2009

1 / 23

Outline

ContextTarget platforms & applicationsProblems

Current solutionsAd-Hoc solutionsDedicated Operating SystemsConclusion

ApproachPreliminary remarksPrinciplesPros & Cons

Conclusion

2 / 23

Outline

ContextTarget platforms & applicationsProblems

Current solutionsAd-Hoc solutionsDedicated Operating SystemsConclusion

ApproachPreliminary remarksPrinciplesPros & Cons

Conclusion

3 / 23

Target platforms

I µ-ControllerI Sleep/low-power modes and fast wake-up timeI Possibly DV(F)S capable

I Radio transceiver

I Real-time clock

I Sensors (Temperature, Humidity. . . )I Battery-operated

I Possibly solar-reloadable

I . . .

4 / 23

Target platforms (contd.)

Energy vs. Power

I Energy-awareness: control average current consumptionI related to discharge profile

I Power-awareness: control maximum current consumptionHighly related to:

I capacityI quality (; cost)

5 / 23

Target applications

I Data acquisitionI PeriodicallyI On demand

I Triggering an alarm on certain events

⇒ In most cases:

I Periodic sensing of environment and/or listening radio channelI Should sleep most of the time

6 / 23

Target applications

I Data acquisitionI PeriodicallyI On demand

I Triggering an alarm on certain events

⇒ In most cases:

t

I Periodic sensing of environment and/or listening radio channelI Should sleep most of the time

6 / 23

Target applications

I Data acquisitionI PeriodicallyI On demand

I Triggering an alarm on certain events

⇒ In most cases:

t

I Periodic sensing of environment and/or listening radio channelI Should sleep most of the time

6 / 23

Problems: distribution

I “Chaotic” global behavior, dynamism

I Debugging

I Shelf life

I Unreliable communications

I Security

I . . .

worse and worse. . .

7 / 23

Problems: “embeddedness”

I Cyber-physical device: closed loop (reliable simulation...?)I Various constraints

I low speedI very small memoryI . . .

I Various peripherals

I . . .

8 / 23

Outline

ContextTarget platforms & applicationsProblems

Current solutionsAd-Hoc solutionsDedicated Operating SystemsConclusion

ApproachPreliminary remarksPrinciplesPros & Cons

Conclusion

9 / 23

Current solutions: ad-hoc solutions

Manual implementation

I Method?

I Toolchain?

I Power management?

I . . .

I Reliability?

10 / 23

Current solutions: dedicated Operating Systems

TinyOS

I Event-driven paradigmI All implemented in nesC

I restricted / extended CI fully component-based approach

I Compiled together with the applications

I Locks ; deadlocks

I Power management: manual & decentralized

I Available on many platforms

; tens of components needed for simple applications. . .

11 / 23

Current solutions: dedicated Operating Systems (contd.)

MANTIS

I Classical programming model

I Supports long-running computations

I Power management by hand

; More efficient than TinyOS when:I long idle periodsI timely processing

12 / 23

Current solutions: dedicated Operating Systems (contd.)

Contiki

I ExokernelI tries to reduce provided abstractionsI instead: use libraries

I Proto-threadsI event-based, stack-lessI optional preemptive multi-threading implemented as a library

I Inter-process communication: event posting

I Power-management by hand (only helped by exposing the size of theevent queue!)

13 / 23

Context: conclusion

⇒ No mechanism allowing global management of the platform!

14 / 23

Outline

ContextTarget platforms & applicationsProblems

Current solutionsAd-Hoc solutionsDedicated Operating SystemsConclusion

ApproachPreliminary remarksPrinciplesPros & Cons

Conclusion

15 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

16 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

16 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

D1 D2 · · · Dn

16 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

D1 ‖ D2 ‖ · · · ‖ Dn

16 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

D1 ‖ D2 ‖ · · · ‖ Dn ‖ C

16 / 23

Approach: preliminary remarks

I Driver ≈ Automaton — In fact, a Transducer:I Inputs = software requests & hardware interrupts / dataI Outputs = software responses & hardware requestsI Reflects the state of the associated device

I Ensuring properties of the whole platform⇒ controlling the drivers behavior

I Controller Synthesis Problem:

D1 ‖ D2 ‖ · · · ‖ Dn ‖ C |= φ

16 / 23

Approach: preliminary remarks (contd.)

Controllable Driver

I Inputs: {reqc , requ}I Outputs: {reqc(), requ()}

reqc/ reqc ()

requ/ requ()

ok: Validation from controller

ack : Refused request handling

17 / 23

Approach: preliminary remarks (contd.)

Controllable Driver

I Inputs: {reqc , requ,ok}I Outputs: {reqc(), requ(),ack}

reqc∧ok/ reqc (),ack

/ requ()requ

ok: Validation from controller

ack : Refused request handling

17 / 23

Approach: preliminary remarks (contd.)

Controllable Driver

I Inputs: {reqc , requ,ok}I Outputs: {reqc(), requ(),ack}

reqc∧ok/ reqc (),ack

/ requ()requ

ok: Validation from controller

ack : Refused request handling

17 / 23

Approach: overview

HW platform

Application task(s)

SW services

HW commandsHW signals

”Reactive” kernel

18 / 23

Approach: overview

HW platform

Application task(s)

SW services

HW commandsHW signals

”Reactive” kernel

Drivers Controller

18 / 23

Approach: overview

HW platform

Application task(s)

SW services

HW commandsHW signals

”Reactive” kernel

Drivers Controller

18 / 23

Approach: overview

HW platform

Application task(s)

SW services

HW commandsHW signals

”Reactive” kernel

Drivers Controller

Enforces globalproperties

Controllable inputs

Uncontrollable inputs

18 / 23

Approach: framework

Properties

Drivers

19 / 23

Approach: framework

Properties

Drivers

ControllerSynthesis

Controller

19 / 23

Approach: framework

Properties

Drivers

ControllerSynthesis

Controller

Kernel

19 / 23

Approach: framework

Properties

Drivers

ControllerSynthesis

Controller

Kernel Applications

Execution

19 / 23

Approach: cons

Cons

I Uncontrollable combinations of platforms & properties

I Very platform-specific properties

I It is still possible to write energy-hungry applications. . . not surprisingly!

20 / 23

Approach: pros

Pros

I Power & Energy -aware “by construction”depending on the properties. . .

I Unchanged application layer

I Concurrency handling by the controller:; No locks ⇒ No deadlocks

I Supports long-running application tasksI Classical programming model

21 / 23

Outline

ContextTarget platforms & applicationsProblems

Current solutionsAd-Hoc solutionsDedicated Operating SystemsConclusion

ApproachPreliminary remarksPrinciplesPros & Cons

Conclusion

22 / 23

Conclusion

I Lack of global control capabilities in current tool-setsI Most often too hard to implement

I Global control of the platformI Concurency handlingI Power & Energy management

I Towards a “Real-Energy Programming” paradigm

I Proof-of-concept implementation (in progress)I Realistic application

23 / 23

Thank you

Questions ?

24 /—