Information Technology Reference
In-Depth Information
An
infusion session
is defined as the interval from the start of the pump motor
till its stop.
We implemented software that cap-
tures the requirements on an Atmel
SAM7X-EK development board [2], run-
ning the FreeRTOS real-time operating
system [3]. The development board is in-
terfaced to the sensors and actuators of
the Baxter PCA infusion pump hardware.
Sensor signals from the bolus request but-
ton and the empty reservoir detection
switch are captured through periodic sam-
pling. Instructions for the pump motor
to start and stop are delivered via pulse
width modulation. Alarms are signaled
with flashing LEDs in our experiments.
The FreeRTOS in our case study runs a
priority-based, preemptive scheduler. Five
tasks, each implemented with an indepen-
dent C function, communicate with each
other by sending and receiving messages in three message queues, Q1, Q2, and
Q3. Some tasks have individual local variables, which we deem as unknown to the
analysis due to our black-box assumption, but they do not share global variables
in our implementation. In this case study, we view each task as a component;
the terms
task
and
component
are used interchangeably.
The five tasks are summarized in Table 1. The Priority column indicates the
task priorities in addition to the system idle task's priority of FreeRTOS. The
left (right, resp.) arrow means that the corresponding task reads (sends, resp.)
messages from (to, resp.) the queue. An
event
in the system is a single action
performed by a task. We attach each event with a timestamp, denoted as a
pair (
e,t
), where
e
is the event and
t
SENSOR: BOLUS_REQ
SENSOR: EMPTY_RSV
BOLUS
EMPTY / NON_EMPTY
TASK: BolusReq
TASK: EmptyRsvDetection
ENQ(Q1, BOLUS)
ENQ(Q1, EMPTY)
QUEUE: Q1
DEQ(Q1, BOLUS)
DEQ(Q1, EMPTY)
TASK: PlatformIndependent
ENQ(Q3, EMPTY) /
ENQ(Q3, NON-EMPTY)
ENQ(Q2, BOLUS)
QUEUE: Q2
QUEUE: Q3
DEQ(Q2, BOLUS)
DEQ(Q3, EMPTY)
TASK: PumpMotorCtr
TASK: AlarmCtr
START
ALARM
STOP
STOP
ACTUATOR: MOTOR
ACTUATOR: ALARM
Fig. 1.
Data flow of the GPCA
∈
R
≥
0
is the timestamp. For example,
(alarm
,
9760) represents an event where the
AC
task has raised an alarm, at
time 9760 ms since the system starts execution. The events we recorded for this
case study is summarized in Table 2. We assume it is known which task produces
which event. In particular, we assume we know whether an instance of the stop
event is produced by
AC
or
PM
.
Tabl e 1.
Tasks in FreeRTOS Implementation for GPCA
Task Name
Abbreviation Period Priority Queues Accessed
PumpMotorCtr
PM
300 ms
+6
← Q
2
PlatformIndependent
PI
Aperiodic
+5
← Q
1,
→ Q
2
,Q
3
BolusReq
BR
500 ms
+4
→ Q
1
AlarmCtr
AC
500 ms
+3
← Q
3
EmptyRsvDetection
ER
1000 ms
+2
← Q
3
