Extensible and Scalable Time Triggered Scheduling - Semantic Scholar

Extensible and Scalable Time Triggered Scheduling Wei Zheng University of California, Berkeley [email protected] Claudio Pinello Quantech Global Services [email protected]

Jike Chong University of California, Berkeley [email protected]

Sri Kanajan General Motors [email protected]

Abstract The objective of this paper is to present how to design a system that can accommodate additional functionality with either no changes to the design or adding architectural modules without changing the implementation of the legacy functionality. This objective is very relevant to industrial domains where an architecture is designed before the full range of functionalities to support is known. We focus on an important aspect of the design of automotive systems: the scheduling problem for hard real time distributed embedded systems. Two metrics are used to capture the design goals. The metrics are optimized subject to a set of constraints within a mathematical programming framework. The cost of modifying a legacy system is characterized at an Electrical Control Unit (ECU) component level. Results obtained in automotive applications show that the optimization framework is effective in reducing development and re-verification efforts after incremental design changes.

1. Introduction Automotive manufacturers such as General Motors (GM) have adopted a product-line design approach to manage complexity and reduce cost. The mantra of this design paradigm is component reuse and incremental design. Following this approach, substantial savings in Non Recurring Engineering (NRE) costs and time-tomarket can be achieved. In this paper, we focus on a relevant, albeit particular, design aspect: bus and task scheduling for a time-triggered distributed system. We study ways of making this scheduling robust with respect to variations in number and type of functionality that the architecture must be able to support.

Alberto Sangiovanni-Vincentelli University of California, Berkeley [email protected]

Our overall approach is based on the principle of orthogonalization of concerns[11]. In this paradigm, divide and conquer strategies are used to tame complexity. A fundamental aspect of our design approach is the orthogonalization of function and architecture. In this approach, a functional description and a set of virtual architectural components are given first and then a mapping process is used to associate functional components to architectural components. For this reason, the starting point of our flow is assumed to be: 1. A Directed Acyclic Graph (DAG) capturing the relationships among tasks; 2. The physical architecture of the system. Scheduling can be considered as an integral part of the design process. Optimal mapping of functionality to architecture implies solving the scheduling problem to provide a metric for the quality of the mapped design. Thus, in an ideal case, scheduling and mapping are intertwined. However, this approach may result in an overwhelming computational cost. We prefer to follow once more a divide and conquer approach that is also effectively used in industry (see Zakarian et al [13] and the design flow followed at GM): we assume that the mapping of functionality to architecture is given prior to and independent from the design of the schedule. Two metrics, extensibility and scalability, are used to optimize a schedule that could accommodate incremental design changes. Our formulation assumes statically scheduled tasks with data dependencies in a distributed and heterogeneous multi-processor architecture. The bus is time triggered. We allow preemption in the ECUs and accommodate multi-rate tasks using task graph expansion (TGE). All tasks are allocated a priori, and task migration across ECUs is not allowed (see figure 1). The optimization problem is cast in a mathematical programming framework.

3, extensibility and scalability metrics are illustrated. In Section 4, a case study and experimental results are presented to show the effectiveness of our approach in finding schedules that require minimum modifications to accommodate incremental changes. Finally in Section 5 and 6 concluding remarks are offered with future work.

2. Preliminaries and Basic Definitions Figure 1. System design flow

2.1. Functionality Representation There is a wide body of previous work in static cyclic scheduling and real time scheduling for control applications that are relevant for our discussion, for example, [12][7][3][8][9]. Classical scheduling theory typically uses metrics such as the sum of completion times, scheduling length, resource usage or the maximum lateness [12]. As the deadline constraints are added for real time control systems, the emphasis is shifted to finding a feasible solution while minimizing metrics such as end-to-end delay, overall processor cost, and/or overall communication cost [3]. Mathematical programming is used in [7] for mapping and scheduling of homogeneous multi-processor real time system. Pop’s work [9] is the one that comes closer to our approach as the concept of incremental design is present in his work in a predominant way. In Pop’s work, an improved list scheduling approach is used to obtain a valid schedule; a future task profile must be specified in order to develop task slacks by a bin packing process on the processing elements. Compared to his approach, our incremental design flow does not require a particular specification of future task profile, it provides a generalized solution that will redistribute slacks among all tasks and targets all variations of future task sets. Pop’s approach handles multi-rate tasks with dummy tasks and dummy resources, which may increase problem complexity. We handle multi-rate tasks with task graph expansion and assignments of release time and deadlines, which are intrinsic to our problem formulation. We also use preemption as a degree of freedom in scheduling to enhance extensibility and scalability. However, mapping of functionality to hardware components is assumed to be a degree of freedom for Pop, whereas our work assumes this mapping is given1. The paper is organized as follows: In Section 2, preliminary remarks, basic definitions and the formulation of the feasibility constraints are presented. In Section

2.2. System Architecture Representation

1 A quantitative comparison with Pop’s work is not possible at this point because of the difficulties in re-constructing the list scheduling algorithm from scratch, and the lack of an example data set in Pop’s work to compare to.

The architecture is also represented by a graph. We consider a distributed architecture consisting of a set of N possibly heterogeneous ECU’s interconnected with

The function of a system is represented by a task graph as in figures 2 and 8. The task graph is a DAG. Each node of the DAG represents a task, which is a sequence of instructions to be executed on a processing unit; each edge represents a data dependency between two tasks, the source task must complete before the destination task can begin. A task graph could contain more than one disconnected partitions. Each disconnected partition represents an independent thread of application. Each task has a period that is an integer value that determines how often a task should be executed. The super period is the least common multiple of all task periods. All tasks in a task graph are scheduled within one super period. Time is expressed relative to the beginning of the super period. A task might be repeated to match the super period by applying TGE, see figure 2.

Figure 2. Mapping and task graph expansion

one time-triggered bus. Every node has the architecture indicated in figure 3.

a set of task pairs with no DD* on the same ECU {(ti , tj )|ti , tj ∈ κuk , ti ≺ tj , uk ∈ }  a set of task pairs with DD* on different ECU {(ti , tj )|ti ∈ τ, tj ∈ τ, ti ≺ tj , ati ,uk +atj ,uk ≤ 1}

θ

∗1 ati ,uj = 1: task ti is allocated on ECU uj ti ≺ tj : task ti must precede tj because of DD* ti ≺ tj : ti and tj have no DD* ti = tj : ti and tj are different tasks DD*: data-dependency

Figure 3. Time-triggered node architecture

This basic node architecture is consistent with the Flexray protocol that has been chosen by several players (such as GM, BMW and Daimler-Chrysler) in the automotive domain as the backbone for future distributed control systems. The Flexray [1] protocol has features that can support high bandwidth and fault tolerance. The bus is implemented with a time-division multiple-access (TDMA) scheme. Each ECU is allocated a predetermined set of time slots on the bus. For a first order approximation, we assume that slots and TDMA rounds can have arbitrary size. A message is defined as the data dependence between two tasks allocated on different ECUs. We assume point-to-point multi-cast communication. If a task tj produces the same data for tasks ti and tk , we model this as two distinct data dependencies and produce two messages on the bus. The TDMA slot allocation is statically scheduled and programmed into each ECU’s bus controller. This implies that the cost of a design change is the number of ECUs we need to reprogram to obtain a new valid schedule.

Figure 4. Task properties for T3 Parameters and Variables: A task ti with period qti , deadline dti released at rti , with WCET eti , starts to execute at sti and finishes at time fti . A message sent from task ti to task tj starts to transmit on the bus m at time sm ti ,tj , with WCTT tti ,tj , and finishes transmism sion at time ft ,t . In summary (figure 5), we use a i j 7-tuple of real-valued parameters and variables to describe a task, and a 4-tuple to describe a message. Only the start and finish time are variables, idle time is an intermediate variable, all the others are parameters given by the problem specification.

2.3. Notations A short summary of the notations used in mathematical programming framework is given first. The properties with respect to task t3 is illustrated in figure 4 Sets τ a set of tasks τ = {ti |i = 1, ..., n}  a set of ECUs  = {ui |i = 1, ..., m} λ a set of task allocation for ECUs {κuk |uk ∈ } (κuk = {ti |ati ,uk = 1}) ∗1 π a set of task pairs running on the same ECU {(ti , tj )|ti , tj ∈ κuk , ti = tj , uk ∈ } σ a set of task pairs with DD* on the same ECU {(ti , tj )|ti , tj ∈ κuk , ti ≺ tj , uk ∈ }

Figure 5. Task and message parameters and variables We use binary decision variables to set precedence between tasks, precedence between messages, and describe preemption between tasks:


yti ,tj =
pti ,tj = zti ,tj ,tk ,tl

0, if start time of ti precedes start time of tj 1, otherwise 0, if task ti is not preempted by task tj 1, otherwise  0, if message transmitted between ti ,tj precedes message between tk ,tl = 1, otherwise

Binary variable yti ,tj is used to specify which task runs first in task pair set θ. For task pairs in the set σ, yti ,tj is implicit. zti ,tj ,tk ,tl specifies message precedence on the bus. We use pti ,tj to specify whether task ti is preempted by task tj .

source task to finish, then the destination task can begin. For data dependent task pairs on different ECUs, equation 6 ensures the source task finishes before the message can begin, and equation 7 ensures the message finishes before the destination task can begin. fti ≤ stj

(ti , tj ) ∈ σ

fti ≤ sm t ,t

(ti , tj ) ∈ 

(6)

ftm,t ≤ stj

(ti , tj ) ∈ 

(7)

i

i

j

j

Task Mutually Exclusive Constraints: A schedule implies an order for tasks to execute on each ECU. The binary decision variable yti ,tj describes the precedence order for a pair of tasks with no data dependencies on the same ECU. Order is implied for task pairs set σ, the set of data-dependent task pairs on the same ECU.

2.4. Feasibility Constraints

sti < stj + yti ,tj × M

A schedule is feasible if it satisfies the constraints imposed by the architecture: • Each ECU cannot process more than one task concurrently, although a task could be suspended to allow another task to execute, i.e., we allow preemption. • The bus can only transmit one message at a time. • There is no preemption for the messages.

(5)

(ti , tj ) ∈ θ

stj < sti + (1 − yti ,tj ) × M

(ti , tj ) ∈ θ

(8) (9)

M is a large constant used in mathematical programming to allow both equations to be valid given the binary variable yti ,tj . Task mutual exclusivity is defined only on the task start time. Task finish time is dependent on the preemption state between the task pair. Preemption Constraints: The preemption constraints describes the finish time behavior when one task preempts the other in θ, the set of task pairs on the same ECU with no data dependency.

• Collision of messages implies infeasible schedule.

fti ≤ stj + yti ,tj × M + pti ,tj × M (ti , tj ) ∈ θ (10)

In the following paragraphs, we formulate all the architectural constraints so that a mathematical program can be set up. Release and Deadline Constraints: A hard real time system requires all tasks to start after their release time, and finish before their deadlines.

ftj < fti + yti ,tj × M + (1 − pti ,tj ) × M (ti , tj ) ∈ θ (11) pti ,tj + ptj ,ti ≤ 1 (ti , tj ) ∈ θ, (tj , ti ) ∈ θ (12)

rti ≤ sti , ti ∈ τ

(1)

fti ≤ dti , ti ∈ τ

(2)

Task and Message Constraints: A task ti in execution may be preempted by another task tj , which may again be preempted by some other tasks. Task ti resumes its execution after task tj finishes. A message is not allowed to be preempted by another message during its transmission. Its finish time is trivially calculated. fti = sti + eti + Σ(ti ,tj )∈θ (pti ,tj × etj ) m ftm,t = sm t ,t + tt ,t i

j

i

j

i

j

(ti , tj ) ∈ 

pti ,tj ≤ 1 − yti ,tj

m m sm t ,t + tt ,t ≤ st ,t + zti ,tj ,tk ,tl × M i

Data Dependency Constraints: For data dependent task pairs on the same ECU, equation 5 restrict the

(13)

When task ti precedes task tj and is also preempted by tj , equation 11 ensures that the finish time of task tj is earlier than the finish time of task ti . Equation 12 prevents task pair ti and tj from preempting each other. Equation 13 describes the constraint that tj can preempt ti only if tj starts after ti . Message Mutually Exclusive Constraints: The binary decision variable zti ,tj ,tk ,tl describes the precedence order for a pair of messages on the bus. There is no preemption on the bus, so finish time is only dependent on message start time, WCTT, and precedence order.

(3) (4)

(ti , tj ) ∈ θ

j

i

j

k

l

(14)

m m sm t ,t + tt ,t ≤ st ,t + (1 − zti ,tj ,tk ,tl ) × M (15) k

l

k

l

i

j

where (ti , tj ) ∈
, (tk , tl ) ∈
, i = k, or, j = l

3. Extensibility and Scalability Metrics The extensibility and scalability metrics provide upper bounds to the amount of incremental design changes a schedule can accommodate. This involves providing blocks of idle times on the ECUs for computationally intensive tasks, and providing porosity in the schedule to accommodate tasks with tight deadlines.

3.1. Motivations and Definitions The motivation for selecting an extensible and scalable schedule is to allow maximal incremental design changes to an existing design without modifying the existing schedule. This reduces the need of revalidating a schedule upon design changes. A schedule is a list of sti for tasks and sm ti ,tj for messages that satisfies all constraints of the system. If an incremental design change does not violate any system constraints using the existing schedule, we say the schedule can tolerate the incremental change. An incremental change in the schedule can be a change of worst case execution time (WCET) for an existing task; a change of worst case transmission time (WCTT) for an existing message; the addition of a new task on an ECU, or a new message on the bus. There are some limitations to the types of incremental design changes considered. A new task or message must have a period that is a factor of the existing super period, such that the size of the super period is maintained when accommodating the change. Extensibility Metric for Tasks: The extensibility metric for a task describes the maximum task WCET extension a schedule can accommodate without rescheduling. This corresponds to the Real slack illustrated for T 1 in figure 6. We allow stack-based preemption in executing tasks on the ECUs, so a task ti may extend its finish time beyond the start time of the next task tj on ECU uk . Execution of ti can resume after tj finishes, as long as ti finishes before the next data dependency of ti . Numerically, the slack for task ti is the sum of all idle time on uk between finish time of ti and ιi , where ιi is the earliest of the three times below: a) start time of next dependent task on uk b) start time of next dependent message c) deadline of task ti Intuitively, ti is allowed to extend through all idle times on uk as long as it does not violate data dependency constraints and finishes before its deadline. Extensibility Metric for Messages: The extensibility metric for a message describes the maximum message WCTT extension a schedule can accommodate by

a) start time of next dependent task on uk b) start time of next dependent message c) deadline of task ti Real slack for T 11 is the idle time on ECU1 between T 11 finish time and time (b).

Figure 6. Extensibility metric illustration

rescheduling the finish time of the message between the source ECU and the destination ECU. Since preemption is not allowed on the bus, the slack for a message is the bus idle time between its finish time and the earlier of the 2 times between a) start time of the next massage and b) start time of the destination task. Scalability Metric for Tasks: The scalability metric for an ECU describes the maximum WCET a schedule can accommodate for a new independent task with certain period. The new task must be executed before its deadline. As preemption is allowed, all idle time in a period can be used by a new independent task. If the task period is less than the super period, the task is repeated through TGE. Each repetition must contain enough idle time to accommodate the new task. Figure 7 shows the largest task of period 2 that can be accommodated on ECU1. Numerically, the maximum WCET of a new task tk that could be accommodated in the existing schedule is defined as the minimum of all idle time across all repetitions of the period. Intuitively, all repetitions of the new task must fit into their respective period. The period with the least amount of idle time limits the size of the new task that can be accommodated.

Note: The maximum WCET of a new task tk that could be accommodated is the minimum of idle time in period 1 and idle time in period 2.

Figure 7. Scalability metric illustration

Scalability Metric for Messages: The scalability metric for the bus describes the maximum WCTT a schedule can accommodate for a new independent message. Preemption is not allowed on the bus, so for a new message with a specific period, the maximum WCTT that could be accommodated is the largest contiguous block of idle time within that period. Numerically, the metric is defined as the minimum of such largest contiguous idle time blocks across all repetitions of the period. Intuitively, all repetitions of the new message must fit into their respective period. The largest contiguous idle time in each period limits the size of messages they can accommodate.

3.2. Formulating Intermediate Variables The mathematical representation of extensibility and scalability metrics contains min and max functions that are piece-wise linear which would increase computation complexity of the problem. We use a formulation approach, compute task and message idle times as an intermediate variable, to avoid explicitly using the min and max functions. Task idle time: Task idle time ιti is computed with respect to the task ti . It represent a continuous segment of idle time after the task finish time fti on an ECU uk . Task idle time is found to be a good approximation for the extensibility metric for tasks as defined in section 3.1. The first segment of idle time on an ECU uk occurs before the first task, and is not associated with any task. It is represented as ιbf uk , where bf means before first. ιbf uk

≤ sti ,

uk ∈ , ti ∈ κuk

tj ∈κuk

m ιm,bf ti ,tj ≤ sti ,tj

(21)

m m ιm ti ,tj ≤ (stk ,l − fti ,tj ) + zti ,tj ,k ,l × M

(22)

m ιm ti ,tj ≤ P − fti ,j

(23)

(16)

ιti ≤ (stj − fti )+ yti ,tj × M + pti ,tj × M, (ti , tj ) ∈ π (17) ιtj ≤ 0+yti ,tj ×M +(1−pti,tj )×M, (ti , tj ) ∈ π (18) ιti ≤ P − fti , ti ∈ τ   ιtj + ιbf etj , uk ∈  uk = P −

ti , the result of the first component is invalid, the preemption state variable pti ,tj becomes “1”, and the RHS is discarded. In the case ti is before tj and no preemption exist between ti and tj , after considering all task pairs π, ιti is assigned with the idle time of ti . Equation 18 describes a special case in the idle time calculation. If task tj preempts task ti , ti should resume execution immediately after tj finishes. Under this condition, (yti ,tj = 0) and (pti ,tj = 1), and ιtj is assigned with “0”. The idle time after the last task on an ECU cannot be calculated by equations 17 and 18. Assuming there are no tasks after ti , idle time ιti is between task finish time fti and super period P . This is an upper bound for ιti . If there is some task after ti , a lower value for ιti will be assigned in equation 17 or 18. Since the mathematical programming uses ≤ to describe constraints, we need to find the largest set of task idle time described in the above equations. We use equation 20 to ensure sum of all task idle times (LHS) is equal to the super period P minus the sum of all execution times of tasks on ECU uk . Message idle time: Similarly, idle times on the bus could also be calculated using this framework. We associate each message on the bus with an idle time ιm ti ,tj , which is the time between message finish time ftm , i ,tj . and the next message start time sm tk ,l

(19) (20)

tj ∈κuk

The first idle time on ECU uk is assigned with the earliest task start time sti in equation 16. The idle times between tasks are computed in equation 17. There are three components summed together on the right hand side (RHS). To calculated idle time for task ti , first component assumes ti is before tj , and finds the idle time between finish time fti and start time stj . The second component checks if ti is before tj . If ti is not scheduled before tj , the precedence variable yti ,tj becomes “1”, and the RHS sum is discarded. The third component checks if tj preempts ti . If tj preempts

Where (ti , tj ) ∈ , (tk , tl ) ∈ , i = k, or, j = l   m,bf ιm eti ,tj (24) ti ,tj + ιbus = P − (ti ,tj )∈

(ti ,tj )∈

3.3. Multi-Objective Cost Function We choose to approximate the metrics so the formulation becomes practically solvable. The cost functions we considered here are: M axE =



m wti ,tj ×((sm ti ,tj −fti )+(stj −fti ,tj ))

(ti ,tj )∈

M inS =

 uj ∈ ti ∈τ

ati ,uj ×(ιti −αuj )2 +



(25) 2 (ιm ti ,tj −αbus )

(ti ,tj )∈

(26)

M ax

ES = k1 × E − k2 × S

(27)

αuj is the average idle time on ECU uj αbus is the average idle time on the bus

In equation 25, wti ,tj is a weight parameter to task pairs in . It allows the relative weights to be adjusted across different task pairs. (sm ti ,tj − fti ) calculates the source task slack to the dependent message, ) calculates the message slack to the and (stj − ftm i ,tj destination task. We maximize these metrics to widen the time window in which a message could be scheduled. This approximation is derived from condition (b) in figure 6. A larger weight on one task pair allows the solver to favor that set of slacks at the expense of slacks else where. We maximize the sum over all the slacks associated with each task and each message to make the schedule more extensible. For equation 26, we want to distribute the idle time more evenly by minimizing the variance of idle time segments in the ECUs and on the bus. This allows more porosity in the schedule to accommodate new task and messages in various time segments in a super period. If a new task can not fit in one continuous ECU idle time segment, it can be preempted by legacy tasks and still be scheduled. If a new message can not fit in one continuous bus idle time segment, we need to move as few legacy messages as needed to accommodate the new message. Based on these extensible and scalable approximation cost function, it is possible to jointly consider them in equation 27 by using coefficients k1 and k2 . We customly optimized the relative importance of the extensibility and scalability components to be k1 = 7 and k2 = 2 for our test case.

4. Case Study Illustration 4.1. Experimental infrastructure The formulation is described by AMPL, a mathematical programming modeling language. ILOG CPLEX 9.0.0 optimization solver is used on i686 or equivalent server running Linux. Data from results generated are plotted and extracted with our own interpreters.

4.2. System Description We present a set of advanced automotive control application case used by Nagarajan et al [4]. The system contains three threads of control: adaptive cruise control (ACC), electric power steering (EPS), and traction control (TC). Data is collected from sensors and processed in one or more ECUs. The ECUs then control actuators to respond to the sensed environment. ACC maintains safe distance between two cars. EPS provides assistance to steering. TC actively stabilizes the vehicle under slippery road conditions. These functions are mapped to an architecture with 10 sensors, 3 ECUs, and 4 actuators. The scheduling problem contains 24 tasks, of which 6 are expanded using TGE. During the TGE, a task Tn is renamed to T n i, where n is the task ID shown in the Function Graph, and i is the natural number representing the instance it appears in. As these are safety critical functions in a vehicle, all deadlines must be met. The input data used in the case study is included in figure 10.

3.4. Cost Function Evaluation based on Metrics The extensibility and scalability metrics described in section 3.1 is approximated into a multi-objective cost function in section 3.3. To evaluate the effectiveness of this approximation, we need to solve a real industrial problem by applying the approximated multi-objective cost function, and extract extensibility and scalability metrics from the resulting schedule. The extraction can be applied to the scheduling result outside the mathematical programming framework. The extraction follows exactly the metrics described in section 3.1. Therefore it is an objective monitor of the effectiveness of objective functions in approximating the metrics.

Figure 8. Case study functionality graph

4.3. Optimizing Scheduling A typical scheduling heuristic for distributed embedd system is minimizing schedule end-to-end delay.

the actuator nodes. In the optimized schedule, slacks are more distributed among the sensors and tasks on processors, allowing more flexibilities for incremental changes to the WCET of sensors and tasks, thereby increases extensibility of the schedule.

Figure 9. Case study architecture graph

Dark bars: Real task slack from the traditional schedule. Light bars: Real task slack from the optimized schedule. Graph shows redistribution of slacks. Top table: Task WCET in number of time units Bottom table: Message WCTT in number of time units

Figure 10. Data used for case study We compare this heuristic with our extensible and scalable scheduling scheme optimized with respect to our cost function. • Traditional schedule: minimize end-to-end delay • Optimized schedule: maximize extensibility and scalability When scheduled for minimum end-to-end delay, the function consumes approximately 3/4 of the available super period. This implies a 33% margin for future incremental developments. The cost function abstracted from extensibility and scalability metrics utilizes this margin to enhance the schedule. Extensibility is captured by quantifying the maximum slack of a task in a schedule. It is the upper bound of task WCET extension the schedule can accommodate. The task slacks, as defined in section 3, are extracted from the two schedules. In figure 11, the y-axis shows task slack for each task, and the x-axis is ordered with respect to task start times. The lighter bars correspond to the schedule obtained by optimizing with respect to our cost function, hence the optimized schedule. The darker bars correspond to the traditional schedule. Compared to the traditional schedule, the total slack in the optimized schedule increased significantly from 170.3 to 189.6 units of time. In the traditional schedule, slacks are accumulated at the end of

Figure 11. Extensibility metric evaluation Scalability is captured by quantifying the maximum new task size the schedule can accommodate with certain periods. The ECU scalability, i.e. scalability for tasks, is defined in section 3. In figure 12, the vertical axis represents the period of the new tasks to be added, and the horizontal axis represents the cumulative idle time in one period on all processor ECUs. Darker bars correspond to the traditional schedule, and lighter bars correspond to the optimized schedule. For all possible periods of a potential new task, the optimized schedule can accommodate longer WCET than the traditional one. This shows the effectiveness in the multi-objective function for optimizing scalability.

4.4. Scenario Illustrations We use three incremental design scenarios to illustrate the effectiveness of our metrics in handling design changes. These scenarios correspond to specific future application profiles used by Pop [9]. The first two contains changes to the EPS unit. The third one concerns changes to the ACC unit. We apply the scenarios to the traditional and optimized schedules in section 4.3. Changes to a task start time would result in ECU re-programming. Changes to message start or end time implies re-programming both the message source and destination ECU. We compute the minimum number of ECUs that must be reprogrammed to achieve a feasible schedule. New tasks and messages are scheduled on a legacy schedule by fixing start times of legacy tasks and mes-

Light bars: Upper bound of new task size - optimized schedule. Dark bars: Upper bound of new task size - traditional schedule. Graph shows potential for tasks to be added at various periods.

Figure 12. Scalability metric evaluation sages. The legacy decision binary variable values are implied by the legacy start times. If we can find a solution, we have accommodated the change, otherwise, the legacy start times on ECUs are relaxed until a solution is found. The ECU count is confirmed with a rescheduling of only the reprogrammed ECU, all other ECU schedules are kept fixed. This ECU reschedule count is an indicator of the amount of re-verification that is required by the incremental change. See table 1 for results. Table 1. Incremental change evaluation Scenario Traditional Result Optimized Result Scenario one 15 1 Scenario two 8 3 Scenario three 8 5 * Value shows number of ECU requiring reprogramming

Scenario one is a simple illustration of the effectiveness of our approach. A tightly coupled schedule as in the traditional schedule responds poorly to small incremental changes. A small increase in one task execution time requires 15 out of 17 ECUs in the system to be reprogrammed. As messages in the bus are forced to shift, the change is propagated to almost all ECUs. In the optimized schedule, T 4 has enough slack for the change to be accommodated by reprogramming only one ECU. Scenario two describes an incremental change on EPS involving 3 ECUs. In the traditional schedule, a shift of legacy tasks induces a message shift, and causes an avalanche effect to shifts on more ECUs. One important observation is that there are two instances of T 4 involved, the first required the most amount of reprogramming, while the second utilizes the slacks at the end of the cycle and required minimal amount of re-

Scenario one - Hand Wheel Effort Upgrade: allows different drivers to select profiles of desired force feedback on the steering wheel based on road conditions; WCET of Hand Wheel Effort + 1 Scenario two - Enhanced Steering: uses Road-Wheel Force as input; requires Tnew to be added between T 2 and T 5 on P 2; Two new messages: T 2 to Tnew and Tnew to T 5 Scenario three - Upgrade to Stop-N-Go ACC: predict desired speed based on digital map information and forward looking sensor; add Tadd to P 1; extend existing task T 10; Two new messages: T 7 to T 11, T 19 to T 10

Figure 13. Incremental design scenarios programming. In the optimized schedule, the scalability metric is effective in spreading out tasks on the ECUs and the messages on the bus such that idle time slots are available to accommodate the new tasks and messages. Only the 3 involved ECUs are re-programmed. Scenario three is the largest incremental change we analyzed. It involves one new task, one task extension and two new messages. Five ECUs are used to implement the changes. In the traditional result, similar change propagation mechanisms affect a total of 8 ECUs. In the optimized result, only the necessary five ECUs require re-programming.

5. Conclusions We have presented a design flow and a time-triggered scheduling approach that encapsulates the requirements for a product line with an incremental design approach. Deploying this approach requires conformance to automotive standards, especially the ones corresponding to time-triggered operating systems (OSEK) and the communication bus protocol (FlexRay). We captured the need for accommodating incremental changes without perturbing the initial design by defining appropriate extensibility and scalability metrics. The scheduling problem was cast as a mathemat-

ical programming optimization problem, with multiobjective cost functions derived from the metrics. The results based upon automotive design scenarios, show marked improvement in comparison to traditional scheduling approaches.

6. Future Work The multiple ECUs (processors) scheduling problem we focused on is an NP-hard problem. The complexity mainly resides in solving for the precedence binary variable yti ,tj and zti ,tj ,tk ,tl . To deal with larger problem sizes, we could use a heuristic to obtain a feasible solution first, lock down all precedence binary variables, then use our cost function to optimize. To mitigate the possibility of getting locked into a suboptimal ordering, algorithms could be used to perturb a feasible ordering toward a better solution. Future work will also include taking into account Flexray protocol details such as communication cycle length, homogeneous slot sizes and multi cycle transmit flexibility.

7. Acknowledgements We would like to acknowledge the constructive comments discussions of Professor Kurt Keutzer and General Motors Research staff, specifically Mira Supal, Thomas Fuhrman, Arnold Millsap, Tom Forest, Shengbing Jiang and Pradyumna Mishra.

References [1] Flexray-specification. www.flexray.com. [2] Osek group, osek-vdx: Time-triggered operating system specification 1.0. July 2001. http://www. osek-vdx.org/mirror/ttos10.pdf. [3] A. Bender. Design of an optimal loosely coupled heterogeneous multiprocessor system. Proc. Electronic Design and Test Conference, pages 275–281, 1996. [4] N. Kandasamy, J. P. Hayes, and B. T. Murray. Dependable communication synthesis for distributed embedded systems. Proc. 22nd Int’l Conf. on Computer Safety, Reliability, Security (SAFECOMP), 2003. [5] H. Kopetz. Real-time systems-design principles for distributed embedded applications. Kluwer Academic Publishers, 1997. [6] C. L. Liu and J. W. Layland. Scheduling algorithms for multiprogramming in a hard-real-time environment. J. ACM, pages 46–61, 1973. [7] W. Plishker, K. Ravindran, N. Shah, and K. Keutzer. Automated task allocation on single chip, hardware multithreaded, multiprocessor systems. Workshop on Embedded Parallel Architectures (WEPA-1), February 2004.

[8] P.Marti, R. Villa, J.M.Fuerte, and G. Fohler. Real time scheduling methods requirements in distributed control system. In 5th IFAC Workshop on Real-Time Programming (WRTP00), pages 101–108, May 2000. [9] P. Pop. Analysis and synthesis of communicationintensive heterogeneous real-time systems. Ph. D. Thesis No. 833, Dept. of Computer and Information Science, Linkping University, June 2003. [10] P. Pop, P. Eles, T. Pop, and Z. Peng. An approach to incremental design of distributed embedded systems. DAC ’01: Proceedings of the 38th conference on Design automation, pages 450–455, 2001. [11] A. L. Sangiovanni-Vincentelli, L. Carloni, F. D. Bernardinis, and M. Sgroi. Benefits and challenges for platform-based design. Proceedings of the Design Automation Conference (DAC’04), San Diego, CA, USA, pages 409–414, June 2004. [12] J. A. Stankovic and K. Ramamritham. Advances in realtime systems. IEEE Computer Society Press, 1993. [13] A. Zakarian and G. Rushton. Development of modular electrical systems. IEEE/ASME Transactions on Mechatronics, pages 507–520, December 2001.