Predicting dynamic computational workload of a self-driving car (PDF ...

2014 IEEE International Conference on Systems, Man, and Cybernetics October 5-8, 2014, San Diego, CA, USA

Predicting Dynamic Computational Workload of a Self-Driving Car Young-Woo Seo

Junsung Kim and Ragunathan (Raj) Rajkumar

The Robotics Institute Carnegie Mellon University Pittsburgh, PA USA [email protected]

Dept. of Electrical Computer Engineering Carnegie Mellon University Pittsburgh, PA USA {junsungk, [email protected]}

Abstract—This study aims at developing a method that predicts the CPU usage patterns of software tasks running on a selfdriving car. To ensure safety of such dynamic systems, the worstcase-based CPU utilization analysis has been used; however, the nature of dynamically changing driving contexts requires more flexible approach for an efficient computing resource management. To better understand the dynamic CPU usage patterns, this paper presents an effort of designing a feature vector to represent the information of driving environments and of predicting, using regression methods, the selected tasks’ CPU usage patterns given specific driving contexts. Experiments with real-world vehicle data show a promising result and validate the usefulness of the proposed method. Index Terms—Prediction of software tasks’ CPU usage patterns, regression, machine learning, self-driving car

I. I NTRODUCTION To enable a vehicle to drive autonomously, the computing unit of a self-driving car must be capable of running simultaneously many software tasks (e.g., motion-planning, moving object detection, etc.). As those tasks are computationally intensive and the capacity of a computing unit is not unbounded, it is important to efficiently utilize such limited computational resources. In safety-critical systems like a self-driving car, researchers have used conventional real-time theories. Real-time tasks on such systems can be modeled as an infinite sequence of periodic jobs [13], where each job is released at every T units of time and executed for at most C units of time. The task utilization is then defined as C T and represents the worst-case computational workload. Using this definition, analytical methods have been provided to guarantee system timeliness using the utilization-based and/or responsetime-based analyses [6]. Many variants of the periodic task model have been proposed to accommodate different deadline properties [12], shared resources [17], and task dependencies [15]. Although the conventional real-time approaches are applicable to a self-driving car, they would fail to incorporate the dynamic nature of its operating environments. This is because they are too conservative to handle tasks for autonomous driving where the resource utilization patterns change as driving environments change. For example, when a self-driving car drives down an empty street, a motion-planning algorithm’s CPU utilization is low; it is, however, many times higher when computing a collision-free trajectory along a busy street. Such information about driving environments should be utilized to infer computational workload on the fly. However, it is extremely hard to mathematically model any environmental information such as real-world traffic situations.

978-1-4799-3840-7/14/$31.00 ©2014 IEEE

Thus, the problem of scheduling tasks with dynamically changing utilizations calls for a robust and data-oriented analysis. A data-oriented analysis would enable us to efficiently use limited computing resources by assigning tasks, based on the analyzed utilization patterns, to individual cores of computing units. To this end, this paper presents an effort to develop methods for learning the patterns of tasks’ CPU utilizations in given driving contexts. In particular, we collect the task utilization data from our self-driving car’s maneuvers, design a representation of the collected data, and develop methods, using regression methods, to predict the future CPU utilization of each task. Researchers have tried improving the performance of worstcase scenario-based analysis by analyzing the data of binaryexecution [4], [9]. Hansen and his colleagues employed extreme value theory to deal with the tail behaviors of a distribution [9]. Our approach is related to these approaches in that they measured the execution times of tasks using a statistical analysis, but our work aims at predicting future workload based on past workload data. Our work is closely related to that of two other studies. Rrushi and Kang used a linear regression method to identify the relation between a control system and its desired outputs [19]. Ahmadi et al. also used a linear regression method to model the behaviors of a cyber-physical system, showing the efficacy of their proposed approach in a green transportation system [1]. Whereas our approach differs from these earlier regression approaches in fitting the unknown, nonlinear mapping between the feature representation and CPU utilization. Our contributions include 1) an analysis of the resource utilization patterns of software tasks running on a self-driving car, 2) the development of a feature representation to capture the relevant information of internal and external driving environments, 3) the use of regression methods for the CPU utilization prediction, and 4) the empirical validation of the proposed methods’ usefulness. In what follows, in Section II-A, we briefly describe what the tasks of autonomous driving are from the software architecture of our self-driving car and detail which ones are analyzed; In Section II-B, how they are computationally represented; in Section II-C, we laid out what regression methods are used. Finally, in Section III, we describe the settings and discuss the findings of the experiments. II. P REDICTION OF CPU U SAGE PATTERNS OF R EAL -T IME AUTONOMOUS D RIVING TASKS This section details how we address the problem of predicting dynamic, computational workload of a self-driving car. In

3030

Fig. 1: Our self-driving car [21] and a brief illustration of its software architecture. For reliable and safe autonomous driving, many processes are required to simultaneously run on the vehicle’s computing cluster. Thus, to efficiently utilize limited computing resources, it is important to precisely know, in advance, which task processes consume how much of those resources under what contexts. Section II-A, we briefly describe the pipeline of the software architecture of our self-driving car and detail four essential tasks that our self-driving car needs to always execute to perform autonomous driving maneuvers. Then, in Section II-B, we explain how we represent the (internal and external) states of driving environments and then, in Section II-C, explain the regression methods applied to this representation to predict CPU usage patterns of those selected tasks. A. Tasks for Autonomous Driving Figure 1 shows our self-driving car and a brief illustration of its software architecture [21]. On behalf of human drivers, a self-driving car executes driving maneuvers to get human attendants to their destinations. To enable the vehicle to drive autonomously, many task processes need to run simultaneously on the computing units of a self-driving car. For example, various task processes (i.e., reading raw data from sensors) in a perception subsystem need to interpret what sensors (e.g., LIDARs, radars, cameras, etc.) perceive the current state of the vehicle and its driving environment, and to produce task-relevant information (e.g., positions of static/dynamic obstacles, topology of road network, pose of the vehicle, etc.). Based on the information about traffic environments and the topology of the road network, a mission-planning subsystem searches for the optimal route to the destination. Given the selected route and traffic conditions, a drivingbehavior decision making subsystem (or behavior executive) plans how to reach the destination and controls, by providing motion goals, a motion planning subsystem [20]. Based on the motion goals, estimation of nearby objects positions and their likely trajectories, a motion planner computes a collisionfree trajectory to achieve the motion goals (e.g., drive to reach a certain location) [8]. This trajectory is used to eventually control the vehicle’s locomotion to drive it autonomously. Among these tasks, we chose four: mission planning, driving-behavior decision making, and two motion planning tasks (traffic-free and traffic-based), because they are fundamental and the most frequently used tasks for our autonomous driving. Here we briefly describe these tasks in terms of their primary goals. For the technical details, we refer to [7], [20]

for mission planning, to [2], [7] for driving-behavior decision making, and to [8] for motion planning. Mission Planning Given a destination from a user, the mission planner searches for the optimal route from the current location to the destination. To do so, the mission planner needs information about the current vehicle’s location and road network. To estimate the expected time of arrival, the mission planner analyzes the various dynamic and static aspects of a road network such as the number of intersections, the number of lane changes to execute, legal road speed limit, road blockages, etc. It then chooses the route that returns the shortest travel time. The chosen route is represented as a set of road segments where a certain location at each segment corresponds to a mission, such as “go from point A to point B.” As the vehicle drives toward its destination, such a lanelevel mission will be continuously updated and provided to the “Behavior” subsystem to control the vehicle’s motions [7]. Driving Behavior Decision Making (or Behavior Executive) Given a chosen route to the destination, the drivingbehavior decision maker generates short-term decisions to follow the mission plan. To do so, the behavior subsystem requires a reference trajectory without considering traffic, information about the current vehicle’s location, moving and static object detection, and road-blockages. Examples of such driving behaviors include on-road driving, intersection handling, distance keeping, lane changing, and interactions with neighboring vehicles. While executing on-road driving behavior, the algorithm ensures that the car stays in a lane and keeps its proper distance from the car ahead, if any. It also deals with changing lanes and merging with another lane to exit/enter the road while abiding by traffic rules, (e.g., obeying stop signs or traffic lights). The decisions result in a set of goals that the car needs to reach. Motion Planning (Traffic-free Planner and Traffic-based Planner): The motion planner executes two motion-planning strategies: a pre-planning (traffic-free) and a reactive-planning (traffic-based) [8]. The pre-planning aims at generating, based on a given road geometry with no traffic, a trajectory for a relatively long distance and reactive planning focuses more on achieving a goal from the behavior generation subsystem while avoiding static/dynamic obstacles. To do so, these motion planners require the current vehicle pose, a map of the road network, and a list of static and dynamic obstacles. In particular, the motion-planners generate multiple possible trajectories for the car to follow to achieve the goal. Each trajectory is represented by a cost, and the algorithm chooses the one with the lowest cost. The motion planner’s final output is a trajectory that a drive-by-wire system, which controls the vehicle actuators, will execute. B. Representation of Autonomous Driving Conditions To predict a task’s CPU utilization at a given time, it is necessary to represent, in a computational form, the states of the internal and external driving environments of a selfdriving car. The representation should succinctly capture only the relevant information. To this end, we design a representation summarized in Table I. We represent, using a multi-dimensional, feature vector x ∈ Rm , the states of the vehicle and its driving environment.

3031

Features x1 x2 x3 x4 x5 x6 x7

Descriptions (metrics) Vehicle speed (mph) Vehicle curvature Maximum speed (mph) Road curvature Distance to the next geometry change (m) Number of road lanes Number of moving objects

Type Continuous Continuous Continuous Continuous Continuous Discrete Discrete

TABLE I: Representation of the regression problem of predicting computational workloads of a self-driving car. In particular, the features x1 ∈ [0, 70]1 (miles per hour) and x2 ∈ [−0.163, 0.163] (radian) concern an aspect of the current vehicle’s motion: x1 , how fast it is driving and x2 , how circular its steering wheel’s turning angle is. The remaining features concern the status of the driving environment. In particular, x3 ∈ [0, 65] (miles per hour) represents the maximum speed of a road section that our vehicle happens to be driving on; x4 ∈ [minx4 , maxx4 ]2 is the curvature of that road segment; x5 is the distance to the location where the road geometry is changed (e.g., appearance of an intersection); x6 ∈ [1, 5] is the number of road-lanes. Here a road-lane refers to a part of a road used for controlling a single-line of traffic in the same driving direction. x7 ∈ [0, 30] is the number of moving objects that were recognized by our perception module for detecting and tracking of moving objects [5]. The selection of these features is done based on our knowledge of these tasks. In reality, the variables in the feature vector may be correlated to each other, but, in this work, we assume that they are independent of one another. At a given time, t, our perception subsystems observe the states of our car and its driving environments to fill the values of this feature vector, xt . Given this vector, the goal of this work is to predict the CPU utilization of a specific software task. In the next section, we detail what regression methods we investigate for this prediction task. C. Regression for Predicting Computational Workload We frame the problem of predicting a task’s CPU usage pattern as a regression problem, yk = f (xk , tj ), where yk ∈ [0, 1] is a software task’s CPU utilization; f is a function that maps a feature vector to a real-value; xk ∈ Rm is a feature vector of representing the states of the vehicle and its driving environments, and tj is the software task under investigation. The dimension of a feature vector is 7 for our case. The true function, f (xk , tj ), is unknown. To estimate this function from the data, we use five regression algorithms: a linear regression, a logistic regression, a regression tree, a regression tree with bagging, and Gaussian processes. In general, a regression algorithm aims at solving the problem of predicting a target value in real-numbers given a feature vector, y = Xβ +, where, for our case, y is a vector of target values, X is n × m data matrix, and β is an m-dimensional coefficient vector, where there are n number of m-dimensional data, and  is the error between true values and predicted values. A solution for such a regression problem needs to find 1 We have tested the maximum speed of our vehicle 70 mph under autonomous driving mode and 75 mph under manual driving. 2 The value of the maximum (minimum) road curvature, max x4 (minx4 ), is dependent upon the radius of a curvy road and may be retrieved from a governmental manual about road geometry. But, for our case, we find the maximum (minimum) value from collected data.

a coefficient vector, βˆ ∈ Rm that minimizes the empirical error (or the sum of square-error between the true values, y, 2 n  Tˆ and the predicted values),  = [3]. An i=1 yi − xi β ˆ optimal coefficient vector, β, as a linear regression solution, can be obtained by computing the minimum of the error ˆ However, the performance of equation, (XT X)−1 XT y = β. ˆ is very sensitive to outliers the resulting coefficient vector, β, because it is essentially a line that fits the center of the data points. This is particularly true when the true relationship between a target value, yk , and an input vector, xk , is nonlinear. To overcome such a sensitivity, an iterative solution can be used. For the logistic regression, a hyper-function, σ(xT β), is iteratively learned, using a gradient descent, to make a regression function more robust to outliers of the input. Another way of avoiding a data-sensitive solution and of obtaining a generalized solution is to use the regularization that adds another term to an error function to control the complexity of a resulting coefficient The total error 2 vector. T m Tˆ function becomes, yi − x β + λ |βj |q , where i=1

i

j=1

λ is a regularization coefficient, which controls the relative importance of the data error and the regularization term, and q is the regularizer (e.g., q = 1 for L-1 and q = 2 for L-2). Three other regression methods we used for this study ˆ from training data. We also iteratively find a solution, β, used as non-linear regressors, a regression tree, a regression tree with bagging, and a Gaussian processes. A regression tree is a decision tree with binary splits for a regression problem. The target value of a given input vector is predicted by comparing the input vector with the learned criteria at each branching point from the root node to a left node. The bagging (or bootstrap aggregation) is a type of training an ensemble machine and its final output is produced by combining the outputs of multiple weak learners. At each training iteration, n out of n samples are, with replacements, randomly selected. These randomly selected n samples is a bootstrap (or a bootstrap replica) of the given data used to train a regression method. The Gaussian processes aim at solving the regression problem in the Bayesian inference framework where the posterior is computed by multiplying a likelihood and a prior. The likelihood function is obtained through a training process using data and the prior is imposed by an assumption about the data [18]. III. E XPERIMENTS This section details the settings and results of experiments that we conducted to validate the usefulness of the proposed methods. A. Experimental Settings To record the selected tasks’ CPU usage patterns while the vehicle was driving, we implemented a lightweight kernel-level task profiler [10], which is now a part of Linux/RK [16] and integrated into the software package of our self-driving car. The task profiler is used to measure each tasks’ execution time. In particular, when the task profiling turned on, the Linux/RK kernel module collects (1) the release and completion time of every job of each task, (2) the processing core where each task runs, (3) the status of each task, (4) the cache miss ratio, and (5) the instruction counter. The collected data is stored

3032

Fig. 2: (a) The route for data collection and the ground-truth patterns of the tasks’ CPU utilization. (b) The CPU usage patterns of “Mission-Planning” and “Driving-Behavior Decision-Making” tasks. (c) The CPU usage patterns of two motion-planning tasks: “Traffic-based” and “Traffic-free.” at the kernel level and is later saved as a text file for further preprocessing before regression methods are applied. To collect the vehicle’s actual driving data, we drove, multiple times, our self-driving car on a route around Pittsburgh International Airport where the traffic was moderate during the data collection period, and the geometry of the route is not significantly challenging. The route is shown in Figure 2 (a). This data collection resulted in 16 data sets (i.e., 4 tasks for 4 different data logs). Data points numbered 321,118 with approximately 20,000 data points on average for each data set. We used about 70% of each data set for training the regression methods and 30% for evaluating the trained methods. We implemented a task running on our log playback framework [14] to fill out the values of the feature vectors described in Section II-B. Particularly, the vehicle speed, x1 was estimated from an inertial navigation system and the value of the vehicle curvature, x2 , was obtained from the steering wheel’s turning angle. The information about the road segment our vehicle happened to be driving on was directly retrieved from a map database. We manually built a map of the target area that included the speed limit, x3 , the curvature at a given location, x4 , the number of road lanes, x6 , and other locations where the road geometry changed, like intersections, ramps, etc. Thus, it is straightforward, given the vehicle’s current location estimated by our pose estimator, to compute the distance, x5 , between the current location and the next changing point in geometry. A moving object tracker fused measurements from sensors in different modalities to detect moving objects and tracked them using a Bayes filter [5]. The outputs of this tracker were used to count the number of moving objects, x7 . For each feature variable, the maximum values described earlier were used to normalize individual feature values, thereby avoiding the dominance of the subset of features for our regression problem. Each of the regression methods contains its own hyperparameters that need to be tuned optimally for a reasonable performance on the testing data. For the linear regression, we ran a 10-fold cross-validation to find the optimal coefficient vector that minimized the empirical error measured by the sum of the squared error. To obtain a generalized linear solution, we also tried L1 (or Lasso) and L2 (or Ridge regression) regularization, but found a marginal difference on the performance of the linear regression. For the logistic regression, we ran, multiple times, a least square to find the optimal coefficient vector – it terminated the iterations after running by the given number of iterations or until there were no significant weight changes. For the regression tree, it is important to find an

optimal level of the tree depth – if it has too many levels (or the depth is too shallow), a resulting tree would overfit the training data (or a resulting tree’s expressionness on the data is not good enough), resulting in poor prediction accuracy. To find the optimal level, we ran a 10-fold cross-validation. Another important hyper-parameter of a regression tree is the number of sample points per leaf node. For the bagging, we tried two different learners: a least-square boosting and a decision tree, finding the bagging with a decision tree to work better. We ran a 10-fold cross-validation for the bagging as well to find the optimal level of the tree. For the Gaussian processes, we used a linear mean and covariance function, and a Gaussian likelihood function.3 Because of such a setting for the Gaussian processes, the inference for predicting the values of testing data was made exactly. Figure 2 (b) and (c) show the ground-truth of the selected tasks’ CPU usage patterns. Each task’s utilization pattern varied as the driving environments changed. The “MissionPlanning” task’s pattern looks dichotomously consistent. At the beginning it used CPU very intensively to search through the topology of the road network and consider various aspects of the current roads, as it searched for an optimal route to the destination. As the mission is executed, its CPU usage decreases – cutting down the initial usage by nearly half and being reduced incrementally. This is because the amount of search for the road network topology decreases as the vehicle’s location closes in on its destination. The “Driving-Behavior Decision Maker (or Behavior)” task used CPU dynamically as it was involved in various aspects of the vehicle’s driving maneuvers – analyzing traffic situations to guide the motion planner’s execution. The two peaks at the beginning and end of the graph correspond to the high computation of localizing our vehicle, based on the estimated current location, within the entire road network topology. The two motion planning tasks, the “Traffic-based” and “Traffic-free” motion planners, consistently used CPU at about the same rate. When the “Behavior” provides the goal of the motion planning (e.g., finding a collision-free path to drive to a certain location), the “Traffic-free” motion planner solves an optimization problem to find a path to the motion goal location within a road-segment that our vehicle happens to be driving on.4 When the vehicle entered a new road segment, the “Behavior” will generate a new motion goal and the “Traffic-free” motion planner finds a 3 We used the GPML toolbox http://www.gaussianprocess.org/gpml/code/ matlab/doc/index.html for our GP implementation. 4 A road-segment roughly corresponds to an edge in a road network where an intersection is a vertex.

3033

Fig. 3: Mean of the mean squared errors of five regression methods on four datasets. The y-axis represents the mean of the mean squared errors on CPU utilization predictions and the xaxis corresponds to five regression methods. Each graph shows the mean error of the five regression methods on four tasks: a) Driving-Behavior Decision Making, b) Mission Planning, c) Traffic-based Motion Planning, and d) Traffic-free Motion Planning. new trajectory to reach the newly generated motion goal. These periodic execution activities are continuously performed until the vehicle arrives at its destination and in fact correspond to several peaks (i.e., red triangles) on the graph. The CPU time of the “Traffic-based” motion planner was about ten times that of “Traffic-free” motion planner. Indeed, it was called on to continuously search for an optimal trajectory as a function of the remaining distance to reach a motion goal. In particular, as the vehicle drove toward the motion goal location, the search space shrank that the “Traffic-based” motion planner (i.e., traffic-based reference planning algorithm) needs to examine. At the same time, another part of the “Traffic-based” motion planner (i.e., a local planner) was continuously searching for an optimal trajectory over the predefined trajectory set [8]. This causes the CPU usage pattern by the “Traffic-based” motion planner to periodically fluctuate. B. Experimental Results Figure 3 summarizes the performance of the regression methods. The graph shows the mean of the mean squared errors of the five regression methods on four data sets. The regression tree with the bagging outperformed all other methods in that its outputs were the most accurate. The regression tree alone also performed relatively well, except for the “MissionPlanning” task. For our case, the regression tree seemed to be a good solution. Unexpectedly, the performance of the linear regression was not the worst. This is surprising because the linear regression fitted just a line to the data points to solve a regression problem. By contrast, the performance of the logistic regression was worse than that of the linear regression. The reason we used the logistic regression was to fit, through an iterative parameter search, a non-linear pattern to the data. However, it turned out that a global model found by the linear regression worked better in terms of the prediction error. However, such a quantitative performance evaluation may provide us no definitive indication for which regression method was best for our task. Recall that the goal of this work is to develop a method that predicts the expected CPU utilization of a task running on a self-driving car and that enables us to

efficiently use the limited computing resource. In particular, the prediction outputs of the CPU utilizations should be slightly greater than the actual utilization. Otherwise (i.e., outputs being less than the actual utilization), the response time of a task would not be guaranteed, resulting in unreliable autonomous driving. To evaluate the outputs of the five regression methods from this perspective, we further analyze the prediction errors and categorize them into two cases: the “over-estimation” case where the prediction is greater than the actual usage and the “under-estimation” case where the prediction is less than the actual usage. For the over-estimated case, it may be fine as long as the prediction is less than the CPU utilization suggested by the worst-case analysis. However, for the under-estimated case, it may cause the problem of a task being unable to use a CPU for long enough before finishing its job. To evaluate each regression method from this criteria, we compute the ratio of the number of the predictions, which is greater (or less) than the actual utilizations, to the total number of the predictions. Table II shows these ratios, actual over- and underestimation amount of CPU time. For example, of four datasets, 62% of the “Logistic regression” outputs for the “Behavior” task were greater than the actual usages. In other words, 38% of the “Logistic regression” outputs for the same task were less than the actual usages.5 The numbers in the parenthesis provide further information about over- and under-estimation rates. Specifically, for those 62% outputs over-estimated, on average, 28.5% of the CPU time was estimated as more than the actual usages, and 2.9% of the CPU time was estimated as less than the actual usage. From this criteria, the regression tree with the bagging was the best regression method for the “Behavior” task. It showed that 64% (36%) of its outputs were over-estimated (under-estimated) than the actual CPU usages, and 1.6% CPU (5.1%) time was over-estimated (underestimated). Thus, one would like to have a method that shows a high over-estimation rate with both lower actual overestimation and lower under-estimation. If this condition is hard to achieve in practice, one would prefer a method having a high over-estimation rate with a low under-estimation. Overall, the regression methods did a reasonable performance in that their over-estimation rates were a bit low, but the actual underestimation of CPU time was not great – i.e., less than 10% of CPU time. For the “Mission Planning” task, the overestimation rates of all those regression methods were relatively high – greater than 78%. But, their actual under-estimation on CPU time was pretty high – greater than 30%. Although the actual effect of such a high under-estimation is dependent on various factors, this high, under-estimation is undesirable. In particular, what if the “Mission Planner” needs 100% of CPU time for a certain period but only 70% of CPU is available? A simple remedy for such cases is to increase the outputs of the best regression method by adding a constant term (e.g., 0.1). The second rows of each regression performance in Table II shows the performance gain when adding 0.1 to the regression outputs. Although the MSE and the amount of over-estimation were increased a bit, the performances of all five methods were drastically increased. For example, adding 0.1 to the outputs of the regression tree with bagging increased the over-estimation rate from 64% to 86%, while increasing 1.5% of the resource 5 Due to space constraints, we did not write this under-estimation ratios (100 - “over-estimation” rate) in the table.

3034

Behavior Mission Planning Traffic-based MP Traffic-free MP

0.6220 0.7606 0.7815 0.8022 0.6413 0.8783 0.0602 0.9937

LR (0.285/0.029) (0.276/0.018) (0.001/0.409) (0.011/0.198) (0.019/0.017) (0.039/0.013) (0.040/0.007) (0.008/0.009)

0.5647 0.8116 0.8088 0.8199 0.5669 0.8092 0.6281 0.9961

LI (0.029/0.075) (0.046/0.108) (0.013/0.329) (0.047/0.254) (0.008/0.010) (0.022/0.003) (0.000/0.001) (0.010/0.010)

0.5354 0.8820 0.8084 0.8294 0.5011 0.8009 0.5028 0.9972

RT (0.036/0.049) (0.037/0.128) (0.078/0.354) (0.113/0.292) (0.011/0.012) (0.025/0.007) (0.000/0.000) (0.010/0.008)

0.6440 0.8650 0.8042 0.8237 0.5399 0.8466 0.5322 0.9973

BA (0.016/0.051) (0.030/0.081) (0.033/0.325) (0.054/0.251) (0.007/0.008) (0.020/0.002) (0.000/0.000) (0.010/0.008)

0.5649 0.8110 0.8088 0.8199 0.5671 0.8093 0.6282 0.9961

GP (0.030/0.076) (0.046/0.108) (0.015/0.330) (0.046/0.254) (0.007/0.009) (0.022/0.003) (0.000/0.000) (0.003/0.010)

TABLE II: Experimental results. “LR” stands for the logistic regression, “LI” for the linear regression, “RT” for the regression tree, “BA” for the regression tree with the bagging, and “GP” for the Gaussian processess. “MP” stands for motion planning. The cells in bold-face are the best methods for the corresponding tasks. over-estimation. However, this should be done with caution because the constant term in fact corresponds to the percentage of the CPU time. For example, adding 0.1 to the outputs of a regression method means to increase 10% of a task’s expected CPU utilization. IV. C ONCLUSIONS AND F UTURE W ORK This work presented our initial efforts to develop a dataoriented, dynamic scheduling for real-time tasks. To achieve this goal, this paper presented as a first step, our effort to develop a method that predicts the CPU utilization patterns of dynamic tasks running on a self-driving car. To this end, we designed a feature vector to represent the internal and external states of a self-driving car and used five regression methods to predict the CPU usage patterns of four software tasks running on a self-driving car. Through testing with the actual driving data, we found that a regression method could be used to predict a software task’s dynamic CPU utilization. We used our expertise on autonomous driving to manually choose seven variables to represent the internal and external states of autonomous driving environments. It would be useful if such a feature selection process could be done automatically. As future work, we would like to further investigate the regularization methods for such an automatic feature selection. This work presented so as to guarantee the response time of a task, of (slightly over-) predicting CPU utilization of certain tasks in a self-driving car. To better understand how safe over (or under) estimation of CPU utilization is in terms of reliable autonomous driving, we would like to investigate the effects of, particularly, under-estimation of CPU utilization, and how to handle under-estimation of CPU utilization when it happens. ACKNOWLEDGMENT The authors would like to thank the members of GM-CMU Autonomous Driving Collaborative Research Lab (ADCRL) for their effort and dedication. R EFERENCES [1] Hossein Ahmadi, Tarek Abdelzaher, Jiawei Han, Nam Pham, and Raghu K. Ganti, The sparse regression cube: a reliable modeling technique for open cyber-physical systems, In Proceedings of the 2011 IEEE/ACM International Conference on Cyber-Physical Systems (ICCPS-11), pp. 8796, 2011. [2] Christopher Baker and John Dolan, Traffic interaction in the urban challenge: putting boss on its best behavior, In Proceedings of International Conference on Intelligent Robots and Systems (IROS 2008), pp. 17521758, 2008. [3] Christopher M. Bishop, Pattern Recognition and Machine Learning, Springer, 2007. [4] Francisco J. Cazorla et al., PROARTIS: probabilistically analyzable realtime systems, ACM Transactions on Embedded Computing Systems, 12(2): 1-26, 2013.

[5] Hyunggi Cho, Young-Woo Seo, B.V.K. Vijaya Kumar, and Raj Rajkumar, A multi-sensor fusion system for moving object detection and tracking in urban driving environments, In Proceedings of IEEE International Conference on Robotics and Automation (ICRA-2014), pp. 1836-1843, 2014. [6] Robert I. Davis and Alan Burns, A survey of hard real-time scheduling for multiprocessor systems, Journal of ACM Computing Surveys (CSUR), 43(4): 1-44, 2011. [7] David Ferguson, Chris Baker, Maxim Likhachev, and John Dolan, A reasoning framework for autonomous urban driving, In Proceedings of the IEEE Intelligent Vehicles Symposium (IV-08), pp. 775-780, 2008. [8] Tianyu Gu, Jarrod Snider, John M. Dolan, and Jin-Woo Lee, Focused trajectory planning for autonomous on-road driving, In Proceedings of IEEE Intelligent Vehicles Symposium (IV-13), pp. 547-552, 2013. [9] Jeffery Hansen, Scott A. Hissam, Gabriel A. Moreno, Statistical-based WCET estimation and validation, In Proceedings of Workshop on WorstCase Execution Time Analysis, 2009. [10] Hyoseung Kim, Junsung Kim and Raj Rajkumar, A Profiling Framework in Linux/RK and its Application, In Proceedings of RTSS@Work, the Open Demo Session of the 33rd Annual IEEE Real-Time Systems Symposium (RTSS-12), 2012. [11] Junsung Kim, Karthik Lakshmanan, and Raj Rajkumar, Rhythmic tasks: A new task model with continually varying periods for cyber-physical systems, In Proceedings of IEEE/ACM International Conference on CyberPhysical Systems (ICCPS), pp. 55-64, 2012 [12] J. Lehoczky, Fixed priority scheduling of period task sets with arbitrary deadlines, In Proceedings of IEEE Real-Time Systems Symposium, pp. 201-209, 1990. [13] Chung Laung Liu and James W. Layland, Scheduling algorithms for multiprogramming in a hard-real-time environment, Journal of the ACM, 20(1): 46-61, 1973. [14] Matthew McNaughton, Christopher R Baker, Tugrul Galatali, Bryan Salesky, Chris Urmson, and Jason Ziglar, Software infrastructure for an autonomous ground vehicle, Journal of Aerospace Computing, Information, and Communication, 12(5): 491-505, 2008. [15] Muntz, R. R. Muntz and E. G. Coffman, Preemptive Scheduling of RealTime Tasks on Multiprocessor Systems, Journal of The ACM, 17(2): 324338, 1970. [16] Shuichi Oikawa and Ragunathan (Raj) Rajkumar, Linux/RK: a portable resource kernel in Linux, In Proceedings of Real-Time Systems Sumposium (RTSS) Work-In-Progress, 1998. [17] Ragunathan (Raj) Rajkumar, Synchronization in Real-Time Systems: A Priority Inheritance Approach, 1991. [18] Carl E. Rasmussen and Chris Williams, Gaussian Processes for Machine Learning, MIT Press, 2006. [19] Julian L. Rrushi and Kyoung-Don Kang, CyberRadar: a regression analysis approach to the identification of cyber-physical mappings in process control systems, In Proceedings of IEEE/ACM Workshop on Embedded Systems Security, 2008. [20] Chris Urmson et al., Autonomous driving in urban environments: boss and the urban challenge, Journal of Field Robotics, Special Issue on the 2007 DARPA Urban Challenge, Part I, 25(8): 425-466, 2008. [21] Junqing Wei, Jarrod Snider, Junsung Kim, John Dolan, Raj Rajkumar, and Bakhtiar Litkouhi, Towards a viable autonomous driving research platform, In Proceedings of IEEE Intelligent Vehicles Symposium (IV-13), pp. 763-770, 2013.

3035