Abstract:
A method for predicting the worst case response time for a frame in a frame queuing system, where frames are grouped together in transactions. In order to achieve an analysis that better models the transactions present in the serial bus network, the transaction concept has been redefined compared to prior art, resulting in a different approach when implementing the analysis. According to the invention, the transaction period is longer than the frame periods comprised therein, and is defined as the LCM of the frame periods. As a result, several instances of a frame of a given priority may occur in one transaction, which alters the process of estimating response time. The queuing system can for example be the serial bus of a serial bus network, and the analysis can then be adapted to handle transmit queue budgets.

Description:
FIELD OF TECHNOLOGY  
       [0001]     The present invention relates to a method for predicting the worst case response time for a fixed priority frame in a frame queuing system in a serial bus network, such as a CAN.  
       BACKGROUND  
       [0002]     In many applications, serial bus networks are used for communication between digital devices; one example is a CAN network in a vehicle. Further, the communication between these devices is typically associated with specific timing requirements, stating a maximum delay from the time a certain event takes place to the time when a corresponding function is performed. For example, it is normally appreciated if the automatic breaking system (ABS) responds quickly to a sensor signal even when the network is occupied with several other tasks (like engine control, transmission control, etc).  
         [0003]     Such timing requirements translate into a maximum response time for frames, i.e. a maximum time period between arrival of a frame transmission request and completed transmission of the same frame.  
         [0004]     Consequently, when designing such a network, it is critical to be able to guarantee transmission of messages (frames) within the timing requirements. In order to enable such guarantees, the network is modulated in a software design tool, and maximum response times are predicted. If the network is deemed to be too slow under present circumstances, it will have to be redesigned, or, if possible, the band width of the network bus can be improved.  
         [0005]     The mechanism assigning priorities and handling the distribution of frames on a serial bus is referred to as scheduling, and resembles the process of scheduling tasks in e.g. a centralized computer processing system. The design tools mentioned above are based on response time analysis, in short a way to mathematically determine the delay between a request (e.g. for sending a frame on a serial bus) is made and when it is treated.  
         [0006]     An algorithm where the task or frame currently being processed can be interrupted by a new request is referred to as a preemptive scheduling algorithm. An algorithm where the current task or frame is completed before a new request is treated is called non-preemptive.  
         [0007]     An example of scheduling analysis for preemptive scheduling is given in the article “Finding response times in a real time system” by M. Joseph and P. Pandya, BCS Computer Journal, vol. 29, no. 5, pp. 390-395, Oct. 1986. The analysis was based on the assumptions that the worst case response time for tasks occurs when all types of requests enter the scheduling process simultaneously.  
         [0008]     Often, however, a given set of requests will have offset constraints, i.e. different types, of requests will be constrained to execute at fixed offsets in relation to each other. Therefore, the assumption of simultaneous requests results in a pessimistic prediction.  
         [0009]     The article “Adding time-offsets to schedulability analysis” by Ken Tindell, published as Report YCS 221, Department of Computer Science, University of York, 1994, presents a scheduling analysis for tasks in a processor allowing for such offsets. Here, tasks which have interrelated time dependencies are grouped together in so called transactions.  
         [0010]     While this approach improves the accuracy of the predictions and reduces the pessimism, each task is restricted to have a period that is an integer multiple of the corresponding transaction period. However, when considering frames on a serial bus, frame periods can only be guaranteed to be a multiple of the frame processing period. As the offset of a task is restricted to be shorter than the transaction period, this places severe restrictions on the applicability of the method.  
         [0011]     Therefore, despite the prior art put forward above, known scheduling analysis models still fail to provide accurate predictions of frame response times on serial bus in a digital network.  
         [0012]     As a consequence, the available computer models of a serial bus network, such as a CAN network, are in general too pessimistic. This overly pessimistic approximation leads to unnecessary redesign, or even implementation of unnecessary band width.  
         [0013]     Further, the nodes in a serial bus network may be restricted to only enter a given number of frames into the arbitration process. Such restrictions, normally referred to as node budgets, are imposed in order to allow the node processor to handle other tasks apart from scheduling and transmitting frames. These budgets are not considered in conventional scheduling analysis.  
       SUMMARY OF THE INVENTION  
       [0014]     An object of the present invention is therefore to provide a more correct way to estimate delivery times of frames on a serial bus network, and to overcome at least some of the shortcomings of prior art methods.  
         [0015]     This and other objects are achieved by a method of the kind mentioned by way of introduction, comprising the steps of: defining the period of the transaction as the least common multiplier (LCM) of the frame periods of the included frames; identifying a set of starting points, representing the latest possible release times for all frames in the transaction having higher or equal priority as said frame; for each starting point (s), determining a maximum duration of a sequence of frames having a higher priority as said frame that can occur starting at this starting point, identifying the next frame instance having a latest possible release time equal to or greater than this starting point, and calculating the difference between the end of said sequence and the arrival time of said frame instance, and selecting the longest of said differences for determining the frame response time.  
         [0016]     In order to achieve an analysis that better models the transactions present in the serial bus network, the transaction concept has been redefined compared to prior art, resulting in a different approach when implementing the analysis. According to the invention, the transaction period is longer than the frame periods comprised therein, and is defined as the LCM of the frame periods. As a result, several instances of a frame of a given priority may occur in one transaction, which alters the process of estimating response time.  
         [0017]     While conventional estimations are based on one specific instance of a frame, the method according to the invention considers all instances in the transaction.  
         [0018]     By adjusting the prior art response time analysis schemes to the conditions of a serial bus network, the method according to the invention provides a more accurate prediction of frame response times in different stages of the processing, enabling a more efficient utilization of the network.  
         [0019]     The queuing system can for example be the serial bus of a serial bus network, or a transmit or receive queue connected to this bus. In a complete system response time analysis, several different contributions to the application-to-application response time will have to be considered.  
         [0020]     The step of determining the frame response time can include calculating a sum of the longest of said differences and a frame transmission time.  
         [0021]     According to one embodiment, the set of starting points is divided into subsets, each being associated with one frame instance, and said difference is then calculated for the starting points in one such subset at a time. This leads to a somewhat different implementation, but the end result remains unchanged.  
         [0022]     The step of calculating said maximum duration can be performed by setting a current duration to an initial value and iterating the following steps until the duration converges: determining a maximum contribution from each transaction by identifying a set of time lags between a given transaction and said starting point, determining the contribution from this particular transaction with this particular time lag, and selecting the largest contribution; determining an updated duration including a sum of all such maximum contributions; and replacing the current duration with the updated duration.  
         [0023]     This provides an efficient numerical solution to the very difficult analytical problem of finding the longest busy period starting in a given point.  
         [0024]     The initial value is preferably set to the longest possible transmission time of a frame with lower priority than said frame. This represents the longest possible delay that can be caused by a lower priority frame released before the frame of interest. This delay is due to the non-preemptive character of the system. Further, this delay can be included as a constant term in each updated duration, in order to make the estimation more accurate.  
         [0025]     According to a preferred embodiment, an error term is also included as a term in each updated duration. The error term can represents the probable duration of transmission errors on the serial bus, and is typically dependent on the current busy period duration. Accordingly, the error term is recalculated for each iteration.  
         [0026]     According to one embodiment, relating to determining the response time on a serial bus where each transmit queue is arranged to transmit a limited number of frames onto said serial bus during a given period of time, frames originating from the same transmit queue being referred to as a batch, and the step of determining a maximum contribution is performed for one batch at a time, and further comprising: determining the transmission time of the maximum number of frames the corresponding transmit queue may transmit during the current duration, and limiting said maximum contribution (I(T)) to said transmission time.  
         [0027]     This embodiment modifies the method according to the invention to handle budgets, which is an important feature of e.g. some CAN systems. 
     
    
     DETAILED DESCRIPTION  
       [0028]     In the following description, a frame refers to a class of frames having the same fixed priority. An individual frame in the queuing system is instead referred to as a frame instance.  
         [0029]     The arrival time is the point in time when a frame instance is notionally created, and the release time is the point in time when this frame instance actually enters the arbitration process of the queuing system. In a perfect system, these times would coincide, but in practice there is a delay, referred to as release jitter. The latest possible release time of an instance is the arrival time plus the maximum possible jitter.  
         [0030]     Frame instances are expected to arrive periodically, and the expected period between such arrivals is called the frame period. Sporadic frames, i.e. frames not having a periodic behavior, are treated as having a period equal to the shortest time between two sporadic arrivals.  
         [0031]     From the release time, a transmission time will be required to complete the transmission of the frame, and this will be dependent on the amount of data placed in the body of the frame. In a non-preemptive system, like a CAN, a frame may not be interrupted when transmission has started.  
         [0032]     Several frames that share a common time relationship are grouped together in a transaction, where each frame is related to the start of the transaction with an offset. The transaction is periodic with a transaction period, and each transaction occurrence is referred to as a transaction invocation. Note that it is not necessary that all frames having a common time relationship are grouped in the same transaction. In fact, according to preferred embodiments of the invention, it may be advantageous to let the frame of interest per definition be the frame with lowest priority in its transaction. This can be accomplished by grouping frames with lower priority in a separate transaction.  
         [0033]     A sporadic frame cannot have a time relationship with other frames, and thus forms a transaction by itself. Such a sporadic transaction is treated as having a period equal to the shortest time between two sporadic arrivals.  
         [0034]     Before a released frame instance with priority i will be transmitted by the queuing system, the transmission of any frame with a higher priority j&lt;i must be completed (N.B. that a higher priority is denoted with a lower index). The period of time during which the bus is occupied with such frames is referred to as the level i- 1  busy period. The delay between the arrival of the frame instance and the completed transmission of the instance is referred to as the response time.  
         [0035]      FIG. 1  shows an example of a network  1  in which the present invention is applicable. The network  1  comprises a plurality-of nodes  2 , connected by a serial bus  3  carrying information contained in frames  4 . One example of such a network is a CAN, Controller Area Network which is a simple communications standard that has gained widespread use in automotive and control applications. The CAN standard is described in detail in “CAN specification version 2.0”, Robert Bosch GmbH, Stuttgart, 1991.  
         [0036]     Each node  2  has a node controller  5 , and a transmit queue  6  and a receive queue  7 . Frames that are ready for transmission are inserted into the transmit queue they are allocated to, and the transmit queues are ordered by frame priorities. The node controller places frames that are waiting in the transmit queue on the serial bus by calling a frame processing routine. In order to guarantee a limited duration of such a call, every transmit queue can have a budget, i.e. a maximum number of frames instances that can be included in a frame processing call. The period between frame processing calls is referred to as a frame processing period.  
         [0037]     A call to the frame processing routine is made periodically, and each time the number of frames allowed by the transmit queue budget (in priority order) are taken out of the queue and copied to the controller for transmission. In some serial bus systems, e.g. the CAN implemented by Volcano Communication Technology AB, multiple queues can be allocated to a single node controller, but a frame can only be allocated to one transmit queue.  
         [0038]     The situation is similar on the side of a receiving node. Frames received by the receiving controller are inserted into a local receive queue, and a call to a frame processing routine is made periodically. Each time, the number of frames allowed by the receive queue budget are taken out of the receive queue and processed.  
         [0039]     The nodes in the CAN system and similar types of serial bus networks are not synchronized, which means that predefined time relationships between different frames (offsets, see above) only can exist between frames originating from the same node, and, if a node has several transmit queues, from the same transmit queue. Therefore, the frames in a transaction all originate from the same transmit queue. The collection of all transactions from a transmit queue is referred to as a batch. Consequently, a particular budget is always related to one particular batch.  
         [0040]     CAN uses an arbitration protocol to resolve contention on the bus when more than one frame is ready for transmission. The arbitration protocol works in the following way: Each frame  4  starts with a unique arbitration field of 11 or 29 bits. If a CAN controller transmits a zero, the bus will reflect a zero regardless of what the other controllers have transmitted. If a CAN controller transmits a one, the bus will reflect a one only if no other controller transmitted a zero.  
         [0041]     When the arbitration protocol starts, a controller begins to transmit the arbitration field of the highest priority frame queued in the controller starting with the most significant bit. For each bit that is transmitted the controller waits for the signals to propagate along the bus and then reads the value of the bus. If the controller transmitted a one but receives a zero this indicates that another controller is transmitting a frame with a lower value encoded into the arbitration field and therefore the controller drops out of contention and stops transmitting. After the last bit of the arbitration field has been transmitted only one controller may still be transmitting since the arbitration field is unique. In this way the value of the arbitration field is equal to a priority where a lower value means higher priority.  
         [0042]     Middleware provided by Volcano Communication Technology AB provides an interface to the application programmer which is completely signal-based and guarantees that when a signal is written the new value will be distributed throughout the system within a certain guaranteed amount of time.  
         [0043]     With an off-line software module called the Volcano Network Architect (VNA) the system designer is able to define the signals that build up the functionality and specify the timing constraints on those signals. Another module, referred to as a frame compiler, is adapted to compile a network configuration based on the timing requirements of different signals. The process involves packing the signals into frames and assigning parameters such as periods, priority and offset. A response time analysis is carried out in the process in order to verify that the configuration satisfies the constraints specified.  
         [0044]     In addition to the response time caused by the CAN bus itself, the end-to-end response time (i.e. application to application) thus contains two additional parts, corresponding to the time a frame can spend waiting in the transmit and receive queues.  FIG. 2  illustrates the process. First, the data (a signal originating from an application) is sent, i.e. placed in a frame intended to be transmitted on the serial bus. The frame is placed in the transmit queue, and after a certain time D 1 , the frame is included in a frame processing call and enters the bus scheduling process (arbitration). The time D 2  it takes for the frame to be transmitted on the bus is the response time described above. The frame then spends a certain time D 3  in the receive queue before being included in a frame processing call that finally communicates the data to the receiving application.  
         [0045]     A flow chart of a part of the process performed by the frame compiler is shown in  FIG. 3 . First, in step S 51 , periods and offsets are determined based on the currently available data. Then, in three consecutive steps (S 52 -S 54 ), transmit queue delays, bus response times, and receive queue delays are calculated respectively. In step S 55 , the results are analyzed, and it is determined if the results can be improved by a further iteration. Depending on this determination, program control is returned to step S 51 , or the process is terminated. In practical implementations, it may be advantageous to perform the calculations in steps S 52 -S 54  for different subsets of frames, each such subset being relevant in a particular mode of operation.  
         [0046]     Although the following description will be focused on the response time of the serial bus, all three delays D 1 , D 2 , D 3  in  FIG. 2  can be determined according to essentially the same method, where the response time of one part is the jitter of the following. Note, however, that the effect of budgets mentioned above only needs to be considered when determining the bus response time, D 2 .  
         [0047]      FIG. 4  shows three frames F i , F j , F g  with priorities i&gt;j&gt;g, and periods p i , p j , p g . Frames F j  and F g  have offsets O j  and O g  compared to the beginning of the transaction, which in this case coincides with the arrival of frame F i . According to the invention, a transaction T comprising these frames is defined to have a period equal to the least common multiplier of the three frame periods, P T =LCM(p i , p j , p g ), so that each transaction invocation will be identical. Each instance k of a frame F i,k  is illustrated by two joined arrows, a first arrow indicating the arrival time of the instance, a i,k , and a second indicating the latest possible release time, r i,k . The time between the arrows is the jitter, J i .  
         [0048]     In order to determine the response time R i,k  of instance k of a frame with priority i, a level i- 1  busy period (w) must be determined for this instance. The response time is then given by:
 
 R   i,k   =β   i-1,k   +W−a   i,k   +C   i   =D   i,k   +C   i    Eq. 1 
 
         [0049]     where β i-1, k  is the start of the level i- 1  busy period w related to instance k, a i,k  is the arrival time of the frame, and C i  is the transmission time of the frame. This is illustrated in  FIG. 5 .  
         [0050]     The process of determining the worst case response time according to equation 1 will be described with reference to  FIGS. 6-8 .  
         [0051]     First, a set of candidate starting points is determined in step S 2  ( FIG. 6 ). It can be shown that the worst case level i- 1  busy period must start on one of the latest possible release times of one of the frames instances with priority j≦i (higher or equal priority). In the transaction shown in  FIG. 4 , these candidate starting points are denoted r i,1 - r i,4 , r j,1 -r j,3  and r g,1 -r g,6 .  
         [0052]     For each of these starting points, s, the length of the corresponding maximum level i- 1  busy period w is determined (step S 3 ), and the frame instance k having a latest possible release time r i,k  on or after the corresponding starting point s (r i,k ≧s) is identified (step S 4 ). In  FIG. 4 , the points r i, 2 , r j,1 , r g,1  and r g,2  are associated with instance  2 , r i,3 , r j,2  and r g,3  are associated with instance  3 , r i,4 , r g,4  and r g,5  with instance  4 , and r i,1 , r j,3  and r g,6  with instance  1 .  
         [0053]     In principle, r j,3  and r g,6  are associated with instance  1  of the next invocation of the transaction, but due to the definition of the transaction period made above, the association between starting points and instances is allowed to “wrap around” the same transaction. As equation 1 assumes that the busy period starts before the latest release of the frame instance, the skilled person realizes that in this case, the correct start of the busy period β i-1,k  is in fact the point r j,3  or r g,6  subtracted by the transaction period P T .  
         [0054]     The difference D i,k  between s+w and a i,k , which is the first term of equation 1, is calculated in step S 5 , and the steps S 3  to S 5  are repeated for all starting points (step S 6 ). In step S 7 , the worst case response time, R i , is then found by selecting the largest of the calculated differences and adding the frame transmission time, according to:
 
 R   i =max( D   i,k )+ C   i .
 
         [0055]     An alternative, but entirely equivalent, approach is shown in  FIG. 7 , where the steps S 11  to S 16  replace the steps S 2  to S 6  in  FIG. 6 . Here, the frame instances of the transaction are determined first (step S 11 ), and then a set of candidate starting points associated with this instance is determined (step S 12 ). This set is of course a subset to the complete set in step S 2 . The steps S 13  to S 15  correspond to the steps S 3 , S 5  and S 6 , the step S 4  being unnecessary as the instance is known. Then, in step S 16 , the steps S 12  to S 15  must be repeated for each instance.  
         [0056]     The step of determining the duration of the maximum busy period (S 3  and S 13 ) will be described more in detail with reference to  FIG. 8 . The routine described here will be called upon with input variables i (priority of the frame) and s (starting point of interest).  
         [0057]     First, in step S 21 , an initial value for the duration w is chosen. This value corresponds to the blocking factor B during which the bus may be blocked by a lower priority frame, and is equal to the longest transmission time for a frame with priority j&gt;i. Note that this blocking factor may result also from a non-real-time frame (which is not part of the analysis), and thus should be set to the longest possible transmission time for the serial bus. On a typical CAN bus, this is the transmission time of an eight byte frame.  
         [0058]     Then a set of candidate time lags between a particular transaction T and the busy period starting point s is identified in step S 22 . Similar to the situation with starting points above, it can be shown that the transaction will have the greatest impact on the busy period if the starting point s occurs on the latest possible release time of a frame with priority j&lt;i in the transaction.  
         [0059]     Then, in step S 23  to S 26 , a contribution i (T) from this particular transaction to the duration of the busy period w is determined for each candidate time lag. First (step S 23  and S 24 ) it is determined how many frames with priority j&lt;i belonging to the transaction T that can be released within the busy period of duration w. Note that it is possible that several invocations of the transaction may occur within the busy period.  
         [0060]     In step S 25 , all released frames (priority j&lt;i) are summated, to generate the contribution i (T), and the process is repeated for all time lags in the set (step S 26 ). The maximum possible contribution from a transaction, I(T), is selected in step S 27 , and the steps S 22  to S 27  are repeated for all transactions (step S 28 ).  
         [0061]     Note that the steps S 22  to S 28  are performed also for the transaction to which the frame of interest belongs. In this particular case, however, there is only one possible time lag (the starting point s is fixed in the transaction), and the steps S 23  and S 25  are only repeated once.  
         [0062]     In step S 29 , a new value for the duration, wn, is determined as wn=B+ΣI (T), and the new duration wn is compared to the current duration w in step S 30 . If they are equal, the process is ended in step S 32 , and program control returns to step S 4  or S 14 . If not, w is replaced by wn, and the steps S 22  to S 30  are repeated (step S 31 ). The steps S 30  to S 32  correspond to an iteration of the process until the duration w converges.  
         [0063]     When comparing wn and w, differences smaller than the time required to transmit one bit on the serial bus, T BIT , will not considered. In fact, the method is advantageously implemented using only integer numbers (instead of float numbers), where each integer step represents T BIT .  
         [0064]     In order to handle the influence of transmission errors in the estimation, wn can include a third term, E(w+C i ), which represents the time required for all types of errors on the bus during the time period w+C i . The skilled person will be familiar with different ways to estimate E.  
         [0065]     In the process described above, each iteration is based on the current value, w. Alternatively, the determination in step S 23  can be based on the new duration, wn, which is updated for each transaction. Such an update can include calculating wn=wn+I(T), just after step S 27  where the contribution I(T) from a particular transaction has been determined. At the same time, the previously iterated contribution from this transaction must be deducted from wn, and this can be done by calculating wn=wn−I(T), just before step S 27  where I(T) is updated.  
         [0066]     The above variation requires some further initializations in step S 21 , namely that the new duration value, wn, is set to B and that the set of maximum contributions I are set to zero.  
         [0067]     As a further improvement, the busy period duration used in step S 23  can be compensated for the contribution from the transaction currently being investigated. However, note that simply subtracting the contribution I(T) calculated in the previous iteration will risk resulting in a too optimistic busy period. Instead, a more elaborate compensation must be performed.  
         [0068]      FIG. 9  illustrates a sequence that can replace the steps S 28  and S 29  of the process in  FIG. 8 , in order to handle the effect of budgets and thereby further shorten the worst case response time.  
         [0069]     Step, S 41 , replacing step S 28  in  FIG. 8 , repeats step S 22  to S 26  for all transactions in a batch. Then, in step S 42 , a limitation on the total contribution from this batch (I B ) is determined in the following way. First, the maximum number of frames, n B , that can be transmitted during the current busy period duration, w, is determined as  
         n   B     =       b   B     ×         J   B     +   w       fp   B             
 
         [0070]     where b B  is the number of frames in the node budget, fp B  is the frame processing period of the node, and J B  is the possible delay of a frame processing call. Note that n B  is rounded up to the closest integer value.  
         [0071]     As the frame processing period fp B  is defined as the time between two consecutive frame processing calls, the time between actual release of frames (i.e. completion of these calls) may be shorter, if the first call is delayed more than the next. Therefore, the maximum possible delay, J B , must be added to the current duration in order not to result a too optimistic limitation.  
         [0072]     The limitation, limit B (w), is then calculated as the maximum transmission time of n B  frames. In order to facilitate this calculation, the transmission time of each transmitted frame can be approximated with the maximum transmission time of any frame in the batch with priority j&lt;i, but more elaborate calculations can be envisaged.  
         [0073]     In step S 43 , the batch contribution, I B , is determined as I B =min(I(T), limit B (w)), and the process starting in step S 22  is repeated for all batches (step S 44 ). Step S 45  replaces step S 29  in  FIG. 8 , calculating the new value, wn, as wn=B+ΣI B . Again, wn can include a third term, E(w+C i ). Program control then continues to step S 30  in  FIG. 8 .  
         [0074]     It is clear that the skilled person can make numerous modifications to the above described preferred embodiments without departing from the invention as defined by the claims. For example, as mentioned above, the method can easily be adapted to e.g. transmit queues and receive queues in a CAN, in order to provide a complete response time analysis. Although the effect of budgets is not present in these cases, a similar restriction due to the transmission rate will be present in the receive queues.  
         [0075]     Naturally, the method is applicable to other types of serial bus networks as well, with only minor adjustments.