EVALUATING WORST CASE RESPONSE TIME IN MONO AND ...

EVALUATING WORST CASE RESPONSE TIME IN MONO AND MULTI-MASTER PROFIBUS DP Salvatore Cavalieri (1), Salvatore Monforte (1), Eduardo Tovar(2), Francisco Vasques(3) (1)

Department of Computer Science and Telecommunications Engineering, Faculty of Engineering, University of Catania Viale A.Doria, 6 95125 Catania, Italy Tel.: +39 095 738 2362, Fax: +39 095 738 2397 e-mail: {salvatore.cavalieri, salvatore.monforte}@diit.unict.it

(2)

Department of Computer Engineering, ISEP, Polytechnic Institute of Porto Rua de São Tomé, 4200 Porto, Portugal Tel.: +351.2.8340500, Fax: +351.2.8321159 e-mail: [email protected] (3)

Department of Mechanical Engineering, FEUP, University of Porto Rua Dr.Roberto Frias, 4200-465 Porto, Portugal e-mail: [email protected]

Abstract Profibus networks are often used as the communication infrastructure for supporting distributed computer-controlled applications. Very often these applications impose strict real-time requirements. A widely used class of Profibus networks is the Profibus-DP profile, which may be implemented as mono or multi- master network. The aim of this paper is to analyse the real-time behaviour of both mono and multi- master Profibus-DP networks. The authors present a novel methodology for evaluating the worst-case message response time in systems where high-priority and cyclic low-priority Profibus traffic coexist. The proposal constitutes a powerful tool to guarantee, prior to runtime, the real-time behaviour of a distributed computer-controlled system based on a Profibus network. Keywords: Profibus-DP, Worst Case Response Time Evaluation, Real- Time Constraints.

1. Introduction A computer-controlled system is generally characterised by a centralised architecture, where the field devices (e.g., sensors and actuators) are connected to the computer system via point-topoint links. However, there are several advantages if a FieldBus is used as a replacement for the point-topoint links. A Fieldbus is a serial digital communication system used to interconnect process controllers, sensors and actuators, at the lower levels of the factory automation hierarchy [1]. The main advantage is an economical one. Naturally, the use of a single wire brings other important advantages, such as easier installation and maintenance, easier detection and localisation of cable faults, and easier expansion due to the modular nature of the network. The ability to support 1

distributed control algorithms is another advantage achievable by the use of FieldBus networks [1]. When distributed control algorithms exchange information across a FieldBus, there is the need to guarantee the real-time constraints of the exchanged messages. Within the context of this paper, we consider real-time constraints as the upper bound for message response time, i.e. the maximum allowable time span between a message transfer request and its transmission on the communication system. The use of a Fieldbus communication system introduces an increase in the total message delay with the respect of the traditional point-to-point communication systems. This increase results from multiple factors, such as the access and queuing delays and the protocol processing time. In particular the access and queuing delay factors depend on the Medium Access Control (MAC) mechanism used by the particular Fieldbus network. Different approaches for the MAC mechanism have been adopted by Fieldbus communication systems. As significant examples, we can mention the Timed Token protocol in Profibus [2], the centralised polling in FIP [3] and the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) in CAN [4]. This paper focuses on the evaluation of the messages' response time in Profibus-DP, which represents one of the most widely used FieldBus, and can be used both in mono and multi- master configurations. A new methodology for evaluating the worst-case message response time in systems where high-priority and cyclic low-priority Profibus traffic coexist will be presented. The proposed analysis constitutes a powerful tool to guarantee prior to runtime the real-time behaviour of a distributed computer-controlled system based on a Profibus network, where the real-time traffic is supported either by high-priority or by cyclic poll Profibus messages. The results presented in this paper can be considered as an important contribution to the state-ofthe-art in the real-time analysis of FieldBus traffic. In [5] a real-time analysis of Profibus messages has been presented. However, such analysis is some how inacurate, since it does not consider that Profibus message requests are queued in a FCFS (First-Come-First-Served) queue. In [6] and [7], an extended response time analysis was presented, enabling the evaluation of the worst-case response time for each individual message stream. However, this was intended for multi- master Profibus DP systems, and if applied to the mono- master system it leads to very pessimistic results, since the worst-case token rotation time is always considered. Moreover, the work presented in [7] has some limitations also for the analysis of the message response time in multi- master Profibus networks. First of all, the analysis is based on the assumption that each master station is able to transmit, in the worst-case, only one message per token visit. This assumption is correct but seems to be very pessimistic. Secondly, the other limitation is due to 2

the value of the real token rotation time, i.e. the effective time needed for the token to perform a complete cycle among all the nodes in the Profibus network. It was assumed that this value was always equal to the worst-case for every token cycle. Also in this case this assumption is correct, as it is relevant to a lower bound of the rotation time, but it seems a very pessimistic assumption and not much realistic. Finally, in the message model adopted in [7] some specific Profibus message streams are not considered, as will be pointed out in this paper. The proposal presented in this paper, which overcomes the above- mentioned limitations, is organised as follows. First, an ad- hoc analysis of mono- master Profibus-DP network will be proposed. Then, a novel worst-case response time analysis has been developed for the multimaster Profibus DP network, allowing to obtain less pessimistic results than those presented in [7], as will be shown in the paper.

2. A brief Overview of the Profibus-DP Protocol Profibus was recently considered as one of the Fieldbus solutions for the General-Purpose Fieldbus Communication System European Standard, the EN 50170 [2]. The Profibus protocol is based on a token passing procedure used by master stations to grant the bus access to each one of them [2][8]. The number of master stations may be one (mono- master Profibus-DP networks) or more than one (multi- master Profibus-DP networks). After receiving the token, the measurement of the token rotation time begins. This measurement expires at the next token arrival and results in the real token rotation time (TRR ). A target token rotation time (TT R) must be defined in a Profibus network. The value of this parameter is common to all masters. When a master station receives the token, the token holding time (TT H) timer is given the value corresponding to the difference, if positive, between TT R and TRR. An important Profibus concept is the message cycle. A message cycle consists of a master's action frame (request or send/request frame) and the associated responder's acknowledgement or response frame. User data may be transmitted in the action frame or in the response frame. Profibus defines two categories of message cycles: high priority and low priority. These two categories use two independent outgoing queues. If at the arrival, the token is delayed, that is, the real rotation time (T RR) was greater than the target rotation time (TT R), the master station may execute, at most, one high priority message cycle. Otherwise, the master station may execute high priority message cycles while TT H>0. TTH is always tested at the beginning of the message cycle execution. This means that once a message cycle is started it is always completed, including any required retries, even if TT H expires during 3

the execution. We denote this occurrence as a TT H overrun. The low priority message cycles are executed if there are no high priority messages pending, and while TT H>0 (also evaluated at the start of the message cycle execution, thus leading to a possible overrun of TT H). All the stations shall in general monitor all requests. The acknowledgement or response must arrive within a predefined time, the slot time, otherwise the initiator repeats the request. At the network set-up phase, the maximum number of retries, before a communication error report, must be defined in all master stations. The Profibus real-time analysis presented in this paper is based on the knowledge of the message cycle duration. This duration must include the time needed to transmit the action frame and receive the related response, and also the time needed to perform the allowed number of message retries.

3. Network and Message Models We consider a bus topology containing n master stations. It is clear that in the mono- master Profibus-DP network n is equal to 1. A special frame (the token) circulates around the logical ring formed by the masters. We denote the logical ring latency, i.e. the token walk time, including node latency delay, media propagation delay, etc. as λ. We assume that two types of message cycles can be performed: high priority and cyclic low priority, both modelled as periodic processes. Requests for message cycles are placed in high priority and cyclic low-priority outgoing queues. Let Shk i=(Chk i, Dhk i, Thk i) and Slk i=(Clk i, Dlk i, Tlk i) be high-priority and cyclic low-priority message streams in the generic master k (k=1,..., n), respectively. A message stream is a temporal sequence of requests for message cycles. Chk i and Clk i are the maximum message cycle durations for requests of message streams Shk i and Slk i, , respectively . These durations include the time needed to transmit the request frame and completely receive the related response, and also the time needed to perform the allowed number of message retries. Thk i and Tlk i are the periodicity of requests concerning message streams Shk i and Slk i, respectively. We assume that this periodicity is the minimum interval between two consecutive arrivals of the related requests to the outgoing queue. Dhk i and Dlk i are the relative deadlines of the related message cycles. They are defined as the maximum admissible time interval between the instant when the message request is placed in the outgoing queue and the instant when the related response is completely received at the master's 4

incoming queue. In the paper, it will be assumed that Dhk i= Thk i and Dlk i=Tlk i. Further, we assume that nhk and nlk are the number of high priority and cyclic low priority message streams, respectively. In the following analysis we will consider the maximum message cycle duration for a request of message stream Shk i for every message stream inside the master k (i=1,.., nhk and k=1,..., n). This value will be indicated as Chk max. Similarly, Clk max will indicate the maximum message cycle duration for a request of message stream Slk i for the generic master k and for every cyclic low priority message stream inside the master k (i=1,.., nlk and k=1,..., n).

4. Common Definitions for the Timing Analysis of Mono and Multi-Master Profibus-DP The following definitions hold for both the mono and multi- master analysis. Definition 1 – Overrun – We define an overrun as the occurrence of a TT H expiration while a message cycle is being processed. Definition 2 – Overrun Window – We define an overrun window as the time window during which TT H is exceeded due to the completion of a message cycle, added with the subsequent token passing interval. Definition 3 – Late Token – A token is defined as being late if, at its arrival, the real token rotation TRR is greater than the target token rotation time TT R. In [9], Liu and Layland introduced the concept of critical instant as being the time instant at which a request for a given task has the longest response time, that is, the longest time interval till the end of the response for that request. Moreover, a critical instant for any task occurs whenever the task is requested simultaneously with requests for all higher priority tasks. In a Profibus network, we must consider that, due to the FCFS behaviour of the outgoing queues, a given message request can be delayed by requests from all the other message streams (contrarily to the task scheduling case, where it would be delayed only by high priority message stream requests). Therefore, a critical instant will occur when, for a given priority (i.e. high- or lowpriority) every message stream simultaneously issues a message request. Moreover, due to the non pre-emptive context of message processing, high-priority requests may suffer some additional delay before starting being processed. Let us introduce the following definitions: Definition 4 – Profibus Critical Instant – Considering that requests for all high and low-priority message streams are simultaneously placed on the respective outgoing queues, we define a 5

Profibus critical instant as the time instant at which a request for a given message stream has the longest response time. Definition 5 – Initial Blocking – We define the initial blocking as the delay that the first request made at the critical instant may suffer until starting to be processed. Definition 6 – Critical Load – We define the critical load for a given priority class, as the time interval between a critical instant and the time instant when the last request (made at the critical instant) for that priority class has been completely processed.

5. Worst Case Response Time The aim of this section is to present the worst case message response time analysis for both the mono and multi- master Profibus DP network. The following two subsections will deal with these two systems, respectively.

5.1 Mono-Master Profibus-DP A late token arrival implies that at most one high-priority message can be processed by the master station. It should also be noted that an overrun in a given token arrival, does not usually imply a late token on the next arrival. Let us denote A(tc) as the token arrival instant for the tc th token visit. At the time instant A(tc), tc tc−1 TTH is assigned with the value TTR − TRR . Therefore, there will be a late token arrival only if tc −1 TRR > TTR . Note that the real token rotation time is measured between consecutive token

arrivals. As depicted in Figure 1, it is clear that the token is neither late in the tc th token visit nor in the

( tc + 1)th

tc visit, after the visit where an overrun has occurred (as TTR > TRR ). However, in some

particular conditions the token can be late. tc TRR tc TTH

tc −1 TRR

high / low -priority

TT R

overrun window

A(tc − 1) A(tc)

A(tc + 1) token latency

À TTH = 0

TTH expiration

À

Figure 1 – Overrun and late token 6

Theorem 1 – In a mono- master Profibus system, if in the tc th token visit an overrun occurs, then there will be a late token arrival if and only if the overrun window is greater than the value of tc −1 TRR .

Proof. Let us assume that in the tc th token visit an overrun occurs, and let ω be the overrun window. tc tc tc tc −1 As shown in Figure 1, TRR = TTH + ω . As TTH = TTR − TRR , then: tc tc −1 TRR = TTR − TRR +ω

(1)

tc We must prove that the token will be late at (tc + 1) th token arrival, that is, TRR > TTR if and tc −1 only if ω > TRR .

Since all quantities involved in expression (1) are positive, if

tc TRR > TTR

then

tc tc −1 tc tc −1 0 < TRR − TTR = −TRR + ω → TRR < ω ; vice-versa if ω > TRR then obviously follows tc TRR > TTR . Hence: tc tc −1 TRR > TTR ⇔ ω > TRR

(2)

That is, a late token arrives at the (tc + 1) th token visit if and only if the length of the overrun window is greater than the value of TRR computed at the beginning of the tc th cycle, that is, is tc −1 greater that TRR .o

Corollary 1 – A low-priority overrun induces a late token if and only if in the previous token visit no low-priority and at most one high-priority message has been processed. Proof. For

a

low-priority

overrun

the

length

of

the

longest

overrun

window

is

ω = Clmax + τ, where Clmax > Ch max . If in the previous token visit, no low-priority messages and at most one high-priority message were processed, at the token arrival TRR ≤ Chmax + τ , which is smaller than ω and thus a late token will be induced on next visit. o As far as the evaluation of the worst-case response time is concerned, two factors must be considered: the initial blocking and the high-priority critical load. The worst-case response time for both high-priority and low-priority messages stream (occurring after a critical instant) results from the simultaneous occurrence of: 7

1. the longest initial blocking, that is, the first high-priority request suffers the longest possible delay before being processed; 2. the longest high-priority critical load, that is, it takes the maximum number of token visits to process all high-priority requests. The following two theorems prove that the simultaneous occurrence of both conditions lead to the worst-case response time for the last message request to be processed. Theorem 2 – The longest initial blocking occurs when all requests are issued simultaneously with the occurrence of a low-priority overrun. Proof. Considering that the initial blocking depends on the position of the critical instant itself, the theorem is proved if a shifting of its position leads either to a deadline violation or to a smaller blocking. Referring to Figure 2, if the position of the critical instant is anticipated (shifted to the left), this leads to a deadline violation, since it means that requests were issued while the queue was not empty (either for low-priority or high-priority). Finally, if the critical instant is postponed (shifted to the right), this leads to a smaller blocking. o Master’s Critical Instant

Ch

Cl TTH = 0 high priority message

low priority messages

token latency τ

À Ch

high-priority queue not empty

Cl

low-priority queue not empty

Figure 2 – Master’s Critical Instant Corollary 2 – The longest initial blocking is B = Cl max + τ . Proof. Referring to Figure 2, it is clear that the longest low-priority overrun is Cl max + τ . o The length of the high-priority critical load interval depends not only on the occurrence of the maximum initial blocking, but also on the traffic processed on the previous token cycle. Theorem 3 – A Profibus critical instant occurs when the longest initial blocking is preceded by a token visit where no low-priority and at most one high-priority message is processed. Proof.

8

As depicted in Figure 3, a token arriving after a Profibus critical instant leads to a longer highpriority critical load, since the second high-priority request to be processed will suffer a delay of

τ . Taking into account that the maximum initial blocking is equal to the longest low-priority overrun window (Corollary 2); and considering also Corollary 1, after the critical instant a late token arrives if no low-priority message and at most one high-priority message is processed in the previous token visit. o Critical Load

Critical Load

Õ

Critical Instant

Critical Instant

Figure 3 – Late token and high-priority critical load

Corollary 3 – The maximum high-priority load interval leads to the worst-case response time for low-priority message streams. Proof. Considering that low-priority message cycles are performed in turn only after processing all the high-priority messages, its is clear that the maximum high-priority load interval leads to the longest time interval between the critical instant and the time instant at which the last lowpriority message is processed; and thus to the worst-case response time. o Since all the possible requests are issued at the critical instant, a master may need several token visits to process all high-priority requests, before processing any low-priority request. Thus, there will be a well-defined pattern when processing all those pending requests (Figure 4).

Critical Instant

1

nhπ

nhπ

1

1

nhπ

High-priority processing pattern

Figure 4 – The 1-nhπ processing pattern

This processing pattern is characterised by a late token arrival, where just one high-priority message is processed, followed by an early token arrival, where nhπ high-priority messages are processed. 9

Theorem 4 – The occurrence of a Profibus critical instant induces a (1- nhπ) processing pattern for high-priority messages. Proof. From the above analysis, it follows that the occurrence of a critical instant induces a late token arrival. Thus, as depicted in Figure 5, only one high-priority message will be processed (Œ) and, on next token visit, TTH will be assigned with a maximum values equal to (TTR − Ch max − τ ) .

TTR = Chmax + τ TTH = TTR − Chmax − τ

TTR

Ռ

• Ž

•

Õ

Profibus Critical Instant

TTH = 0

À

TTH = 0

ω = Cl max + τ high priority messages

low priority messages

À

À

TTH = 0

ω = Chmax + τ token latency τ

À

ω = Cl max + τ TTH expiration

Õ

late token

Figure 5 – Evaluation of the 1-nhπ high-priority processing pattern

Therefore, if the number of high-priority requests issued at the critical instant is greater than the number of high-priority messages which can be processed during TTH , then a high-priority overrun occurs, and, in the worst case, the length of the overrun window will be (Chmax + τ ) . Consequently, the token real rotation (TRR ) equals the target token rotation time (TTR ) (•), and on next token visit only one message cycle will be carried out (Ž). The (nh π − 1) processing pattern is then clearly defined, where (nh π − 1) messages are processed before the expiration of

TTH and the last of the nh π messages are processed in overrun. The maximum time spent processing this nh π messages is equal to (TTR − Ch max − τ ) for processing (nh π − 1) messages, plus (Ch max + τ ) to process the message in overrun, that is, is equal to TTR . It is also clear that if: •

the smallest token cycle always comprises one high-priority message cycle; and

10

•

in a token cycle where at least one low-priority message is processed, the token is never released before the expiration of the token holding time timer (TTH ) ;

then, in the last token cycle where there are still high-priority requests pending, the token holding timer is assigned with TTH = TTR − Ch max − τ (•), and this occurs after a token cycle which comprise no low-priority and exactly one high-priority message cycle (Œ,

Ž ).

Moreover if an

overrun of TTH occurs, then in the next token cycle no low-priority and at most one highpriority message can be processed (•). o The worst-case response time for high-priority messages can then be computed considering the following 4 components: 1. the initial blocking; 2. the time spent processing requests during the token visits where nhπ high-priority messages can be processed, plus the time spent to pass the token, that is, nh n hπ ⋅ TTR ; 3. the time spent processing requests in token visits where just 1 high-priority message can be processed, plus the time spent to pass the token, that is, nh nh π ⋅ ( Ch max + τ) ; 4. a component ψ h , which is related to the finishing of the (1 − nhπ ) processing pattern. We consider that at the end of the last complete cycle of nh π messages, there are three possible cases: a) there are no more pending requests, and thus the computation of the response time ends before releasing the token in the previous token cycle; b) there is just one pending request, and thus the time needed to process the pending requests is exactly Chmax ; c) there are more than one pending request, and thus one more token cycle is needed to process the pending requests Hence, the worst-case response time for Profibus high-priority messages is: R h = B + nh (nh π + 1) ⋅ (TTR + Ch max + τ) + ψ h

(3)

− τ, if nh = nh (nh π + 1) ⋅ (nh π + 1)  ψ h = Ch max , if nh = nh (nh π + 1) ⋅ ( nh π + 1) + 1 (nh − nh (nh π + 1) ⋅ (nh π + 1)) ⋅ Ch    max + τ, otherwise

(4)

nh π = (TTR − Ch max − τ) Ch max  + 1 = (TTR − τ ) Ch max 

(5)

where:

and:

11

5.2 Multi -Master Profibus-DP Concerning the analysis of the worst-case message response time for multi- master Profibus-DP networks, the conditions that lead to the maximum initial blocking must be re-analysed. In the following analysis, it is assumed that the critical instant for master k occurs immediately after releasing the token for its tcth token visit (or token cycle). For simplification of the analysis and without loss of generality it is possible to consider that the master k is the first one receiving the token at the tcth token visit. It should be noted that an increase of the initial blocking is expected only by the token holding periods of the masters following master k in the tcth token cycle and up to master k in the (tc+1)th one. Thus, let us introduce the following: Definition 7 – Relative Token Cycle – We define the tcth relative token cycle for the master k as the set of all the masters from master k (included) up to master n receiving the token in the tcth absolute token visit and all the masters, from the first one up to the master which precedes master k, receiving the token in the (tc+1)th absolute token visit. Moreover we denote with ki the ith master in a relative token cycle, where i=0,.., n-1, assuming that master k0 coincides with master k. Henceforth, unless explicitly specified, token cycles are to be considered relative to master k and master indexes are ordered starting from master k. Moreover, the following notation is used: • nhπ tck as the number of high-priority messages processed by master k in its tcth token cycle; • nlπ tck as the number of low-priority messages processed by master k in its tcth token cycle; • ∆htck as the value of the token holding time timer at token arrival to master k for its tcth token cycle; • ∆ltck as the value of the time interval given by the difference between the token holding time timer at token arrival to master k for its tcth token cycle and the number of high-priority messages processed at the tcth token cycle, i.e. ∆ltck = ∆htck - nhπ tck ⋅Chk max ; • H tck as the value of the token holding period at master k, which can be greater than ∆htck , if an overrun occurs.

{

• Cl max = max Cl kmax 1≤ k≤ n

} the maximum low priority message cycle to be processed in the

system. For this analysis we consider the following theorem. Theorem 5 – In a multi- master Profibus system, the maximum initial blocking will occur as a result from the simultaneous occurrence of the following conditions: 12

• each master ki (i=1,..,n-1) does not use the token for processing message cycles in the (tc-1)th relative token cycle and the master k does not use the token for processing message cycles in n −1

th

the tc token cycle. That is

∑ H ktci−1 = 0 ∧ H ktc = 0 ; i =1

• a critical instant occurs just after releasing the token for every master ki (i=1,.., n-1) in the (tc1)th token cycle and for master k in the tcth token cycle.

Proof. Let us assume that no message streams are to be processed by all the masters ki following master k (i.e. i=1,..,n-1), when each of them releases the token in the (tc-1)th token cycle. This condition is depicted in Figure 6, in which it is assumed that master k is master 2 (i.e. k0 =2), k1 =3, k2 =4 and k3 =1. The figure highlights the (tc-1)th relative token cycle. The same figure allows to better understand the maximum value that the initial blocking can have. In fact,, a critical instant occurs for every master ki (i=1, 2 and 3) just after releasing the token in the (tc-1)th token cycle and for master 2 in the tcth token cycle. In this token cycle, on the receipt of the token, master 3 uses the token until it expires. Assuming that the expiration of TT H occurs an instant after the master has started to transmit the longest message stream, it performs this last transmission before releasing the token. In the worst case, the time needed to complete this last transmission is k

{

k

}

1 1 , Cl C max = max Ch max max , i.e. the maximum message cycle length which should be processed

by the master k1 . tc th

relative token cycle

(tc − 1) th relative token cycle

Master 1

¤ st

Master 2

¤

Processing 1 Request

TTR

Master 3

¤ TT H = 0

À

¤

Master 4 high priority message

T TR − λ

token latency λ/n

¤

critical instant

13

initial blocking

À

TTH expiration

Figure 6 - Conditions leading to the maximum initial blocking. The other masters (number 4 and 1) receiving the token in the tcth token cycle are allowed to 2 3 transmit only one high-priority message stream with durations of Ch kmax and Ch kmax , respectively.

When the tcth token cycle is concluded, master 2 receives the token and can transmit the highpriority message streams. It is clear that if no message stream is to be processed by all the masters following master

k

this

leads to the lowest possible initial blocking for the master k, Bk : λ ≤ Bk

(6)

Concerning the upper bound, one should consider the overruns due to processing of the longest message streams. Taking into account the conditions leading to the maximum initial blocking, it is clear that at most only one overrun (TT H expiration) may take place before master k processes its first request. In particular, the worst case initial blocking occurs when master k1 overruns due to the maximum messages cycle. Therefore, the maximum initial blocking in a Profibus multimaster system can be bounded as:

λ ≤ B ≤ TTR − λ k

1 + C kmax

+

n−1

i ∑ Ch kmax

(7)

i= 2

An expression for the maximum blocking that the first request issued at the critical instant in master k may suffer, can be expressed as:

Bk = λ +

i + nl π ktci ⋅ Clmax ) ∑ (nh π ktci ⋅ Ch kmax

n −1

(8)

i =1

where: kj kj   kj  kj  nh π tc = min  nh , ∆h tc / Ch max + 1      

(9)

represents the number of high-priority messages which can be processed by master ki at its tcth token visit and k nl π tci

0 if ∆l k i < 0 tc  = ki ki ki ki min nl , ∆l tc / Cl max + 1 if ∆l tc ≥ 0 

( 

 )

(10)

represents the number of low-priority messages which can be processed by master ki at its tcth token visit.

14

We have to prove that under the hypotheses of the theorem, equation (8) gives the maximum allowed value for the initial blocking. Let us assume that exists B k >Bk . Therefore, at least for a k

k

k

k

given j (j=1,..,n-1), it follows that nh π tcj > nh π tcj or nl π tcj > nl π tcj . k

k

k

Let assume that nh π tcj > nh π tcj occurs. As said before, nhπ tcj represents the number of highpriority message streams processed in master kj within its tcth token cycle. That is, the minimum between the number of requests issued at the critical instant which have not been processed yet and the number of requests that can be processed having received a given token holding time k

k

k

( ∆h tcj ) including the overrunning one, if any. Hence, if nh π tcj > nh π tcj this would mean that message streams have been either received while all nh

kj

requests were queued yielding a

deadline violation, or processed after the completion of the overrunning one, yielding a protocol violation. k

k

In the same way it is possible to demonstrate that nl π tcj > nl π tcj cannot occur. q Concerning the response time of a given message stream, two main components can be identified: the initial blocking and the critical load. It is clear that the worst-case response time occurs if both components assume their maximum value i.e. the worst-case delay the first request issued at the critical instant may suffer (maximum initial blocking) and the longest span of time between the critical instant and the instant at which the last request is processed (maximum critical load). Theorem 5 introduces the hypotheses under which, in a multi- master Profibus network, the maximum initial blocking occurs. It should be noted that the occurrence of such an event does not necessarily lead to the maximum critical- load, and thus to the worst-case response time. It is possible to verify that if the following conditions occur: nh k1

∑ Ch ki1 + nl k1 ⋅ Clmax > TTR − λ i=1

nh k i

∑

j =1

k

Ch j j + nl k i ⋅ Clmax >TTR −

n −1

j i − λ + i ⋅ Ch kmax ∑ Ch max

k

(11) (12)

j =0

where 1