2.1. System, Task, and Power-Mode Model
In the developed system, a sensor-node application consists of several non-pre-emptible atomic tasks. Tasks are divided into periodic tasks and sporadic tasks. All tasks are scheduled only when the system is in an ACTIVE state. When the system is put into an INACTIVE state, by either the application or the scheduler, scheduling is prohibited until the system is made ACTIVE by either a wakeup-radio signal or a wakeup-timer. In addition to the task and system model, the power mode model and the operation model of peripheral devices such as sensors and actuators must be considered. The following are descriptions of the task, device, and power-mode models.
Notation 1: A periodic task and its nth periodic execution are denoted by TPi (o, p, w, g, m) and
i is the identifier of a periodic task,
o is the initial offset of a periodic task,
p is the period of a periodic task,
w is the WCET of a periodic task,
g is the guard time of a periodic task, and
m is the power mode requested to run a periodic task.
The guard time of a periodic task is the predefined start-up time needed to enable the power and hardware devices for running. All executions of periodic tasks in the system's ACTIVE mode can be serialized by a schedulability analysis tool [19
] in order to prevent the pre-emption and overlap of executions. Thus, the scheduler can schedule periodic tasks in an on-time FIFO manner and can predict the timing characteristics in regard to their execution. The states of periodic tasks are classified into RUNNABLE and INACTIVE. The state of a periodic task becomes RUNNABLE when the time_left
value in its task control block (TCB) falls into a non-positive value because the time_left
value is the amount of time left until the next periodic invocation. Upon the completion of a periodic job, a periodic task becomes INACTIVE.
Notation 2: A sporadic task and its nth execution are denoted by SPi (e, w, m) and
i is the identifier of a sporadic task,
e is the event that triggers a sporadic task,
w is the WCET of a periodic task, and
m is the power mode requested to run a sporadic task.
A periodic task can directly activate a sporadic task by sending an event to a sporadic task. In addition, a sporadic task can be activated by a device that was initialized by a periodic task. All devices of the system, such as sensors and actuators, conform to a typical activity sequence, as follows. Each device must be initialized by a periodic task in order to function. After initialization, the device works independently and then generates an interrupt. The interrupt handler again generates an event to trigger the sporadic task that is responsible for post-processing. For example, a sensor device completes the sampling of data following its initialization by a periodic task, and it then signals the end of sampling by generating an interrupt. The sporadic task that is triggered by the interrupt sends the sensor data to an external device via a UART port, when it is scheduled.
Unlike the scheduling of periodic tasks, the scheduling of an activated sporadic task is postponed when an overlap is predicted between the execution of the sporadic task and the execution of the nearest periodic task. The states of sporadic tasks are classified as SUSPENDED, INACTIVE, or RUNNABLE. When a sporadic task terminates its execution and there is no initialized event source for the sporadic task, the state is set to SUSPENDED. Once the event-source device is initialized by another periodic task, the sporadic task waits for the event in an INACTIVE state. When the awaited event eventually occurs, the sporadic task goes into a RUNNABLE state. However, a RUNNABLE sporadic task can only be scheduled immediately when the following three conditions are met:
There is no current execution of another task.
There is no preceding RUNNABLE sporadic task.
It is predicted that the execution of the sporadic task will not disturb the future execution of the coming periodic task, considering the WCET of the sporadic task.
If these conditions are not met, the sporadic task must wait to be scheduled until the three conditions are met in the RUNNABLE state. Figure 1
presents a diagram of the transition of task states with the scheduler.
With the above task model, four power modes are supported for power-aware scheduling: task-power mode, wait_event, sleep_with_timer, and sleep_with_radio. The sleep_with_radio and sleep_with_timer are modes for the system's INACTIVE state, and the others are for its ACTIVE state. The task-power mode is a task-specific mode, in that only necessary devices are turned on for the execution of a task. This power mode also includes the configurations of the microcontroller unit (MCU) and memory. When no task is being run, the system's power mode can be any one of the following: wait_event, sleep_with_timer, or sleep_with_radio. In the wait_event mode, the MCU and the system timer are enabled with the lowest possible power support and the lowest possible clock frequency, such as 32 kHz oscillator. Devices such as sensors and transceivers that are enabled by a periodic task can be kept enabled in this mode following the termination of a periodic task. Therefore, the wait_event mode indicates a power mode, in that a periodic task or a sporadic task can be scheduled in the near future. The sleep_with_timer mode is a lower-power mode, in that all system power supports are turned off, except for the wakeup timer. The system enters into sleep_with_timer when there is no RUNNABLE sporadic task, and when the amount of the time left until the next invocation of a periodic task is greater than minSleepInterval. The predefined value of minSleepInterval is the amount of time that is required for the system to recover its power in order to execute a task. Finally, the system enters into sleep_with_radio upon the request of an application. The sleep_with_radio is the lowest-power mode, in that all system power supports are turned off except for the wakeup-radio receiver. The contexts of the registers and memory must be saved in non-volatile memory when the system enters into either the sleep_with_timer or the sleep_with_radio mode. Additionally, the saved contexts must be restored when the system exits from one of these modes.
A power mode transition is performed by the scheduler calling the Power_Adjust() function. The Power_Adjust() function is designed to reconfigure hardware according to a given power descriptor before and after a task receives a schedule. The reconfiguration of hardware includes the modification of the MCU clock rate, voltage scaling, turning on of the peripherals, and scaling of the system timer.
2.2. Design of an On-Time Power-Aware Scheduler
The scheduling system consists of two main modules, the task scheduler and the event handler. The scheduler keeps the TCBs of tasks either in the periodic task queue (PTQ) or in the sporadic task queue (STQ), as shown in Figure 2
The event handler is responsible for handling hardware interrupts from the system timer, wakeup timer, wakeup radio, peripherals, and the WBAN transceiver. For example, when an interrupt from the system timer occurs, it updates the time-left values of all periodic tasks. If a task with a non-positive time_left is found, the state of the task is changed from INACTIVE to RUNNABLE, and the time_left value is reloaded with the value of that period, minus guard_time, to allow the system to prepare the start-up for the task. When there is an interrupt from a device, the handler prepares an event for the sporadic task that is responsible for that device and changes the state of the sporadic task from INACTIVE to RUNNABLE. If the event handler receives either a wakeup-timer interrupt or a wakeup-radio interrupt, it resumes the operation of the system by restoring the system context. The scheduler is called when the handling of the interrupt is complete.
In addition to handling hardware interrupts, the event handler also generates an event to trigger a sporadic task at the request of a periodic task, and as a result, the event handler changes the state of the target sporadic task from INACTIVE to RUNNABLE. In this case, the scheduler is not called immediately, because the periodic task that requested the event is still running.
graphically illustrate several scheduling and power adjustment scenarios. In Figure 3
denote the power mode and guard time, respectively, of the task a
. In the beginning, the scheduler sets the power mode as ma
and initializes the device D1
at the time of t1
, which is prior to the starting point of the task instance TPai
owing to its ga
. The execution of the periodic task instance TPai
activates the sensor device D1
by calling Request()
. The system then changes the state of the sporadic task SPb
from the SUSPENDED state to INACTIVE in order to allow the task to wait for an event. When TPai
terminates at t2
, the scheduler turns the system power mode to wait_event
, because there is an INACTIVE sporadic task whose execution is potentially possible in the near future. When an interrupt from D1
occurs at t3
, the system determines whether or not to schedule the sporadic task SPb
by considering the WCET of SPb
, as well as the earliest possible start time of the upcoming periodic task. In Figure 3
, when SPb
is scheduled, the power mode is set to the task-power mode mb
, since no execution will overlap with a periodic task, and SPb
is completed at t2
in Figure 4
, the task state is set to SUSPENDED again. At this time, the power mode is determined to be either wait_event
by considering the time left until the next periodic task and the number of sporadic tasks that are INACTIVE. At t2
, the power mode is set to sleep_with_timer
because there is no INACTIVE sporadic task, and the time left until the next periodic task is longer than minSleepInterval
. At t4
, if SPd
, the system enters into the sleep_with_radio
In Figure 5
, when an interrupt from D1
occurs at t3
, the scheduler knows that SPbi
overlaps with TPcj
, the execution of the next periodic task, by comparing the WCET of SPb
with the nearest time-left value. As a result, scheduling of the sporadic task SPbi
Overall, the scheduler assumes control when the event handler completes a cycle of interrupt processing and when the running of a task is complete. The scheduler action is straightforward, since it considers the task model, power mode model, and the time when the scheduler takes control of the CPU, as follows:
If there is at least one RUNNABLE periodic task, set the task-power mode and call the task.
Otherwise, if there is at least one RUNNABLE sporadic task, determine whether or not it can be scheduled immediately by comparing the WCET of this task and the time_left value of the next periodic task. If immediate scheduling is possible, set task-power mode and call the task. If it is not possible, set the system power mode as wait_event.
If there is no RUNNABLE task but there is at least one INACTIVE sporadic task, set the power mode as wait_event.
If there is no RUNNABLE or INACTIVE task,
If there was a turn_off_system request from a task, set the power mode as sleep_with_radio.
Else if the time left until the invocation of the next coming periodic task is larger than minSleepInterval, set the power mode as sleep_with_timer. Otherwise, set wait_event mode.
As given above, the running of a task is implemented in the form of a call to a task-body by the scheduler, because all tasks run without pre-emption. Figure 6
outlines the scheduler's actions in detail.