ABBIndustrial Networks Connecting Controllers via OPC

one direction (due to the limitation of two PROFIBUS slaves with Beckhoff’s

solution). Test 0 is carried out with only one integer value going forth and

back. Test 2 contains twice and Test 3 about three times the quantity of

variables as in Test 1, allowing to observe linear tendencies.

• Test 4 represents the real requirements for the quantity of variables and data

types according to Table 1.1. Thus, the results of Test 4 are the most important ones for statements regarding the feasibility of the setup. In contrary

to Tests 1 to 3, the amount of floating point values transmitted from AC160

to AC800M is much higher. As a consequence, it cannot be performed with

Beckhoff’s PROFIBUS solution.

• Test 5 is the duplication of Test 4, trying to determine the limits of the system.

4.4 Measurements

The following methods were used to evaluate our test system.

4.4.1 Round-Trip Time

The most relevant evaluation we performed is the round trip time (RTT) measurement. For this reason, a boolean value (packed in an integer) is set true and

sent from the AC800M controller to the AC160. At the same time, a stopwatch is

started. Inside the AC160 the value is moved to another boolean and sent back.

As soon as this value returns to AC800M, the stopwatch is stopped and the RTT

displayed via generated event that allows subsequent interpretation for 500 entries.

This number is the minimum sample quantity for our results discussed in the next

chapter. The actual communication slowed down by the cycle time of AC160 and

the resolution of the results is limited by the cycle time of AC800M. The results

can therefore be looked at as worst-case values, while the exact time used for communication only is considered to be somewhat lower in most cases.

An important thing to know is that all the other values, which are transmitted

with every cycle but are not directly relevant for measuring the RTT, changed every

controller cycle. While this does not matter for the fieldbus communication it has

an influence on the OPC communication. The common subscription mode for the

OPC bridging software works differential, that is, values are only transmitted when

they change, which saves CPU load. In order to test the worst case scenario—which

is our task—it is therefore necessary to transmit a new value with every cycle.

A problem that showed up was the cycle time of the AC160 program code

and the cycle time of DSPs transmitted on AF100. For Tests 0 to 3, both values

are constantly 8 milliseconds, which make these tests very comparable. Since the

amount of values increases a lot for Tests 4 and 5, the performance of both the CPU

and the bus are not sufficient anymore and need higher cycle times. However, higher

cycle times on AC160 and AF100 make the RTT slower and results are not directly

comparable to the first tests due to changed conditions. For better understanding it

was therefore decided to test with different configurations and cycle times depicted

in Table 4.2. The trade off is to have lower (faster) cycle times in exchange for OPC

server load: While with configuration A it is a worst-case test, the RTTs get very

high and are not directly comparable anymore. Configuration C makes also Test 4

and 5 directly comparable to the others, but it is not a worst-case test anymore.

For better understanding the following definitions we introduce two terms: For

each configuration there is only one receiving and one sending DSP relevant for

measuring the round-trip times on AF100, containing the variables to time the

connection. We call them the two measuring DSPs while all other DSPs are called

load DSPs.

• Configuration A: The cycle time for all DSPs on AF100 is identical and

complies with a safe choice for the AF100 bus load (see Appendix D). Since

for Tests 4 and 5 the program code runs faster than the bus, there is a new

value sent in each bus cycle.

• Configuration B: The cycle time for the measuring DSPs is set to same value

as the program code cycle time. All load DSPs are sent as in configuration A.

For Tests 4 and 5 this means that load values change only every fourth time

in comparison with the measuring value.

• Configuration C: It is of course not possible to set the DSP cycle time faster

than the program code. Thus it would never be possible to reduce it to 8 ms

for Tests 4 and 5. We therefore installed a second processor module, working

at 8 ms cycle time and only processing the measuring DSPs while the load

DSPs were still processed in the first module. For Tests 4 this means that

load values change only every eighth time compared to the measuring value,

for Test 5 it is even only every 16th time.

The 8 ms cycle time for AC160 program code and AF100 for Tests 0 to 3 was

chosen since it fits for all these tests and still is in the range of other component’s

cycle times. Of course it would have been possible to simply increase the cycle

times for Tests 0 to 3 in order to have the same preconditions as in Tests 4 or 5.

But since it is our task to evaluate the performance of the communication and not

the controller we decided not to falsify results by doing so.

4.4.2 Integrity

The intention of this measurement is to prove that every linked value is communicated correctly (not just the ones relevant for measuring the RTT). For this reason,