towards a reactive model for the power-aware control of an...
TRANSCRIPT
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 /—