Practcal Issues wth the Tmng Analyss of the Controller Area Network Marco D Natale Scuola Superore Sant Anna, Italy. Emal: marco@sssup.t Habo Zeng McGll Unversty, Canada. Emal: habo.zeng@mcgll.ca Abstract The Controller Area Network (CAN) bus s wdely used and has been studed n several research works to determne the worst-case response tme of messages. More results are beng added to study systems that are not constructed accordng to the deal behavor of the message queung and CAN controller assumed n the past. In ths paper, we provde an assessment on the practcal relevance of several of those results. We also present theory and emprcal studes on the relatve mportance of several mplementaton ssues that are qute common n real systems and further devate from the deal behavor. In addton, we propose a heurstc for the desgn of multple software queues when usng TxObjects wthout preempton, and derve an upper bound on the worst case response tme when message output at the CAN drver s pollng based. I. INTRODUCTION Snce ts development n the md 9s, the Controller Area Network (CAN) has attracted a sgnfcant amount of research from the real-tme systems communty. The CAN protocol adopts a collson detecton and resoluton scheme, where the message to be transmtted s chosen accordng to ts dentfer. When multple nodes need to transmt over the same bus, the lowest dentfer message s selected for transmsson. Ths arbtraton protocol allows encodng the message prorty nto the dentfer feld and mplementng prorty-based schedulng. The early analyss on the CAN message response tme [2] was derved by Tndell et al. out of an analogy to the CPU schedulng results. The analyss was later found to be flawed by Davs et al. [2], where a set of formulas s provded for the exact evaluaton and safe approxmaton of the worst case message response tmes. However, the schedulng on a CAN system may be a mult-level schedulng problem n several cases of practcal nterests. The lowest level deals wth the schedulng of the network medum. Above that, the transmt buffers (TxObjects) n the CAN controller need to be approprately assgned to messages, and a software queue at the drver or mddleware layer s used to manage the messages f no TxObject s avalable. The analyss methods [2] [2] are based on a number of assumptons at the mddleware, drver, and controller levels of the CAN communcaton stack that are seldom true n practcal systems (especally automotve systems). These dealzed assumptons nclude the exstence of a perfect prorty-based software queue at each node for the outgong messages, the avalablty of one TxObject for each message (or preemptablty of the TxObjects), and mmedate (zero-tme) copy of the hghest prorty message from the software queue to the TxObjects. Also, researchers tend to assume an assgnment of message dentfers close to Rate Monotonc (RM) or Deadlne Monotonc (DM) polcy, and a possble breakdown utlzaton for the CAN network that s arbtrarly close to %. When these assumptons do not hold, as s the case for many systems, the message response tme (or latency) can be larger than what s predcted by the analyss n [2]. A relatvely lmted number of studes has attempted at the analyss of the addtonal prorty nverson and blockng n the mddleware, devce drver, and CAN controller hardware. [5] [8] analyze the addtonal delay caused by non-abortable (and lmted number of) TxObjects at the CAN controller. Usng FIFO queung (or other polces that are work conservng) for messages nsde the CAN drver/mddleware layers s dscussed and analyzed n [3] [4]. [8] consders the addtonal source of prorty nverson where the copy tme from the message queue to the TxObject cannot be neglected. [7] uses real message traces to analyze more devatons from the assumptons made n the worst-case analyss [2]. In the followng, we wll dscuss the practcal relevance of [2], show several cases of devatons from such deal behavors, and explore the consequences. The paper contrbuton and organzaton are as follows. Secton II ntroduces the notatons and the deal schedulng model, and summarzes the analyss gven n [2]. It then uses random CAN systems to study the probablty when such an analyss s actually needed (the orgnal analyss n [2] s flawed). Secton III uses fve CAN bus confguratons from actual automotve systems to llustrate the realstc breakdown utlzaton n CAN consderng the fact that message dentfers are not assgned accordng to the Rate Monotonc polcy. Secton IV dscusses two cases where the deal schedulng model s volated. One s to consder the mpossblty of preemptng TxObjects (abortng message transmssons). We expermentally evaluate the mpact of ths polcy when the copy tme from the message queue to the TxObject s neglectable. A heurstc algorthm s provded to determne the mnmum number of TxObjects used by (software) message queues and the parttonng of messages among them, whch s shown to acheve optmalty for all our expermental automotve systems. The second case s when message output at the CAN drver s pollng based, for whch we derve an upper bound on the worst case message response tme. Fnally, Secton V concludes the paper.
II. AN UNLIKELY REFUTE The ttle of one of the recent and most popular papers on CAN worst-case tmng analyss s Controller Area Network (CAN) Schedulablty Analyss: Refuted, Revsted and Revsed [2]. It could not be more clear: there s a serous ssue wth the old analyss and nobody should use t. The paper ntroducng the correct analyss [2] starts wth an example system wth three messages that s not schedulable and yet s consdered as such by the prevous method n [2]. The three messages (A, B and C) have a transmsson tme of unt each and perods of, respectvely, 2.5, 3.5 and 3.5 unts (the utlzaton of the bus s approxmately 97.%). The prorty order (the dentfer assgnment) s such that A has a hgher prorty than B and then C. B,C A A B C A B A C 2 3 4 5 6 7 RC Fgure. The example from [2] showng the flaw n the analyss of [2]. For the analyss model, each perodc or sporadc message m s defned by the tuple m = {N,d,T,J,C,D } where N s the sendng node, d s the CAN dentfer, T s the perod or the mnmum nterarrval tme, J s the queung jtter (sometmes also referred to as release jtter), C s the transmsson tme, and D s the deadlne. The transmsson tme C s gven by the total number of transmtted bts (ncludng the stuffed bts) dvded by the bus transmsson rate. For m,thecrtcal nstant s the tme nstant where: ) the contenton on the bus has just won by the longest lower prorty message (f one exsts); 2) all the hgher prorty messages hp() become smultaneously ready and arrve at ther maxmum rates thereafter. The blockng tme,.e. the tme spent on watng for the transmsson of a lower prorty message already on the bus when m becomes ready, s denoted as B. Consder the analyss of message C n Fgure. Gven that C s the lowest-prorty message, there s no blockng tme. The crtcal nstant s represented n Fgure, wth all messages released at tme t =. Because of the mpossblty to preempt the transmsson of the frst nstance of C, the second nstance of message A s delayed, and, as a result, t pushes over the executon of the second nstance of C. The consequence s that the worst case response tme for message C does not occur at the frst nstance (transmtted after 3 tme unts), but at the second one, wth an actual response tme of 3.5 tme unts. The prevous (flawed and unsafe) analyss n [2] smply assumed that the worst case queung delay w could be determned on the frst nstance n the busy perod as w = B + w + J k + τ bt C k () k hp() where τ bt s the tme to transmt one bt of data on the bus. The fx [2] s obtaned by observng that the worst case response tme s always nsde the busy perod. To fnd the correct worst case response tme, the formula to be appled s a small modfcaton to [2] that checks all the q nstances of message m transmtted nsde the busy perod. Analytcally, the worst-case queung delay w (q) for the q-th nstance n the busy perod s w (q) =B + q C + w + J k + τ bt C k (2) k hp() T k The response tme of the q-th nstance s T k R (q) =J + w (q) q T + C (3) where q ranges from to the last nstance q max of m nsde the busy perod. The length of the longest busy perod L and the ndex of the last nstance can be calculated as L + J k + τ bt L = B + C k k=hp() T k {} (4) q max L + J = T The worst case message response tme s the maxmum among all ts nstances n the busy perod. R = max q=,...,q max{r (q)} (5) A. What Are the Chances that the Fx s Needed The example n [2] has three messages wth such a small perod that each of them takes about 3% of the bus utlzaton. For example, for the typcal bus speed at 5kbps, a message wth full sze (35 bts for standard CAN wth worst case bt stuffng) has a transmsson tme of.27ms. Ths mples a message perod of less than ms for a 3% utlzaton, whch would be unrealstc, even when assumng aperodc loads. In realty, a CAN bus typcally support tens of messages, each one wth a very small fracton of the system utlzaton. Also, nobody would desgn a message system that s on the brnk of feasblty. CAN transmsson may fal and lead to retransmssons, whch are not accounted for n the old analyss [2] or the new one [2] (but could be added wthout much dffculty [3] []). We perform experments to check n what cases the flaws of the analyss n [2] are actually exposed and requre the fx n [2]. We analyze fve bus confguratons taken from actual automotve systems (used also n the other sectons of the paper, one such message set s shown n Table I, another one s descrbed n [5]). In none of the fve real
bus confguratons there s any dfference between the results of the old formula and the new one. We also try randomly generated bus confguratons wth n =, 5, 2,..., 6 messages. For each n, 8 random sets are generated whch are consdered as schedulable by the analyss n [2]. The perods of the messages are generated by the product of one to three factors, each randomly drawn from three harmonc sets (2, 4), (6, 2), (5, ). In such a way, the message perods belong to at most three harmonc sets, as s the case for most applcatons of practcal nterest. For all messages, the deadlne s the same as the perod. In the random experments we try several bus speeds. The typcal automotve CAN bus has a transmsson speed of 5kbps. In the frst set of experments, all messages are assumed to have 8 bytes of data wth worst-case bt stuffng, thus the transmsson tme s.27ms. Out of the. 9 message sets, there are only 6 cases where the system s not schedulable accordng to the analyss n [2] (and the fx s requred). None of these 6 cases has more than 35 messages, and the lowest bus utlzaton among them s 99.8%. The experments wth a slower bus speed at 25kbps (and message transmsson tmes of.54ms) produce 52 message sets out of. bllon (less than one n a mllon cases) n whch the revsed analyss produced a dfferent result. None of these cases happens for a confguraton wth 35 messages or more, and the lowest bus utlzaton that requres a fx s 98.%. If we further slow down the bus speed to 25kbps (and message transmsson tmes of.8ms), a total of 54 message sets out of. 9 (slghtly more than one n a mllon cases) requres the fx from [2]. All these cases happen for a confguraton wth 3 messages or less, and the mnmum bus utlzaton s 97.74%. We repeat the experment assumng the message data length s unformly dstrbuted between and 8 bytes wth worst-case bt stuffng. For CAN bus wth 5kbps transmsson speed, there s no message set where the fx from [2] s requred. For CAN bus wth 25kbps and 25kbps, the number of message sets for whch [2] reports false postve schedulablty results s 25 and 877, respectvely. The lowest bus utlzaton among them s 89.39% for a set wth messages and 25kbps bus speed. The need to consder all the nstances n the busy perod, together wth the fact that the length of the busy perod s unknown n advance, results n an excessve complexty of the exact analyss [2] (mpossble to lnearze) for desgn optmzaton purposes. On the other hand, the probablty of the analyss n [2] (whch defnes a necessary condton for schedulablty) beng flawed s very small, whch ndcates a very good chance that the soluton obtaned usng ths condton s also feasble wth respect to the exact test. Gong back to our experments, 89.39% s a very hgh utlzaton, but there are several other ssues that are worth dscussng and lmt the bus utlzaton to much less than 9% or even 8%: Prortes are often not assgned accordng to the RM or DM polcy (Secton III); Messages may be dropped and retransmtted due to errors [3] []; Messages are not always queued by prorty, TxObjects are seldom preemptable, and message copy tme can be larger than the nterframe bts (Secton IV). The mpact of errors can be analyzed, by frst estmatng the number of transmsson errors, then consderng the error recovery overhead [3] []. We focus on the frst and thrd ssues n the followng. III. TYPICAL BREAKDOWN UTILIZATION The frst lmtaton n the use of the CAN bus bandwdth relates to the assgnment of dentfers to messages. Identfers defne the prorty of the messages. Therefore, we may expect that they are assgned to ease schedulablty as much as possble. Contrary to what was stated n [], the RM polcy s not necessarly optmal when schedulng perodc messages (wth blockng tmes) wth deadlnes equal to ther perods (ths was also noted n [2]): t suffces to consder the counterexample wth three messages havng transmsson tmes and perods m =(3, 5), m 2 =(2, 8), and m 3 =(, ). The RM prorty assgnment results n unschedulablty for m 3, but the system s schedulable f m has a hgher prorty than m 3 and then m 2. However, RM (or DM, n the case that the deadlne s smaller than the perod) s stll a very good heurstc for the assgnment of CAN message prortes, especally when the perods and transmsson tmes are realstc (typcally each message has no more than 5% of the bus utlzaton). Unfortunately, n many systems ncludng automotve applcatons, message dentfers are not necessarly assgned accordng to the message perods or deadlnes. Ths happens for a number of reasons. In automotve systems, each dentfer has been tradtonally assgned to match the functonal content of the message rather than ts crtcalty (or rate), such that messages wth dfferent perods but assocated wth the same functonalty are typcally assgned smlar dentfers. Ths s to ease the message flterng process at the recevng node, although at the expense of schedulablty. In other systems, for example, those usng J939 CAN [4] smart sensors, the dentfers of messages sent from a sensor are predetermned by the sensor manufacturer. Agan, ths has lttle to do wth the message perod (whch s often programmable). We use the breakdown utlzaton to llustrate the mpact of the fact that message dentfers are not assgned to maxmze schedulablty. The breakdown utlzaton of a CAN bus s defned as the the maxmum bus utlzaton (by scalng up the bus speed) at whch at least one message was found unschedulable. We compute the breakdown utlzaton usng fve CAN bus confguratons from actual automotve
Table I THE LIST OF MESSAGES IN ONE OF THE EXPERIMENTAL BUSES (unt for perods: ms; unt for message length: byte) m N T Len d m N T Len d m N T Len d m E 2 2.5 8 m 28 E 8 28 m 55 E 5 28 8 55 m 2 E 2 2.5 8 2 m 29 E 8 29 m 56 E 8 56 m 3 E 2 2.5 8 3 m 3 E 8 3 m 57 E 3 25 8 57 m 4 E 2 2.5 8 4 m 3 E 8 3 m 58 E 3 25 3 58 m 5 E 2 5 8 5 m 32 E 3 2 8 32 m 59 E 3 5 8 59 m 6 E 2 5 8 6 m 33 E 3 5 8 33 m 6 E 3 5 8 6 m 7 E 8 7 m 34 E 3 5 8 34 m 6 E 3 5 7 6 m 8 E 2 2 8 8 m 35 E 3 2 8 35 m 62 E 3 5 8 62 m 9 E 2 5 8 9 m 36 E 3 5 8 36 m 63 E 3 5 2 63 m E 2 25 8 m 37 E 3 2 8 37 m 64 E 3 8 64 m E 2 25 8 m 38 E 2 2 8 38 m 65 E 3 8 65 m 2 E 6 3 2 m 39 E 3 2 8 39 m 66 E 3 8 66 m 3 E 8 3 m 4 E 2 2 8 4 m 67 E 3 8 67 m 4 E 2 8 4 m 4 E 3 8 4 m 68 E 3 8 68 m 5 E 8 5 m 42 E 4 8 42 m 69 E 3 6 69 m 6 E 2 8 6 m 43 E 4 8 43 m 7 E 3 2 8 7 m 7 E 2 8 7 m 44 E 4 8 44 m 7 E 3 2 8 7 m 8 E 8 8 m 45 E 4 5 8 45 m 72 E 3 2 8 72 m 9 E 8 9 m 46 E 4 5 8 46 m 73 E 3 2 8 73 m 2 E 8 2 m 47 E 4 5 8 47 m 74 E 3 2 8 74 m 2 E 8 2 m 48 E 4 5 8 48 m 75 E 3 2 8 75 m 22 E 5 8 22 m 49 E 5 8 49 m 76 E 3 2 8 76 m 23 E 5 8 23 m 5 E 5 8 5 m 77 E 3 2 8 77 m 24 E 5 8 24 m 5 E 5 8 5 m 78 E 3 2 2 78 m 25 E 5 8 25 m 52 E 5 8 52 m 79 E 2 5 79 m 26 E 8 26 m 53 E 5 28 8 53 m 8 E 2 2 8 m 27 E 8 27 m 54 E 5 28 8 54 m 8 E 2 2 2 8 systems. Four CAN bus confguratons belong to an expermental vehcle, and the other one to a hybrd bus. Table I shows the message set n the hybrd bus (for IP protecton, the prorty order rather than the actual CAN dentfer s shown n the table), wth many volatons to the RM polcy. The results confrm that the breakdown utlzaton s sensbly lower than %. The hybrd bus has a CAN network (for whch the message set s shown n Table I) wth a breakdown utlzaton of 45.6%. For the four buses of the expermental vehcle, the hghest breakdown utlzaton s 9.6% for a bus that carres nformaton about objects detected n the envronment by a set of sensors (characterzed by a small number of sendng nodes and messages wth smlar perods). The next two buses (body nformaton, the detals of whch can be found n [5], and chasss wth sgnallng nformaton) have a breakdown utlzaton of 7.7% and 67.% respectvely. Fnally, another bus carryng general (not tme crtcal) nformaton has an even lower breakdown utlzaton at 36.8%. IV. MESSAGE QUEUING AND BUFFERING The confguraton and management of the perpheral TxObjects and the possble message queung are mportant n the evaluaton of the prorty nverson and the worst case blockng tmes for CAN messages. CAN controllers have a number of avalable transmt buffers (TxObjects). When the number of TxObjects avalable at the controller s smaller than the number of messages sent by the node (as s the case for automotve gateways and nodes wth lots of output nformaton, or when message recepton s pollng-based and a relatvely large number of buffers must be reserved to nput streams n order to avod message loss by overwrtng), t s necessary to use a software queue to hold messages watng to be coped to a TxObject. Several commercal drvers (ncludng those from Vector [], probably the most commonly used n automotve systems) allow to put the outgong messages n software queues as a temporary storage for accessng TxObjects. It s also qute common to use multple queues, wth each queue lnked to a sngle TxObject. When a TxObject s avalable, a message s extracted from the queue and coped nto t. In ths case, the preservaton of the prorty order of the messages n the access to the bus requres the followng: (a) The contents of the software queue must be kept sorted by message prorty (.e., by message dentfer). (b) When a TxObject becomes free, the hghest prorty message n the queue s mmedately extracted and coped nto the TxObject. (c) If a hgher prorty message becomes ready and all the TxObjects are used by lower prorty messages, the lowest prorty message n one of the TxObjects must be evcted and put back n the queue to ensure that a TxObject s avalable for the hghest prorty message. (d) Messages n the TxObjects must be sent n the order of ther CAN dentfers (prortes). If ths conflcts wth the transmsson order predefned by the hardware for the TxObjects, the poston of the messages n the TxObjects should be dynamcally rearranged. When any of these condtons does not hold, prorty nverson occurs and the worst case tmng analyss n [2] cannot be used. All these ssues are dscussed n [6] where the mpact of transmsson by pollng (as opposed to nterruptdrven) s also outlned. Usng FIFO or any work-conservng queung for messages nsde the CAN drver/mddleware layers ((a) n the prevous lst) s dscussed and analyzed n [3] [4]. [8] consders the addtonal source of prorty nverson where the copy tme from the message queue to the TxObject cannot be neglected ((b) n the lst). Here, we provde further nsght on the management of TxObjects wthout preempton ((c) n the lst) and pollng based message output at CAN drver (a further volaton of (b) n the lst). A. Impossblty of Preemptng the TxObjects Ideally, a message that s coped nsde a TxObject can be evcted from t (.e., the TxObject s preempted or the transmsson request s aborted), unless the transmsson has already started. However, the need to avod any type of drver complexty, even f at the possble expense of tme predctablty and prorty nverson, mpacts the TxObject management n many practcal systems. Qute often developers prefer not to remove a message from the TxObject, even f a hgher prorty message becomes ready.
Consder the case of a sngle queue sorted by prorty, where the messages use a sngle TxObject. The TxObject cannot be preempted, that s, when a (lower prorty) message s coped nto t, the other messages n the queue may be blocked watng for ts transmsson. In realty, the typcal system mplementaton prevents most cases of prorty nverson. The queung of the perodc messages n a node does not happen asynchronously, but s performed by a sngle perodc task, executed nsde the Interacton Layer []. Ths task (often called TxTask) executes at the greatest common dvsor of the message perods. Every tme t s actvated, t checks f some message perods are expred. If so, t assembles the messages contents and queues them, n the order of ther prorty. Therefore, a prorty nverson only occurs f the TxObject s not empty by the next actvaton of the TxTask. x6f8 x3a8 x3 the TxTask enqueues messages x6f8 s coped nto the TxObject x3 x3a8 x6f8 Fgure 2. the CAN network s used by other messages x3 x3 s delayed and experences prorty nverson Prorty nverson when the TxObject cannot be revoked. One example s shown n Fgure 2. In ths case, a lower prorty message (x6f8 n the fgure), enqueued by a prevous nstance of the TxTask, s stll watng for transmsson n the TxObject when the next nstance of TxTask arrves and enqueues hgher prorty messages (lke the second nstance of x3 n the fgure). Ths type of prorty nverson experenced by x3 clearly volates the rules on whch Equaton (2) s derved. Analyss on the worst case message response tme for ths case where transmsson requests are not aborted s provded n [5] and later n [8]. ) Evaluatng the cost of TxObject preempton: Even when transmsson aborton s allowed by the CAN controller, the developer may choose not to make use of t, to keep the drver desgn smple and save the addtonal overhead that would be requred for the message evcton and replacement. The ntuton s that the smaller overhead together wth the lkelhood that the blockng message s transmtted n a short tme, wll n most cases compensate for the possble ncrease n the worst-case message response tme. Ths choce s qute common n the automotve ndustry and ndeed experments show that t could be justfed by the average tmng performance of messages (as opposed to the worst-case). Consderng that true hard real-tme systems are ndeed rare, ths may be suffcent justfcaton. To evaluate the mpact of dsablng TxObject preempton on the tmng performance of messages, we perform experments where the drver overhead for evctng a message from a TxObject s estmated, based on measurements of queung operatons and regster access on a Freescale MPC5674F mcrocontroller runnng at 2MHz. Gven that the most common structure for the message queue s a smple lst, the tmng overhead s estmated as the tme to take back a message from the TxObject (wth the correspondng operatons on the controller regster) and nsert nto the software queue, whch can be expressed as (2+4n)μs, wheren s the number of messages already n the queue. probablty (cdf).8.6.4 Ideal behavor.2 Aborton wth measured overhead Aborton wth doubled overhead No aborton Worst case from [2] 2 3 4 5 6 7 8 response tme (Xus) Fgure 3. The response tme of a hgh prorty message wth nonpreemptable TxObjects. probablty (cdf).8.6.4 No aborton Ideal behavor.2 Aborton wth measured overhead Aborton wth doubled overhead Worst case from [2] 2 3 4 5 6 7 8 9 2 response tme (Xus) Fgure 4. The response tme of a medum prorty message wth nonpreemptable TxObjects. As an example, we present results on one of the CAN buses of an expermental vehcle, wth 69 messages sent from 6 nodes (the detals are avalable n [5]). We select three representatve messages: a hgh prorty one (second hghest on ts node) wth relatve prorty order of 4; a medum one wth prorty order of 4 (9th out of 8 on ts node); and a low prorty message wth order 63 (the lowest prorty on ts node). We use smulaton to evaluate the tmng performance for four cases: the deal behavor where the TxObject s preemptable wth neglgble tme, the case where the TxObject s preemptable but wth tmng over-
n queue... 2 queues... 3 queues....8 n... + j... + probablty (cdf).6.4 Fgure 6. n... j+ Parttonng of messages nto TxObjects/software queues..2 No aborton Ideal behavor Aborton wth measured overhead Aborton wth doubled overhead Worst case from [2] 2 4 6 8 2 4 6 8 2 response tme (Xus) Fgure 5. The response tme of a low prorty message wth nonpreemptable TxObjects. head, the case where the TxObject s non-preemptable, and, as an addtonal comparson, the case where the TxObject aborton overhead s doubled. Fgures 3 5 show the results for the representatve messages comparng the cumulatve dstrbuton functons (cdfs) for the four confguratons wth the values from worst case analyss [2]. The fgures show that the overhead of message transmsson aborton at the TxObject does not change much the average tmng performance, as demonstrated by the proxmty of the curves wth the deal behavor. Dsablng the preempton of the TxObject can cause sgnfcant addtonal delays for hgh prorty messages (Fgure 3), where the average response tme ncreases from 5μs to 742μs. However, qute nterestngly, for medum and low prorty messages (Fgures 4 and 5), the average tmng performance s actually better f transmsson aborton s dsabled, protectng these messages from further nterference. 2) Defnng the (software) message queues: To allevate the mpact on hgher prorty messages due to the lack of TxObject preempton, multple TxObjects (each of whch corresponds to a dedcated software queue) can be used. Ths soluton s used n the desgn of many automotve systems. In ths case, the desgner s job s to fnd the mnmum number of TxObjects (and software queues) that s requred to ensure all messages meet ther deadlnes and partton the outgong messages among the queues. Ths desgn synthess problem s stll open, and the complexty of the analyss ([5] [8]) suggests that a provably optmum algorthm s hard to fnd. We propose a smple heurstc soluton to the problem of parttonng the messages among queues whch performs extremely well. The soluton conssts n puttng messages wth contguous prorty levels to the same queue. We frst sort messages by prorty (dentfer). The hghest prorty TxObject and the correspondng queue should contan the hghest prorty messages, untl some ndex. The next queue the messages from prorty ndex + to j, and so on (Fgure 6). The requred number of queues and the breakup ponts can be found by exhaustvely explorng all possble optons wth complexty ( n ) = n (n s the number of messages to be queued) for a two-queue system (as opposte to 2 n for an exhaustve search), and ( ) n 2 = n(n ) 2 for a system wth three queues, and so on. The optmzaton goal s to maxmze the laxty of the node E, defned as the mnmum dfference between the deadlne and worst case response tme among ts messages: X = mn (D j R j ) N j=e We use the fve automotve CAN systems (one n Table I, another n [5]) to evaluate the effectveness of the heurstc algorthm. These fve bus systems contan a total of 59 CAN nodes, each sendng to 4 messages. The proposed heurstc can be evaluated by comparng wth the optmum computed from an exhaustve search (whch s feasble for nodes wth less than 2 messages and 3 queues). However, n case the exhaustve search s too tme consumng, the computed result can stll be demonstrated to be optmal f ts maxmum laxty s the same as the (optmal) case where each message s assumed to have a dedcated TxObject. In all our real automotve case studes the heurstc algorthm computes the optmal soluton. For all nodes n all the systems, two queues are suffcent to guarantee the schedulablty of the messages and acheve the maxmum laxty, wth only one excepton (node E 3 n [5], wth 8 outgong messages, where the schedulablty and maxmum laxty requre three queues). Interestngly, ths shows that n most cases, TxObject evcton could ndeed be compensated by usng only two queues. Ths also results n a smpler drver mplementaton, wth better performance for several messages n the average case and stll retanng a guaranteed worst-case performance. B. Pollng-based Output n CAN Drver Fgure 7 shows the basc functonng of a pollng-based output and ts mpact on message latency. A pollng task s executed wth a perod T p. When t executes, t checks the avalablty of the TxObjects. If one TxObject s free, then t extracts the (hghest prorty) message from the queue and copes nto the TxObject. Then t goes back to sleep. As a result, transmssons from a node are always separated by at least T p. If a message s enqueued wth n other messages n front of t n the queue, then t wll have to wat for at
Applcaton layer Mddleware layer Drver layer Controller layer CAN bus Fgure 7. Pollng task TxTask message queue TxObject Pollng task perod The Tx pollng task ntroduces delays between transmsson. least (n )T p before beng coped to the TxObject and consdered for bus arbtraton. The typcal result of a node wth pollng-based message output s shown on the left-hand sde of Fgure 8 for a gven medum prorty message (the detals of the message set can be found n [7]). The rght Y-axs of the fgure shows the cumulatve fracton of nstances that are transmtted wth the latency no larger than the value on the X-axs. Despte the medum prorty, there are nstances wth latences larger than 5ms. Ths s qute unusual, compared to the typcal shape of a latency dstrbuton for a message wth a smlar prorty but usng nterrupt-based message output polcy, as shown on the rght-hand sde of Fgure 8. Indeed, based on ts dentfer, the message should not be delayed by more than a few mllseconds, as the worst-case analyss [2] predcts a worst case latency of approxmately 8ms. However, the source node uses pollng-based message transmsson, and the perod of the pollng task s 2.5ms (as ndcated by the steps n the latency dstrbuton). The number of hgher prorty messages n front of t n the queue vares from to 7, whch s the cause of the correspondng large worst case latency and the substantal latency jtter. We provde an upper bound on the worst case message response tmes for pollng-based output under the assumpton that the perod T p of the pollng task s sgnfcantly larger than the message transmsson tmes. T p s typcally n the range of several mllseconds, and the worst case message transmsson tme s n the order of hundreds of mcroseconds. Followng the framework of the prevous Secton II, we analyze the worst case queung delay w (q) for the q-th nstance of message m. The length of the longest busy perod can be computed n a smlar way. Durng the queung delay w (q), a hgher prorty message m j hp() can provde a number of nterferences on m equal to w (q) n j = w (q) + J j + τ bt T j (6) can be consdered as the sum of three tems: w (q) = I () + I (2) + B (7) where I (): nterferences from hgher prorty messages on the same node, plus the prevous q nstances of m ; I (2): nterferences from hgher prorty messages on other nodes; B : blockng tme from lower prorty messages. Fndng the worst case scenaro that smultaneously consders the contrbutons from the above three tems s not an easy task, and very lkely an NP-hard problem. Instead, we fnd an upper bound for each of the tems separately. Each nstance of m j contrbutng to I () alone can delay the transmsson of the q-th nstance of message m by T p (nstead of C j as n the analyss summarzed n Secton II). Thus, I () s bounded from above by I () = (q + n j ) T p (8) j hp(),n j =N All the hgher prorty messages from other nodes contrbute to the nterference term by addng ther transmsson tme at each of ther n j actvatons. Thus, I (2) s I (2) = (n j C j ) (9) j hp(),n j N Suppose the maxmum transmsson tme of a lower prorty message n lp() s B max = max C k () k lp() Each tme m s delayed up to T p due to the nterference and blockng delay I (2) + B, an addtonal blockng tme can occur equal to the longest transmsson tme of any lower prorty message. It s possble that the transmsson of the messages contrbutng to I () may suffer blockng delays, but ths wll not further affect I () or B (as we assume T p s sgnfcantly larger than the message transmsson tmes). The number of actvatons of the pollng task at whch I (2) + B addtonal blockngs can happen s n b = +. T p Thus, the blockng tme s B = n b B max I (2) + B =( +) B max () The queung delay can be calculated usng an teratve procedure wth two nested loops, as n Algorthm. w (q) s teratvely computed by the outer loop (lnes 2 4). Frst, Equatons (6), (8), and (9) are used to compute the nterferences from hgher prorty messages usng the value w (q) from the prevous teraton. Then, n the nner loop (lnes 8 ), Equaton () teratvely computes the blockng tme B gven the nterferences from hgher prorty messages I () and I (2). The blockng tme B found after convergence s then used wth the other tems to update w (q). For the message on the left-hand sde of Fgure 8, the computed worst case response tme s 37.22ms. Such an T p
number of nstances 4 2 number of nstances cumulatve fracton 5.8 cumulatve fracton number of nstances number of nstances cumulatve fracton 4.8 rate depends on remote nterference cumulatve fracton 8 ~2.5 ms.6 3.6 6.4 2.4 4 2.2 mnmum latency from hgher prorty messages from the same node wth harmonc perod.2 2 4 6 8 2 4 6 8 2 22.5.5 2 2.5 3 message response tme (ms) message response tme (ms) Fgure 8. Latency dstrbuton for a message wth pollng-based output (left) compared to another message wth nterrupt-drven output (rght). Algorthm Calculatng the worst case queung delay w (q) : fnd an ntal value w (q)new (e.g. assumng j hp(), n j = ) 2: repeat 3: w (q)old = w (q)new 4: for j hp() do w (q)old + J j + τ bt 5: n j = T j 6: calculate I () and I (2) usng Equatons (8) (9) 7: B new = B old = B max // ntal value for B 8: repeat 9: B old = B new I(2) : B new + B old =( +) B max : untl B new 2: B = B new 3: w (q)new 4: untl w (q)new 5: w (q) T p = B old // converged value for B = I () + I (2) + B = w (q)old = w (q)new // converged value for w (q) exceedngly large (although pessmstc) bound s further evdence that pollng-based output management n a CAN drver s smply not the rght choce for real-tme systems. V. CONCLUSION Ths paper dscusses several ssues wth respect to the practcal relevance of the analyss of message latences n CAN networks. The possble causes of prorty nversons at dfferent levels n the communcaton stack are examned. A heurstc soluton s proposed for the problem of desgnng multple software queues when usng TxObjects wthout preempton, whch s demonstrated to be close to optmal n practcal systems desgn. We also derve an upper bound on the worst case response tme when message output at the CAN drver level s pollng based. REFERENCES [] Vector canbedded nteracton layer. http://www.vector.com. [2] R. Davs, A. Burns, R. Brl, and J. Lukken. Controller Area Network (CAN) schedulablty analyss: Refuted, revsted and revsed. Real- Tme Systems, 35(3):239 272, 27. [3] R.I. Davs, S. Kollmann, V. Pollex, F. Slomka, Schedulablty Analyss for Controller Area Network (CAN) wth FIFO Queues Prorty Queues and Gateways. In Real-Tme Systems, Volume 49, Issue, Pages 73-6, Jan 23. [4] R. Davs and N. Navet. Controller Area Network (CAN) Schedulablty Analyss for Messages wth Arbtrary Deadlnes n FIFO and Work- Conservng Queue. In Proc. 9th IEEE Internatonal Workshop on Factory Communcaton System, 22. [5] M. D Natale. Evaluatng message transmsson tmes n Controller Area Networks wthout buffer preempton. In 8th Brazlan Workshop on Real-Tme Systems, 26. [6] M. D Natale. What can go wrong n CAN (tmng analyss). In Socety of Automotve Engneers World Congress, 2. [7] M. D Natale, H. Zeng, P. Gusto, and A. Ghosal. Chapter 7, Understandng and Usng the Controller Area Network Communcaton Protocol. Sprnger, ISBN 978--464-33-5, Feburary 22. [8] D. Khan, R. Davs, and N. Navet. Schedulablty analyss of CAN wth non-abortable transmsson requests. In Proc. 6th IEEE Conference on Emergng Technologes & Factory Automaton, 2. [9] A. Mesch, M. D Natale, and M. Spur. Prorty nverson at the network adapter when schedulng messages wth earlest deadlne technques. In Proc. Euromcro Conference on Real-Tme Systems, 996. [] N. Navet, Y.-Q. Song, and F. Smonot. Worst-case deadlne falure probablty n real-tme applcatons dstrbuted over controller area network. Journal of Systems Archtecture, 46(7):67 67, 2. [] M. Park. Non-preemptve fxed prorty schedulng of hard real-tme perodc tasks. In Proc. 7th Internatonal Conference on Computatonal Scence, 27. [2] K. Tndell, H. Hansson, and A.J. Wellngs. Analysng real-tme communcatons: Controller Area Network (CAN). In Proc. 5th Real- Tme Systems Symposum, 994. [3] K. Tndell and A. Burns. Guaranteed Message Latences For Dstrbuted Safety-Crtcal Hard Real-Tme Control Networks. Techncal Report, Department of Computer Scence, Unversty of York, May 994. Techncal Report YCS229. [4] Wlfred Voss. A Comprehensble Gude to J939. Copperhll Technologes Corporaton, 28. [5] H. Zeng, M. D Natale, P. Gusto, and A. Sangovann-Vncentell. Usng Statstcal Methods to Compute the Probablty Dstrbuton of Message Response Tme n Controller Area Network. IEEE Transactons on Industral Informatcs, 6(4):678 69, 2.