This thesis deals with Real-Time Cyber-Physical System (RT-CPS) as its target do- main. RT-CPS applications are usually dedicated towards controlling physical plants.
The applications execute persistently in infinite loops periodically acquiring data from the plant/environment through sensors, processing the same, and then generating ap- propriate actuation data. These control applications are often complex and executed on high capacity compute servers at locations which may be geographically distant from the plant. The sensors and actuators on the other hand, are in general co-located with the plant. In this scenario, both the sensory and actuation data must be transmitted as messages in a timely fashion over networks. The overall problem therefore involves two distinct resource management issues — that of managing computation resources for application execution and managing communication resources for message transmission.
Large systems such as today’s distributed manufacturing systems may constitute multiple control sub-systems running on distributed processing platforms. Control ap- plications in most of these sub-systems are modeled as real-time independent tasks or PTGs, depending on the nature of interactions between their functional components.
These tasks often execute in a federated fashion on dedicated (separate) processing
units in order to keep the design methodology simple, while also meeting specifications related to timing, reliability, energy, etc. However, it may be noted that such federated execution generally leads to poor utilization of resource capacities due to lack of resource sharing among tasks and/or messages. Poor resource utilization in turn, can result in higher design costs as more resources must be deployed to synthesize a given system, than is otherwise necessary. On the other hand, executing tasks on consolidated archi- tectures can reduce design costs, although it can cause to significantly increased design complexity due to a higher degree of contention for shared resources.
A scheduler allocates resources to the tasks and decides their execution sequence (start times) taking schedulability constraints into consideration. To schedule a set of independent tasks, a scheduler needs to satisfy deadline and resource constraints along with precedence relationships associated with sensing and actuation messages.
On the other hand to schedule a set of dependent tasks (represented as a PTG), a scheduler additionally needs to satisfy the precedence constraints among tasks. A sig- nificant amount of work exist in the literature on scheduling of PTGs on distributed systems [1, 6, 9, 11–13, 32]. Most of the existing schemes assume full interconnection between the processing elements in the execution platform. Distributed processing sys- tems formed by local area wireless networks such as ZigBee [45] are practical examples of such execution platforms. Today, there is an increasing trend towards the execution of real-time applications over such distributed local area networks in scenarios such as an Industry 4.0 based smart manufacturing plant. The applications here are typically complex interdependent work flows usually represented as PTGs. However, there is a severe dearth of efficient resource allocation techniques for executing real-time PTGs on the distributed platforms as mentioned above.
Although fully connected platforms find some practical use cases, there exist a vast majority of distributed systems where the processing elements are not fully intercon- nected by dedicated communication links. A shared bus-based automotive RT-CPS can be considered as a typical example of such a distributed platform. It may be noted that real-time scheduling techniques for this scenario must tackle contention for shared
communication channels, in addition to simultaneously handling the contention of tasks attempting to execute on a shared pool of processing elements.
Today, scheduling of tasks and messages in real-time distributed systems is usually carried out in a federated manner in two steps. The first step among them is dedicated to the allocation and scheduling of tasks on processing elements. Given the mapping and execution order of tasks (obtained through the first step), the second step is dedicated to the scheduling of messages between tasks while taking care that all schedulability constraints are satisfied. This separation of concerns between task and message schedul- ing allows the adaption of simpler design methodologies, and hence has been employed as the usual practice. However, it may be noted that integrated scheduling of tasks and messages have the potential to provide improved optimization, leading to possibly higher resource usage efficiencies and lower deployment costs. With this motivation,this thesis has attempted towards the design of task-message co-scheduling strategies for both independent tasks as well as PTGs, on fully-connected and shared-bus based distributed platforms.
Scheduling problems considered in this thesis are generally complex and NP-Hard in nature. We will now consider a series of small test case scenarios of progressively higher complexities and present important scheduling challenges that arrive for each of them. First, let us consider a set of five independent tasks T1, T2, T3, T4 and T5 to be executed on a homogeneous platform consisting of two processors P1 and P2. Table 2.1 shows execution times of these five tasks. All tasks have the same deadline of 14. Based
T1 T2 T3 T4 T5
2 1 2 4 1
Table 2.1: Execution times of tasks on homogeneous processors
on variations in task-to-processor allocation decisions, there can be multiple possible schedules with different makespans. For example, Figures 2.5a and 2.5b show two work- conserving1 schedules having makespans 6 (slack time 14−6 = 8) and 5 (slack time
1In awork-conserving scheduling algorithm, processors are never kept idle while there exists a task
14−5 = 9) respectively, for the given task set.
T1 T2 T5
P 1
T3 T4
P 2
0 1 2 3 4 5 6
6 time(ms)
(a)Schedule 1
T1 T3 T5
P 1
T2 T4
P 2
0 1 2 3 4 5
5 (ms)time
(b) Schedule 2
Figure 2.5: Gantt chart: Independent tasks (Table 2.1); Homogeneous processors
We can observe from the above example that based on variations in task-to-processor allocation decisions, there can be multiple schedules with different makespans. A sched- ule with lower makespan is always beneficial as it allows higher slack times which may be used to better optimize one or more performance metrics such as expenditure on resources, energy, reliability, security, etc.
The first test case scenario does not consider message communication. Next, we con- sider the case when each task takes a sensory input and produces an actuation output.
The sensed inputs are transmitted as messages over communication channels, to pro- cessors where tasks get executed and the corresponding control outputs are computed.
The computed outputs in turn are communicated to actuators as messages via commu- nication channels. Let us consider the same set of five independent tasks T1, T2, T3, T4 and T5 executing on a homogeneous distributed platform consisting of two processors P1 and P2. Tables 2.1 and 2.2 show the tasks’ execution times and their corresponding input/output messages. Here, MiI and MiO represent input and output messages of a task Ti. For simplicity, we assume that the bandwidth of the communication channels among processors in this example is of unit capacity. So, the communication time of messages will become same as their sizes. Here also, all tasks have the same deadline 14.
Depending on variations in task-to-processor allocation decisions, there can be mul- tiple possible schedules with different makespans. For example, Figures 2.6a and 2.6b show two schedules having makespans 14 and 13 respectively, for the given task set and
waiting for execution.
Input Messages Output Messages M1I M2I M3I M4I M5I M1O M2O M3O M4O M5O
1 2 2 1 1 1 1 1 2 1
Table 2.2: Transmission times of input and output messages
T1 T2 T3 T5 T4
P 1 P 2
M1I M2I M3I M4I M5IM1OM2OM3OM5O M4O
B 1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
14
(ms)time
(a)Schedule 1
T1 T4 T3
P 1
T5 T2
P 2
M1IM4IM5I M2I M3I M1OM2OM3O M4O M5O
B 1
0 1 2 3 4 5 6 7 8 9 10 11 12 13
13
time (ms)
(b) Schedule 2
Figure 2.6: Gantt chart: Independent tasks (Table 2.1) with associated messages (Table 2.2);
Homogeneous processors
associated messages. The generated schedules also show that each task starts only after it receives the corresponding input message. Similarly, the output message starts its transmission after the respective task finishes its execution. In Chapter 3 (contribution 1) we present solution strategies for a system model very similar to the second test case scenario.
In the third case scenario, we consider PTG as the application model. Let us consider a set of five dependent tasks represented as a PTG in Figure 2.7, to be executed on the same two processors homogeneous platform. In the PTG, T1 −T5 represent tasks
and M1 −M6 represent messages. Tables 2.1 and 2.3 show execution times of tasks and message sizes/transmission times, respectively. End-to-end deadline of the PTG is assumed to be 14. There can be multiple possible schedules with different makespans
T1
M1 M2 M3
T2 T3 T4
M4 M5 M6
T5
Figure 2.7: PTG with task and message nodes
M1 M2 M3 M4 M5 M6
1 2 2 1 1 1
Table 2.3: Transmission times of message nodes in the PTG shown in Figure 2.7
based on variations in task-to-processor allocation decisions. For example, Figures 2.8a and 2.8b show two work-conserving schedules having makespans 10 and 9, respectively.
If both the parent and child tasks Ti and Tj of a message Mk are scheduled on the same processor, then there is no need to transmit the message Mk over the communication channel. Hence, in this case the transmission time associated with messageMk becomes zero. For example in Figure 2.8a, the messageM2 is not transmitted as both parent and child tasks T1 and T3 are scheduled on the same processor P1. From the same figures, it can also be seen that precedence among task and message nodes in the PTG are preserved. For example (in Figure 2.8a), task T3 starts after the predecessor task T1 finishes its execution. Similarly, task T2 starts after the predecessor message M1 finishes its transmission.
T1 T3 T4
P 1
T2 T5
P 2
M1 M5 M6
B 1
0 1 2 3 4 5 6 7 8 9 10
10
(ms)time
(a)Schedule 1
T1 T3 T4 T5
P 1
T2
P 2
M1 M4
B 1
0 1 2 3 4 5 6 7 8 9
9
time(ms)
(b) Schedule 2
Figure 2.8: Gantt chart: PTG (Figure 2.7) with tasks (Table 2.1) and message (Table 2.3) nodes; Homogeneous processors
Today, continuous demands for higher performance and reliability within stringent resource budgets, is driving a shift from homogeneous toheterogeneous processing plat- forms for the implementation of CPSs. Depending on processor types, a task may require same or distinct execution times on different processors, and this must be correctly ac- counted in the generated schedule. In the fourth test case scenario, we consider the two processors P1 and P2 to be heterogeneous. Table 2.4 shows the execution times of five task nodes (of the PTG in Figure 2.7) on P1 and P2. Similarly, Table 2.3 shows the communication times of message nodes. We consider the deadline of the PTG to be 14.
Figures 2.9a and 2.9b show two work-conserving schedules having makespans 11 and 9 respectively, for the given PTG. From the figures, it can be seen that each task has consumed distinct amounts of time depending on the processor on which it is assigned.
For example (in Figure 2.9a), task T2 has taken 3 time units on processor P2.
T1 T2 T3 T4 T5
P1 2 1 2 4 1
P2 3 3 1 3 2
Table 2.4: Execution times of tasks on two heterogeneous processors
T1 T3 T4
P 1
T2 T5
P 2
M1 M5 M6
B 1
0 1 2 3 4 5 6 7 8 9 10 11
11
(ms)time
(a) Schedule 1
T1 T3 T4 T5
P 1
T2
P 2
M1 M4
B 1
0 1 2 3 4 5 6 7 8 9
9
time(ms)
(b)Schedule 2
Figure 2.9: Gantt chart: PTG (Figure 2.7) with tasks (Table 2.4) and message (Table 2.3) nodes; Heterogeneous processors
A significant amount of work is done on the problem of scheduling PTGs executing on various distributed platforms [1, 6, 9, 11–13, 32]. Most of these works assumed that processors are fully-connected. That is each pair of processors have dedicated commu- nication channel to send/receive data or messages. In the fifth test case scenario, we consider a distributed platform which is fully-connected. Let us consider the same PTG (Figure 2.7) as the previous test case. However, we now consider a fully-connected het- erogeneous distributed platform consisting of three processorsP1, P2 and P3. Tables 2.5 and 2.3 show the execution and transmission times of tasks and messages. Figures 2.10a
T1 T2 T3 T4 T5
P1 2 1 2 4 1
P2 3 3 1 3 2
P3 1 2 3 2 3
Table 2.5: Execution times of tasks on three heterogeneous processors
T5
P 1
T2 T3
P 2
T1 T4
P 3
0 1 2 3 4 5 6 7 8
8
(ms)time
(a)Schedule 1
T2 T5
P 1
T3
P 2
T1 T4
P 3
0 1 2 3 4 5 6
6
time(ms)
(b)Schedule 2
Figure 2.10: Gantt chart: PTG (Figure 2.7) with tasks (Table 2.5) and message (Table 2.3) nodes; Heterogeneous processors; Fully-connected
and 2.10b show two work-conserving schedules having makespans 8 and 6 respectively, for the given PTG. From the same figures, it can also be seen that when both parent and child tasks are scheduled on different processors, the child task has to wait for the corresponding message transmission. For example (in Figure 2.10a), task T2 has to wait for 1 time unit for the transmission of message M1 through the dedicated communica- tion channel between processors P3 and P2. Chapters 4 and 5 address the problem of scheduling a PTG on system model very similar to the fourth and fifth test case scenario.
In the previous test case scenario, we have assumed a distributed platform where processors are fully-connected. However, there exist a vast majority of distributed sys- tems where processors are connected through shared-bus based communication chan- nels [41, 42]. Real-time scheduling techniques for this scenario must tackle contention for shared communication channels, in addition to simultaneously handling the con- tention of tasks attempting to execute on a shared pool of processing elements. In the sixth test case scenario, we consider a distributed platform where processors are con-
nected through shared-bus based communication medium. Let us consider the same PTG in Figure 2.7 having deadline 14 and executing on a heterogeneous distributed platform consists of three processors P1, P2 and P3 connected through a shared bus B1. Tables 2.5 and 2.3 show the execution times of tasks and transmission times of mes- sages, respectively. Figures 2.11a and 2.11b show two work-conserving schedules having
T5
P 1
T2 T3
P 2
T1 T4
P 3
M1 M2 M6 M4 M5
B 1
0 1 2 3 4 5 6 7 8
8
time(ms)
(a) Schedule 1
T2 T5
P 1
T3
P 2
T1 T4
P 3
M1 M2 M6 M5
B 1
0 1 2 3 4 5 6 7
7
time(ms)
(b) Schedule 2
Figure 2.11: Gantt chart: PTG (Figure 2.7) with tasks (Table 2.5) and message (Table 2.3) nodes; Heterogeneous processors; Shared bus
makespans 8 and 7 respectively, for the given PTG. As all the three processors are connected through a single shared bus, depending on schedule of messages on the bus, a task may have to wait for the transmission of other messages which are irrelevant to it. For example in Figure 2.11b, task T3 has to wait for the transmission of message M1 which is irrelevant to it, in addition to M2. In the Chapter 6, we consider a similar platform model for PTG scheduling and present solution for the same.
In the above discussions, we have shown the scheduling of a set of independent tasks or a single PTG executing on various types of distributed platforms. However, there can be multiple co-executing control functionalities in the system, with each such functionalities being represented as a PTG. These control functionalities repeat/execute periodically. The seventh (also the final) test case scenario considers the problem of scheduling multiple PTGs on a shared-bus based distributed platform. Let us consider two PTGs G1 and G2 (Figure 2.12) to be executed on a shared bus-based heterogeneous
distributed platform consisting of three processors (P1, P2 and P3) and one bus (B1).
Here, Tig representsith task node and Mkg represents kth message node of the PTG Gg. Tables 2.6 and 2.7 show execution and communication times of tasks and messages, respectively, in PTGs G1 and G2. Both PTGs G1 (Figure 2.12a) andG2 (Figure 2.12b) have implicit deadlinesD1 = 14 andD2 = 7, respectively. So, hyperperiod for these two co-executing tasks become 14. Within this hyperperiod we have one instance of G1 and two instances ofG2. We determine a schedule for these two PTGs over one hyperperiod.
The determined schedule will repeat every hyperperiod. Figures 2.13a and 2.13b show
T11
M11 M21 M31 T21 T31 T41
M41 M51 M61
T51
(a)
T12
M12
T22
M22
T32
(b)
Figure 2.12: (a) PTG G1, Deadline D1 = 14; (b) PTG G2, Deadline D2 = 7
Processor PTG G1 PTG G2
T11 T21 T31 T41 T51 T12 T22 T32
P1 2 1 2 4 1 1 2 3
P2 3 3 1 3 2 2 1 2
P3 1 2 3 2 3 3 3 1
Table 2.6: Execution times of task nodes in PTGsG1 and G2
two different work-conserving schedules for PTGs G1 and G2 executing on the same distributed platform. We can see that a task of a PTG at different iterations within
Bus PTG G1 PTG G2 M11 M21 M31 M41 M51 M61 M12 M22
B1 1 2 2 1 1 1 1 2
Table 2.7: Transmission times of message nodes in PTGs G1 and G2
T12 T21 T12
P 1
T22 T32 T22
P 2
T11 T31 T41 T51 T32
P 3
M12M11 M41 M12 M22
B 1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
14
(ms)time
(a) Schedule 1
T12 T21 T12
P 1
T22 T32 T22 T32
P 2
T11 T31 T41 T51
P 3
M12M11 M41 M12
B 1
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
14
(ms)time
(b)Schedule 2
Figure 2.13: Gantt chart: Multiple PTGs (Figure 2.12; Tables 2.6 & 2.7); Heterogeneous processors; Shared bus
the hyperperiod may be assigned to different processors and it takes distinct execution times to compute on its assigned processor. For example in Figure 2.13a, the task T32 is assigned on processor P2 in its first iteration and on P3 in the second iteration. T32 takes 2 time units on P2 and 1 time unit on P3. In Chapter 7, we consider the problem of scheduling multiple independent PTGs on a shared bus-based distributed platform.