Industrial Ethernet and new possibilities - Simplifying function tests of industrial devices

(1)

Link¨oping Institute of Technology

Industrial Ethernet and new possibilities –

Simplifying function tests of industrial devices

Master thesis in Computer Engineering by

Henrik Nor´en

LiTH-ISY-EX--10/4353--SE

Supervisor: Jimmy Kjellsson ABB

Examiner: Olle Seger

(2)

(3)

What do you do if you are implementing a new fieldbus protocol in your embed-ded industrial system and want to test it? This was the question that a group of engineers at ABB Corporate Research was asking themselves. Normally, the easiest way would probably be to buy a matching device supporting the same protocol and hook it up to the system. You might also need some equipment to listen in on the traffic between the two, so you’d need to buy that too.

But what if you are working with a limited budget? Or what if this protocol is fairly new, and matching devices are hard to find? Or what if you want to test cases that can’t normally be achieved with normal usage?

Normally, with traditional fieldbus standards, this could be complicated. You would probably need an additional sample of your new system, with some cus-tom made test code, and use this to test the original system. This is not a bad method, but this report will give an example of the new possibilities that comes with the new Ethernet base fieldbus standards emerging on the market today. It will highlight the possibility to create a test tool for your industrial system to use on a standard PC.

”Why?” you might ask. The report suggests that this solution is cheap, fast and flexible. First of all, no special hardware was needed, which had a posi-tive impact on cost. The only thing used was a PC and some standard office equipment.

Second, once the test tool was created, new test cases was really fast and easy to make. The test tool was designed to function as a general framework for creating dynamic test sequences based on Ethernet.

Third, the tool is flexible enough to test a lot of different cases, even cases not allowed by the standard. It made it possible to test cases that would have required the use of several samples of test system simultaneously to work. Also, because Ethernet is such a well known standard, there are a lot of existing software tools at your disposal. For example, free software for capturing and analyzing the test results was used during the tests. Furthermore, since the test tool was designed to be easily extendable to handle more protocols, it is even more flexible and useable for future similar problems.

(4)

Abstract i List of Tables iv List of Figures v List of Abbreviations vi 1 Introduction 1 1.1 Problem Description . . . 2 1.2 Goals . . . 2 1.3 Method . . . 3 1.4 Scope . . . 3 1.5 Definitions . . . 3 2 PROFINET IO 4 2.1 Organization . . . 4 2.2 History . . . 5 2.3 Features . . . 7 2.4 Architecture . . . 8 2.5 Protocols . . . 10 2.6 Underlying Protocols . . . 10 3 DynamicSequenceDesigner 17 3.1 Purpose . . . 17 3.2 Functionality . . . 17 3.3 Interface . . . 18 3.4 Design Elements . . . 18 3.5 Work Flow . . . 20 3.6 Future Work . . . 22 4 Test Specifications 24 4.1 Definitions . . . 24 4.2 Environment . . . 24 ii

(5)

4.3 Method . . . 25 4.4 TC1 . . . 26 4.5 TC2 . . . 27 4.6 TC3 . . . 28 4.7 TC4 . . . 30 4.8 TC5 . . . 31 4.9 TC6 . . . 32 4.10 TC7 . . . 33 5 Test Results 35 5.1 TC1 . . . 35 5.2 TC2 . . . 36 5.3 TC3 . . . 37 5.4 TC4 . . . 38 5.5 TC5 . . . 38 5.6 TC6 . . . 39 5.7 TC7 . . . 39 6 Conclusions 40 References 42

(6)

List of Tables

4.1 The hardware used in the tests . . . 24 4.2 Short descriptions of test cases . . . 25

(7)

2.1 Timing of the MAC access . . . 8

2.2 Establishment of an AR between IO controller and IO device . . 9

2.3 Layout of the IEEE 802.3 Ethernet frame . . . 11

2.4 Layout of the Ethernet frame with IEEE 802.1Q (VLAN) tag (dashed) . . . 12

2.5 Layout of the IPv.4 header . . . 13

2.6 Layout of the UDP header . . . 14

2.7 Layout of the TCP header . . . 15

2.8 Layout of the DCE/RPC header . . . 16

3.1 Sequence of frames imported into DSD . . . 21

3.2 Modified sequence in DSD . . . 22

4.1 Simple connection sequence used in tests . . . 26

4.2 Test setup of TC1 . . . 26 4.3 Test setup of TC2 . . . 27 4.4 Test setup of TC3 . . . 29 4.5 Test setup of TC4 . . . 30 4.6 Test setup of TC5 . . . 31 4.7 Test setup of TC6 . . . 32 4.8 Test setup of TC7 . . . 33 v

(8)

List of Abbreviations

AR . . . Application Relation CM . . . Context Mangement

DCE/RPC . . . Distributed Computing Environment/Remote Procedure Call

DSD . . . DynamicSequenceDesigner FF . . . Foundation Fieldbus

IEC . . . International Electrotechnical Commission IEEE . . . Institute of Electrical and Electronics Engineers IP . . . Internet Protocol

ISA . . . Instrument Society of America LAN . . . Local Area Network

MTU . . . Maximum Transmission Unit

PI . . . PROFINET & PROFIBUS International PNO . . . PROFIBUS Nutzerorganisation e.V. TCP . . . Transmission Control Protocol UDP . . . User Datagram Protocol VLAN . . . Virtual Local Area Network

(9)

Introduction

If you take a look at the trends on the industrial fieldbus market today, you will see that a lot of focus is on Industrial Ethernet. Industrial Ethernet is a collective term for the different emerging fieldbus standards that are using Ethernet as its link layer protocol [10]. It seems like the way to go for all of the big existing producers of fieldbus technology, and also a few new ones. But is this development really the next logical step from a technical point of view?

The largest downside of Ethernet from a fieldbus standpoint is the origin of its name. The word ether relates the protocol to the way radio wave based communication methods work, which communicates over what is historically called ”the Ether”. If you want to say something over the Ether, you just shout it out using your walkie-talkie or your radio broadcasting station. The problem is that if someone nearby also shouts something at the same frequency at the same time, the messages interfere. This means that both parties have to repeat their messages to be heard. Chances are that also the following attempts will fail for the same reason.

Ethernet works basically the same way. Of course there are mechanisms for trying to avoid repeated collision of messages, but there is no way of fully predicting the behavior of the transmissions. From a real-time point of view, this is terrible. And real-time is what fieldbus technology is all about. So the question is: what advantages can Ethernet offer to make up for this fundamental shortcoming?

As I see it, the thing that makes Ethernet so attractive for fieldbus developers is the fact that it’s so widely spread. This brings a lot of advantages. Like the possibility to reuse tested hardware and software designs, using existing knowledge to reduce developing and manufacturing costs, benefitting of the constant development in performance and the possibility to integrate solutions with just about anything.

(10)

CHAPTER 1. INTRODUCTION 2

This thesis tries to emphasize one of the advantages mentioned above, namely the ease of integration. In it will be described how a standard office PC can be used in the early stage function testing of an industrial device with PROFINET IO support, without the need for any additional hardware. I think it goes to show that there are new possibilities to be explored in the new area of fieldbus technology, Industrial Ethernet.

1.1 Problem Description

The thing that initially triggered the request for this thesis report was the implementation of support for PROFINET IO communication in an existing industrial device in the ABB product line. The task was carried out by a group of engineers at ABB Corporate Research in V¨aster˚as. The tools at hand was an example of the device hardware, the device source code and the source code for a PROFINET IO communication stack, implemented by a third party com-pany. The initial problem lied in integrating the communication stack into the device. This required not only pure programming work, but more importantly interpretation of the standard and mapping of its logical design to the practical features of the device.

When the group started to make progress in their work, the next problem facing them was how to test the result of their efforts. The device that they where working on was mainly a slave device, and ABB did not at this time have a controller (master) with support for PROFINET IO, which made the problem even more difficult. How can you test communication from one part if you do not have a counterpart? Here is where the they saw the need for spending some time to investigate the possibility to develop a relatively simple and cost effective way of testing this device.

1.2 Goals

The goals of this thesis are to:

• Develop a software tool that can emulate the communication behavior of different test setups in order to verify the functionality of a hardware device.

• Try to make the tool as general as possible to make it easily adaptable for other test scenarios

• Identify the advantages and disadvantages of the proposed approach. • Foresee the future possibilities of the proposed approach.

(11)

1.3 Method

To reach the goals of this thesis, both practical and theoretical work will be needed. The practical work will consist of implementing a PC software tool for generating test sequences using Ethernet.

The design of a number of test cases will also be a part of the work. To be able to design the test cases, studies of the PROFINET IO specification will be needed.

An evaluation will be made where the proposed technique is compared to the possible alternatives.

1.4 Scope

The scope of this thesis is not to produce a production quality PC tool. To have time to complete all parts of this thesis, I will have to limit the software development part to the most basic functionality for performing the intended tests. This does not mean that the quality of the software will not be prioritized. One of the requirements on the software is to make it general and extendable. This is not easy to achieve, and a lot of time must be spent on implementation design.

It is also not in the scope of this thesis to completely test the functionality of a hardware device. The tests that will be performed are more proof-of-concept. It’s more important to find out what kind of results the test can give, than the actual results. The test cases are designed to test different aspects of both the devices and the test software.

The informational section about PROFINET IO is added to put the work in a perspective, and also to give the reader the technical foundation needed to understand the problems of this thesis and the proposed solution.

1.5 Definitions

To keep some consistency in the reasoning of this thesis and to save the reader some trouble, this section defines a number of special terms that will be used in this document.

This work mostly circles around two hardware artifacts; the test host and the test target. The test host is the host of the test software which will be developed. The test host will be able to emulate the behaviour of different devices, and will be connected to the test target. The test target is the device tested and analyzed. The test software refers to the software tool which will be designed to generate the dynamic test sequences.

(12)

Chapter 2

PROFINET IO

ABB has chosen to support and to help develop the open fieldbus standard PROFINET IO, with intentions of making it a global standard in the automation industry.

PROFINET IO is still a relatively new standard, like most industrial Ethernet-based real-time communication systems. Even so it has a strong position in the field of fieldbus. One of the most important reasons, according to me, is that it embraces the one thing all companies have in common: the will to save money. The concept of using Ethernet-based solutions for real-time communication is starting to be accepted in the industry. The advantages of Ethernet-based standards are more and more evident, but the biggest motivation is, as always, the cost. The costs can be reduced in many different fields both for the vendors and the end costumer.

This chapter contains information about PROFINET IO which is necessary for the reader to understand the design decisions described in chapter 3 and to follow the test case scenarios in chapter 4.

2.1 Organization

PROFINET and its older sister PROFIBUS are both open standards. The stan-dards are promoted and administered by the PI (PROFIBUS & PROFINET International) with more than 1400 members worldwide in its 25 regional as-sociations [9]. The organization provides information, technical support and training, certifies products and coordinates development of the standard.

(13)

2.2 History

The history of fieldbus technology is important to understand why the standards look the way they do today.

2.2.1 Technology

The term fieldbus is informally defined in [15] as a network for connecting field devices such as sensors, actuators, field controllers such as PLC’s, regulators, drive controllers, etc., and man-machine interfaces. The fieldbus technology was first introduced in the early 1970s as a replacement for the old 4-20 mA analog signals, which was used for communication between devices and con-trollers at that time.

The old analog way of communicating was very inflexible. Every signal between a device and a controller needed a separate pair of wires. This made wiring of large systems very difficult and expensive, not to mention expansions of existing systems. Field devices at this time had no logic capabilities, and were basically only remote sensors or actuators, which were directly controlled by the central controller.

When the fieldbus technology arrived it offered a more flexible way of commu-nicating. Instead of every signal being sent in parallel, they could all be sent together serially over a single pair of wires. Systems could now be designed using a wider range of topologies than before, like bus, star, ring and tree, in-creasing the flexibility. It also opened up the field for more intelligent devices, since field buses also could be used for other types of communication than just signal values. Things like alarms, status reports, configuration settings and other commands could be sent together with signal values over the same bus. With more intelligent devices, the control could be distributed over the whole system, which has a lot of advantages like:

• Reduced work load on central controller.

• Reduced communication load between device and controller. • Increased support for remote error handling.

• Encouragement of more modular and flexible systems.

Fieldbuses was initially based on a reduced version of the OSI-model [10], with only three layers: physical, data-link and application layer. This is because of the false assumption that reducing the 7-layer OSI-model was necessary to reduce the delay in the layered structure of the implementation of fieldbuses. This is of course not true since the OSI-model is only conceptual and not an implementation scheme [15]. In reality, several of the services of the removed layers was still needed but was placed in one of the three remaining layers.

(14)

CHAPTER 2. PROFINET IO 6

2.2.2 Standardization

It was not until the mid 1980s that the standardization process of fieldbus tech-nology began [5]. The standardization started in Europe by the International Electrotechnical Commission (IEC) as a project to find one single standard for all needs. French FIP (later WorldFIP) and the German PROFIBUS were both successful and standardized on the respective national level and were both proposed for international standardization by the IEC. The problem for the IEC was that they where very different and suited for different needs, and an international standard needed the capabilities of both. This resulted in the attempt from both parties to extend their existing solutions to meet the de-mands. In 1995, after more than 8 years of efforts to combine the German and French approaches, several American companies started to define a new stan-dard outside the IEC, within the Instrument Society of America (ISA). The result was the Foundation Fieldbus (FF), which used selected parts of both FIP and PROFIBUS. At this time the Europeans where still busy with their national standardization and the work of the IEC was mostly influenced by FF. A new draft for an international standard was developed and was a mixture of FF and WorldFIP, and was up for voting in 1996. This upset the PROFIBUS side a great deal and was the beginning of what is referred to by [15] as the international fieldbus war. All sides used every means possible to secure the future of their own systems. The end of the war came in 1999 when all parties signed a Memorandum of Understanding to accept the solution of creating the fieldbus standard, called IEC 61158, as a collection of all existing fieldbus sys-tems. Eight different systems in a few different flavors each were included in the standard. PROFINET was introduces in 2001 [11] and was added to IEC 61158 to complete the standard.

This solution has both good and bad sides. The standard itself is useless for any implementation without the additional standard IEC 61784 that specifies which parts of the different profiles that can be used together in a system. This solution is far from simple to grasp because of the different parts that needs to be connected. On the other hand it gives the user very much freedom and a lot of choices to pick and mix the parts of the standard that suits its needs. During the fieldbus war the focus moved from the technical to political and monetary aspects. Since the process was so slow, the standard proposals had time to grow in popularity on different fields. To choose only one solution as the global standard would have been very expensive for the companies that had already chosen the other one. But the companies are not out of the woods yet. To bet on the wrong horse can still be a costly mistake for any company. The only difference now is that the market, instead of a standards organization, eventually may choose a winner. This makes the companies cautious and not so eager to make a decision. This could be a slowing factor in the development on the market.

(15)

PROFINET in coming products. One reason could be that one of the strong developers of PROFINET is SIEMENS, which is one of ABB’s main competitors with many similar products. This means that PROFINET is also well suited for ABBs products and that this support is important to compete under the same conditions.

2.3 Features

2.3.1 Communication Types

PROFINET IO supports three different kinds of communication: cyclic I/O data, acyclic record data and acyclic alarms. The cyclic I/O data is sent peri-odically without acknowledgement with a rate determined during the connection between the devices in question. All input data from an IO device is bundled and sent together in a single frame to increase performance. The same goes for output data from an IO controller. A new feature compared to PROFIBUS is that the IO data is sent together with consumer or producer status respectively. This way it is possible tell the correctness of the data without diagnostics [12]. This is also to increase the performance of the communication.

2.3.2 Real-Time

Real-time is a term frequently used in the industry world, and it often concerns communication. But real-time is a fairly wide concept and it is not always clear what it means. Even though there are different levels of real-time, within communication, the bottom line is always the same: you want to send a message, and if it arrives late it is useless. The levels of real-time can range from ”a frame in an on-line video feed was delayed and the viewer experienced a lag” to ”the collision alarm message in a car was delayed and the airbag went off to late”. Both these systems deal with real time requirements, and the levels of the requirements are often measured on a scale between hard and soft. The requirements can be described in such terms as:

• Maximum delay. • Maximum jitter.

• Minimum rate of met deadlines.

Plain Ethernet can not be used for applications with any kind of hard real-time requirements [4], but several approaches exist to achieve Ethernet-based real-time communication. Three types are listed in [6] and they can be de-scribed as ”on top of TCP/IP”, ”on top of Ethernet” and ”modified Ethernet”. PROFINET is placed in the last category since it uses the additional standard IEEE 802.1Q which defines a technique for creating virtual LANs within the

(16)

a LAN. This standard uses a tag within the Ethernet header (see figure 2.4). This tag contains a field for prioritising packets, which is used by PROFINET. PROFINET needs special hardware to handle its highest level of real-time. PROFINET has three levels of real-time to handle all types of real-time de-mands:

• Non Real-Time (NRT). • Real-Time (RT).

• Isochronous Real-Time (IRT).

Figure 2.1: Timing of the MAC access

PROFINET divides the time into send cycles. Each cycle is divided into seg-ments, which are dedicated for different kinds of traffic [13] (see figure 2.1). This is to ensure the different performance requirements of the different levels of real-time. The first two levels are the most important for this thesis.

2.3.3 Integration

One important feature, that has surely influenced the work of the developers, is the ease of integration of PROFINET IO systems with systems using older fieldbus standards, and especially with PROFIBUS. These kinds of requirements often make the work a bit harder in the design process, but are a huge advantage when selling a system. Companies don’t gladly replace functioning systems, and now they don’t have to. They can expand old systems with new parts, with new technology without having to give up the old system that has worked perfectly for many years.

2.4 Architecture

2.4.1 Device Types

PROFINET separates all possible hardware devices into three different types: • IO controller.

(17)

• IO supervisor.

The different types have different behavior and different roles in a system. The IO controller and IO device are the most important for this thesis. Their be-havior are targets of the test cases described in chapter 4. Even so there is no technical limitation stopping tests including IO supervisors.

2.4.2 Application Relations

Application Relations (AR) are used for all communication that belongs to a previously made connection. Connectionless communication is also possible, but then an implicit AR is used. Figure 2.2 shows how an AR is established between an IO controller and an IO device. The controller initiates the connection with a connect request. The IO connect request contains information about what type of connection and alarms the controller want, what parts of the device that the controller want to have access to and general communication parameters. The IO device checks the information for errors and responds. If the controllers model of the device differs from how the device is actually modeled, the device lets the controller know which parts are different. The model is based on a two level system with modules and submodules. Every type of submodule contains a factory set number of channels, which can be input or output.

Figure 2.2: Establishment of an AR between IO controller and IO device After the connect request, the controller sends one write request for every con-figured submodule on the device. It then terminates the write sequence with a parameter end request. The device answers the parameter end, and then sends a application ready request back, which ends the AR establishment when it is acknowledged by the controller.

(18)

2.5 Protocols

2.5.1 PNIO-NDR

This protocol is not optimized for real-time usage. It uses the services of DCE/RPC (see section 2.6.5), which have high reliability but no real-time ca-pabilities. It is used for the non real-time activities, like context management (CM) and to asynchronously read and write record data. CM is the part of PROFINET IO that sets up and handles the connections.

2.5.2 PNIO-DCP

DCP, or Discovery and Configuration Protocol, is used to set up the most basic parameters of devices, like station names and network addresses. The protocol is run directly on Ethernet because it must be usable even if the network is not set up.

2.5.3 PNIO-RT

This protocol is used for the cyclic data transfer. It is a very streamlined protocol and is run directly on top of Ethernet. The header consists only of a 2 Byte frame id. After that follows all input or output data arranged according to slot, subslot and channel addresses. A 4 Byte trailer including a sequence counter and status indicators finishes the frame.

2.6 Underlying Protocols

For the physical and data link layers, defined in the OSI model [10], PROFINET IO relies on the standard IEEE 802.3 [8], also called Ethernet.

2.6.1 Ethernet

Ethernet is used for the physical and data link layers. The physical layer is outside the scope of this thesis. It is not necessary to alter or monitor the behavior of the physical layer in order to meet the goals of this thesis. The data link layer on the other hand must be both monitored and altered. It should not be altered from the viewpoint of the tested device, but the alteration lies in the behavior of the test host in the role of an Ethernet node. This will be discussed further in section 2.6.1.2.

(19)

2.6.1.1 Protocol Layout

There are two different Ethernet flavors that are relevant in the scope of this thesis. First of all, the current version of IEEE 802.3 (figure 2.3) is merged from two slightly different versions of Ethernet: the original version of IEEE 802.3 and Ethernet II, which was the industrial developed version. Both of these are used today and are coexisting on the Internet. Both are also allowed according to the current standard IEEE 802.3.

Destination Source 8 16 24 32 0 Checksum Data... Length/Type Code

Figure 2.3: Layout of the IEEE 802.3 Ethernet frame

The only difference between IEEE 802.3 and Ethernet II was the meaning of the last two octets of the header. Ethernet II used this field to identify the protocol inside the frame while IEEE 802.3 used it to tell the length of the whole frame. The two versions can coexist in one standard since the value of the field in the two versions does not overlap. Ethernet only supports frame lengths of up to 1500 bytes. This means that the largest value of the length field is 0x05DC (decimal value of 1500 expressed as hexadecimal), and it is therefore decided that the allowed range of type codes start at 0x0600. These type codes are assigned globally by the ”The Internet Assigned Numbers Authority” (IANA) and therefore consistent over time. There is no shortage of type-codes, so the limitation of range is of no practical concern. The only practical difference for this work is the way to interpret the frames. For Ethernet II, you have to get the length of the frame from the surrounding frame. In the other case, you have the length, but to know what protocol the frame contains, you need an extra protocol header to house that information. This makes Ethernet II the simplest protocol to handle with the least overhead, and this is probably the reason why this is the most used version of Ethernet today.

The second version of Ethernet in this report is Ethernet with IEEE 802.1Q (VLAN) extension (figure 2.4). The VLAN technique groups network nodes together in the same way a LAN does, but does not require the nodes to be con-nected to the same network switch [16]. The VLAN tag is used by PROFINET IO only to set the priority of Ethernet frames. Switches that support frame prioritizing have different queues for the different priority classes [7]. This is

(20)

one of the measures to achieve real-time capability. The VLAN extension is rec-ognized by the type-code value of 0x8100. The tag itself contains some priority information and also an additional type field, which identifies the protocol of the packet inside the Ethernet frame

Destination Source 8 16 24 32 0 Checksum Data... Type Code (x8100) Prio

CFI

VID

Type Code (for data)

Figure 2.4: Layout of the Ethernet frame with IEEE 802.1Q (VLAN) tag (dashed)

2.6.1.2 Possible Issues

All nodes in an Ethernet network have a globally unique address, a MAC ad-dress, hard coded in a ROM memory. This is of course also true for the test host device. Several of the test cases in this thesis include systems with more than two nodes. This means that the test host must simulate the behavior of more than one Ethernet node. This behavior will conflict with the fact described above which means that one network node only can use its hard coded MAC address. Luckily this rule can be overridden with the software library used in the implementation of the test software. With this library you can create frames exactly the way you want. This feature is a requirement to be able to simulate several devices with only one actual device. The only downside with this free-dom is that the responsibility to generate correct frames lies with the user of the software.

Another issue is the checksum of the frame. To be sure that the receiver accepts the frame, the checksum has to be calculated. Since the frames content is dynamic, the calculation must be done during sequence runtime before the frame is sent. This has a negative performance impact but the size is not easy to predict.

(21)

2.6.2 IP

The Internet Protocol [2], or IP, takes care of the network layer for the non-real-time parts of the PROFINET IO standard.

Version

Fragment Offset

8 16 24 32

0

Length/Type Code

IHL TOS Total Length

Identification Flags

TTL Protocol Header Checksum

Source IP Address

Destination IP Address

Data... Options + Padding

Figure 2.5: Layout of the IPv.4 header

The IP datagram is illustrated in figure 2.5. The header is of variable length because of the variable number of options, and can vary from 20 to 64 bytes. The actual header length is given in the Internet Header Length (IHL) field in the header. The value represents the number of 32 bit (4 byte) words in the header. The standard value is 5, which means 20 bytes, which means that no options are used.

The variable length adds some minor problems when interpreting this protocol. Also the header checksum must be calculated and updated before packets are sent, or else the receiver will discard them as corrupt. One difficulty when implementing this protocol is fragmentation. If an IP packet is larger than the MTU of the underlying protocol, it is fragmented and sent in pieces. This brings up the question how this should be handled in the test software. One must also consider that fragmentation is really uncommon for IP. Software developers often try to avoid fragmenting, and one reason is the performance loss.

2.6.3 UDP

UDP, or User Datagram Protocol [1], is a best effort transport layer protocol. It only offers the most basic services for transporting data from one program to another and makes no guarantees concerning the arrival of the data. This makes it really easy to use with very low overhead.

(22)

The layout of UDP is the most straightforward encountered during this work. It only contains four fields which is illustrated in figure 2.6. It has a fixed length which makes it easy to interpret.

Figure 2.6: Layout of the UDP header

The only difficult part of the protocol is the checksum, which needs to be up-dated before transmitting. Fortunately the checksum can be offloaded by setting the value to 0. This means that the checksum is ignored by the receiver, which saves time and effort both during implementation and runtime.

2.6.4 TCP

The Transmission Control Protocol [3] is a transport layer protocol which guar-antees that data will be delivered, if possible. The delivery of data to the higher level protocol will be in the right order and without errors. The protocol does not guarantee anything concerning performance.

The TCP protocol header (figure 2.7) is, much like IP, of variable length. This feature is, also much like IP, seldom used. The length of the header can be read in the field ”data offset”, which gives you the number of 32 bit words in the header, just like IP. Given that options seldom are used, this value is normally 5. TCP is a more complex protocol than its sister protocol, UDP, and therefore needs more information in the header.

The only problem with interpreting a TCP header is the variable length. This is because the complete structure of the header can not be determined until the first parts of the header are read.

(23)

Source Port Acknowledgment Number 8 16 24 32 0 Destination Port Header

Length Reserved Flags

Sequence Number Options + padding Checksum Window Size Urgent Pointer Data...

Figure 2.7: Layout of the TCP header

The checksum is handled in the same way as with UDP, it is offloaded by setting value to 0.

2.6.5 DCE/RPC

DCE/RPC [14] stands for ”Distributed Computing Environment / Remote Pro-cedure Call”. This protocols purpose is to let programmers write programs for a distributed environment without having to worry about where code is run. It is the same to make a local procedure call as it is to make a remote one. This protocol is used in PROFINET IO because, according to [14]: ”UDP in combi-nation with CL DCE RPC provides a ’better’ TCP in case of retransmissions and a lean implementation for field devices”.

DCE RPC, illustrated in figure 2.8, is a fairly complex protocol, and the subset that PROFINET IO uses has large headers of 80 bytes.

If you study the protocol header, you see that you have the possibility to change the data representation. You could for example change from big-endian to little-endian, and from ASCII to something else. This could be an extra thing to think about when interpreting the protocol. Otherwise the protocol header has a fixed size and contains no checksum or other types of values that needs to be calculated during simulation-time. This makes it straight forward to handle.

(24)

CHAPTER 2. PROFINET IO 16 Interface UUID Activity UUID Version Object UUID 8 16 24 32 0 Flags Data Representation Type Serial High

Server Boot Time

Interface Version

Sequence Number

Operation Interface Hint

Activity Hint Fragment Length

Fragment Number Auth prot Serial Low

Data...

(25)

DynamicSequenceDesigner

This chapter is a presentation of the software tool DynamicSequenceDesigner (DSD) which has been developed as a part of this thesis project. The function-ality and the major design decisions will be presented and explained. The tool is designed to be as general as possible in order to make it extendable to handle new protocols and new functionality. In this project it will be used for testing of PROFINET IO devices.

3.1 Purpose

To be able to test the functionality of any given network device, you basically need a way to control what is sent to the device, and to monitor what is sent in return. There are many software tools that are designed to do just this for different, often very specific, target applications e.g. specific network protocols. This is also the case with PROFINET IO. One problem with such tools is that they are often limited in their functionality, for example if they can only simulate correct behaviour. In some cases you prioritise having better control over which test cases you can design over the ease of use, which come with single purpose software. For example, when a protocol is in an early development stage, you might want to test cases that are not allowed according to the standard. In these cases it would be useful to be able to design completely customized sequences of frames and send them to the device.

3.2 Functionality

DSD is a software tool written in C# for .NET that allows you to create and send custom Ethernet frame sequences with the help of a graphical interface.

(26)

CHAPTER 3. DYNAMICSEQUENCEDESIGNER 18

DSD works well together with Wireshark [17]. Wireshark (formerly known as Ethereal) is an open source tool available for all large platforms, i.e. Windows, Linux, OS X and Solaris. Wireshark is the de facto standard network protocol analyzer. It supports hundreds of protocols.

Since Wireshark is such excellent software for Ethernet frame capturing, in-tegrating capture functionality into DSD would have been like inventing the wheel again. With DSD you can either open complete frame sequences saved with Wireshark, or you can just paste single frames directly into DSD copied from Wireshark.

3.3 Interface

The structure of the graphical user interface and consists of two lists (see figure 3.1). The left list contain the instructions that are used to create sequences (described in section 3.4.2). The other list shows the properties of the selected instruction. Over the instruction list is a toolbar with tools that can be used on the instructions. Over the instruction toolbar are three input fields. Two of the fields are drop-down boxes, which let you choose the network devices for incoming and outgoing traffic. The third field is a text input, which lets you filter incoming traffic with the syntax of the WinPcap library also used in Wireshark. The menus contain functions for saving and opening files, and to copy and paste frames.

3.4 Design Elements

The design of the DSD has been a fairly large part of the work of this thesis. It has definitely been a good way to understand the requirements of the task. This section contains brief descriptions of the basic design elements that affect the functionality of the test software.

3.4.1 Protocols

To make it easy to extend this software to handle more protocols, the procedure to implement a new protocol must be simple and properly specified. This is accomplished by an abstract class called Protocol. This helps the programmer to create new protocol implementations and provides him or her with many tools used to operate on the protocol.

Basically all you need to do to implement a new simple protocol is to describe the structure of the fields of the header. All fields in this description are in-dividual objects that are added to an ordered list structure. You can choose

(27)

from different predefined classes for the fields depending on their type, e.g. IP-address, unsigned byte and UUID. All field classes have the same base class, which makes it easy to work with them. It is also possible to implement new field classes if needed.

Basic properties of a protocol: • Name and description. • Total length of the header. • An ordered list of fields.

• Protocol object that specifies the type of the containing protocol. Tools that are given from the base class lets the implementer:

• Interpret the content of the protocol from a stream of bytes. • Generate a stream of bytes from the current values of the header. • Get the value of a specific field in the header.

3.4.2 Instructions

The Instruction base-class is created to make the instruction set extendable, just like the rest of this software. When implementing an instruction, this is the functionality that every new instruction needs:

• The ability to execute itself.

• The ability to save its current state into an XML document. • The ability to restore its state from the same XML document.

To build sequences with DSD, you create simple ”programs” with the help of a number of instructions. The most basic instruction is Send. Like the name implies, send is used to send an Ethernet frame. You can alter all values of the protocol header of the frames that are sent. You can also choose the values to be either static predefined or fetched from the global register, which is described in section 3.4.3. With this instruction alone you can create static sequences without the control of timing.

To create meaningful test cases, it’s not enough to be able to send one static frame after another. You need to be more flexible, and therefore more advanced instructions are needed. For instance, you need to be able to produce the right timing in your sequences. To manage that, the instructions Wait Time and Wait For was designed. Just as the name suggest, Wait Time halts the execution for a predefined number of milliseconds. Wait For is more advanced and halts the execution until a frame is received with selected field values matching the field values of a predefined frame. Wait For also offers the possibility to save the value of any field of the matching frame in the global register. This value

(28)

can then be used in a Send instruction. This creates the base for creating dynamic sequences, meaning sequences that can react to the response of the test target.

An instruction that has its origin in the need of PROFINET IO to send cyclic data is Jump. It is totally straightforward and all it does is to make a jump in the execution order to the specified instruction. This makes it easy to create infinite sequences. Although it is designed with cyclic data in mind, other fields of use exist, e.g. quick repeating of a sequence to test performance.

3.4.3 Global Register

Without the Global Register, all Protocol objects would be totally stateless. This means that they would have no idea what had happened before they where cre-ated, and what other Protocol objects had done or found out. This would be OK if all protocols where created to exist in stateless environments. This is of course not the case. It would mean that all state information would have to be transmitted with all frames exchanged, or the state would be lost forever. This would result in unacceptable amounts of overhead for many protocols. The Global Register works like a shared memory for all protocols. This gives the protocols the chance to create a local protocol state. Objects are saved and retrieved using string identifiers. The performance to retrieve a saved object is close to O(1)1_{. Using hash functions to index the register makes this possible.}

One possible issue using shared memory and string identifiers is the possibility for protocols to overwrite other protocols information. However, this is consid-ered to be a fairly small risk, if protocol designers consider this when choosing variable names.

3.5 Work Flow

This section gives a short description of the general workflow of the DynamicSe-quenceDesigner. The intended way to use the DSD is to reproduce an observed communication sequence, either as an exact copy or in modified form.

3.5.1 Record

First of all you need to record a communication sequence using Wireshark. Wireshark is also a great tool to analyze the captured traffic.

1_{O(1) is read ”ordo one”, and in this case means that the retrieval time is not depending} on the size of the register.

(29)

3.5.2 Import

To start using the DSD, you need to import the captured frames from Wireshark. You can save a selection of the frames in a pcap file, which you can then open in DSD. Another option is to copy single frames from Wireshark using the copy option ”Bytes (Hex Stream)”, and then to paste them into DSD using the ”Edit” menu.

Figure 3.1: Sequence of frames imported into DSD

3.5.3 Modify

When a pcap file is opened or when a frame is pasted into DSD, it appears in a new Send instruction (see figure 3.1). Normally when importing a bidirectional sequence, you only want to send the frames from one of the parties. The frames from the other party is then converted from Send to Wait For instructions. This way the timing of the sequence can be maintained. You can also add Wait Time instructions to further adjust the timing (see figure 3.2).

The frames of the Send and Wait For instructions can now be altered to suit the test cases. If there is need for any dynamic content, like for example assigning values from received frames to fields in frames to send, this can be done with the Global Register.

(30)

Figure 3.2: Modified sequence in DSD

3.5.4 Play and Monitor

When the sequence is ready it should be saved. Now the sequence is ready to be played. To get the proper feedback of the reactions that is induced by the sequence, it is recommended to use Wireshark again to record the procedure. The result can then be analyzed using Wireshark.

3.6 Future Work

There are several new features that would be useful to implement into DSD, except for the obvious GUI and usability issues. One of them is presented below.

3.6.1 Operations on Global Register

The access of the global register is possible from two different abstraction levels: both when implementing the protocol, and also when creating the sequences in the finished software. This means that an active decision must be made where to implement the logic functionality of the protocols. This will be a tradeoff between e.g. flexibility and performance. It is obviously more flexible to do it in the sequences, which are easily changeable, but probably more effective to do it hard coded. To give the users the possibility to implement more functionality

(31)

directly in the sequences, there should be a way to perform mathematical and logical operations on the variables in the global registers.

One solution is to make an instruction that allows the user to enter C# code as strings, which would be compiled before or during the initiation of the simula-tion. This would of course be a sever security hazard. You could also consider making a more rudimentary syntax for the user, with only limited functionality like mathematical and logical functions. This would on the other hand be a more complex task. With this trade-off you would also have to take into consid-eration what would be most useful for the user. This decision is left to whoever sees it their task to implement this.

(32)

Chapter 4

Test Specifications

The tests performed as a part of this thesis have two main goals. The first goal is to evaluate certain aspects of the test targets. Most focus will be on multi controller aspects. The results of these tests will be useful in the development of multi controller applications. The second goal is the most important one for this thesis report. It is to evaluate the concept and functionality of the test tool that has been developed. This chapter will present the conditions of the tests.

4.1 Definitions

To simplify the description of the test cases, the hardware modules used are defined and named in table 4.1.

Name Description

C1 ABB AC 800M Controller C2 Phoenix ILC 350 PN Controller D1 ABB REF615 Device

D2 SIEMENS ET200S IO Module

T1 Test Host (Computer with Test Software) Table 4.1: The hardware used in the tests

4.2 Environment

The test environment can look a bit different depending on the situation, and the nature of the test case in question. The basic test setup is however very

(33)

Name Description

TC1 Connecting and exchanging cyclic data with D1, using T1

TC2 Connecting and exchanging cyclic data with D1, using T1, while C1 is connected TC3 Making multiple concurrent connections

and exchanging cyclic data with D1 using T1 TC4 Making many concurrent connections

to D1 using T1

TC5 Connecting and exchanging cyclic data with D2 using T1

TC6 Making multiple concurrent connections and exchanging cyclic data with D2 using T1 TC7 Testing controller setup, used by ABB

Corporate Research in Norway, on D1. Table 4.2: Short descriptions of test cases

simple: the test host is connected directly to the test target. If more than one test target or test host are used, they are connected in a bus topology using a hub as the central connection point. A hub is used rather than a switch since it is the easiest way to make the test host function properly. The difference between a hub and a switch is that a hub gives every node access to all traffic on the network. This property is important since the test host is designed to monitor the entire network. One of the downsides with using a hub is that it does not comply with the PROFINET IO standard. This has the effect that some features, like performance, cannot be tested since the hardware does not meet the standard. Another downside with using a hub is that one possible application field of the test software is not tested. It would be useful to connect the test host directly to an existing network of devices and test them on site. It is possible that this would need some reconfiguration of the network, but this is not further examined in this thesis.

4.3 Method

Before the tests, a simple connection sequence between C1 and D1 is recorded. This is done with T1 using Wireshark. The idea is to recreate or modify the se-quence from the perspective of C1 with the help of the test software on T1. This is done accordingly to the description in section 3.5. The sequence is then started and the resulting communication will be monitored with Wireshark.

The test cases are primarily focused on the concept of multi controller use in a PROFINET IO system. A central part of all tests will be to establish one or several ARs between two or more devices. The recorded AR establishment

(34)

CHAPTER 4. TEST SPECIFICATIONS 26

between C1 and D1 will be used as a reference model, even if it is slightly simplified compared to the one in figure 2.2, since it lacks the write commands from the controller. The reference model is illustrated in figure 4.1.

Figure 4.1: Simple connection sequence used in tests

4.4 TC1

In this first test, T1 will be used to emulate the behavior of C1 connecting to D1 (see figure 4.1). The connection will then be kept alive by the exchange of cyclic data.

D1

T1

(C1)

Connection Cycl. data

Figure 4.2: Test setup of TC1

4.4.1 Purpose

This test is meant to test the basic functionalities of the test software. It will first of all show if the test software works at all. A more detailed question is if it will be able to send cyclic data fast enough. The rate of the cyclic data is

(35)

variable and is given by two variables in the connection request. Therefore we can change these variables and test the software at different rates to see how fast it can operate.

4.4.2 Method

The idea is to record a simple connection sequence between C1 and D1. This is done according to the work flow described in section 3.5. Since this is an attempt to perform an exact copy of C1’s connection, one possibility is that it will work without any modifications. If the connection attempt would fail, the responses from D1 will be examined, and the whole sequence will be compared to the successful one from C1. T1’s sequence will then be modified until it is successful. To get a rough idea of the performance of the test software, a test where the cycle time for the cyclic communication is gradually decreased will be performed.

4.4.3 Expected Result

The expected result in this case is rather simple since we have recordings of successful connections. The expected result is that the Wireshark capture of the test procedure should be more or less identical to the one from C1’s connection to D1. The cyclic communication must run for 3 minutes for the test to be considered successful.

4.5 TC2

This test is a more advanced version of the last one. It will be performed the same way as TC1, but with C1 already connected to D1.

D1

T1

(C1)

Connection Cycl. data Connection Cycl. data

C1

(36)

4.5.1 Purpose

This test will show more about PROFINET IO. For example, it will show the basic requirements for connecting multiple controllers in a PROFINET IO net-work. The connection from T1 will be based on the reference connection. This gives us the opportunity to learn which parts of the protocols that can be left unchanged for the second connection, and which must be unique for every con-nected controller. Since the PROFINET IO stack, used in D1, still undergoes large updates, it is interesting to see its current status regarding features like multi controller operation. The downside of the uncertain status of the stack is that it makes drawing conclusions hard, about if certain behavior is intended or just not properly implemented yet. This makes me think of a classic question in software engineering: ”is this a feature or a bug?” This fact must be considered when evaluating the test results.

4.5.2 Method

The basic steps to perform this test are exactly the same as TC1. The only thing changed in the test sequence compared to the reference model is the MAC and IP addresses, since two different controllers connecting is the desired scenario. Since this is the first test with multiple controllers it is not expected to work at the first attempt. The results of the attempts will be compared to the successful connection between C1 and D1. This will create feedback to use to improve the test sequence until it’s successful.

4.5.3 Expected Result

The expected result is two active connections that run for at least 3 minutes. The connections will take place after each other, and get basically the same response from the device. After both connections are complete, cyclic data will be exchanged both between C1-D1 and T1-D1 at every cycle.

4.6 TC3

In TC3 the lessons learned in TC2 about multiple connections in PROFINET IO will be used to set up a number of unique connections, all managed by T1.

4.6.1 Purpose

TC3 can be seen as a performance test of both D1 and T1. It will test both of them on the ability to manage multiple connections including the exchange of

(37)

D1

T1

(C1)

Connection Cycl. data Connection Cycl. data Connection Cycl. data

cyclic data. We will try reach the limit for how many connections the weakest of the devices can handle. This could be either from resource limitations or specific implementation choices. The limit of the weaker device is of course an important lesson, but we can hopefully also make an estimate of the level of performance of the stronger device.

4.6.2 Method

This test relies on the success of TC2. We need to know how to connect mul-tiple controllers to a single device, which is the desired result from TC2. This information will be used to create a number of unique connections with the test software. The connections will be opened in separate concurrent instances of the test software, so that every instance represents one controller. The com-munication between T1 and D1 will be monitored with Wireshark. Both the content of the responses from D1 and the timeliness of the cyclic data will be noted.

4.6.3 Expected Result

The connections will hopefully result in multiple connections and ongoing cyclic data exchange. At some point, when a new controller tries to connect, one of the following will happen:

• We will get an negative connection response from D1. • D1 will not be able to maintain the cycle time. • D1 will crash from lack of resources.

• T1 will not be able to maintain the cycle time, and D1 will disconnect one or several connections.

(38)

It is hard to set up expectations for the timeliness of the cyclic data. It is also hard to know how accurate the time measurement in Wireshark is. In this case it is assumed that Wireshark is accurate enough for this test. When measuring the timeliness, the average cycle time and the average deviation from that average will be calculated. This will be compared to the expected cycle time.

4.7 TC4

This test is designed to set up as many connections as possible to D1 with only unidirectional cyclic data from D1 to T1.

D1

T1

(C1)

4.7.1 Purpose

The purpose of this test is to determine the maximum number of connections that can be concurrently sustained by D1. It is unknown if this will be revealed already in TC3, but there is a large chance that it will not. The difference with this test compared to TC3 is that cyclic information will only be sent one way, from D1 to T1. This takes the load off from T1 and allows for theoretically an infinite number of connections from T1’s perspective.

4.7.2 Method

The only thing needed for this test case is to send the Connect Request of every connection, and not continue with the Parameter End Request and the cyclic data. D1 will start to send cyclic data directly after it has accepted the connection request. The connections will time out in one or a few minutes, but that is plenty of time to send a lot of connection requests. This will test the performance of D1 without requiring much performance from T1. The

(39)

connection responses and the send-time of the cyclic data will be monitored using Wireshark.

By studying figure 2.1 I draw the conclusion that the cyclic data can occupy up to 50% of the total send time available. Since PROFINET IO operates at full duplex, 50 % of the cycle time can be used in both directions. The cycle time is always known, which means that the total send time of the cyclic data is also always known. At some point it must be impossible for the device to send all cyclic data within this send-time.

4.7.3 Expected Result

The connections will hopefully result in multiple connections and unidirectional cyclic data transfer. At some point, when a new controller tries to connect, one of the following will happen:

• We will get an negative connection response from D1.

• D1 will not be able to send cyclic data within maximum send-time. • D1 will crash from lack of resource.

If the send-time of the cyclic data does not reach the maximum available, it will be measured instead. From this, a rough estimation will be calculated of the maximum number of concurrent connections that are possible from this perspective.

4.8 TC5

TC5 will test a connection from T1 to D2, which has an older version of the PROFINET IO stack.

D2

T1

(C1)

Connection Cycl. data

4.8.1 Purpose

This test is designed to compare the behavior of different devices to get a better understanding of the standard.

(40)

4.8.2 Method

This test will be carried out in the exact same way as TC1. The only differ-ence is that this connection will be based on a connection designed for this device.

4.8.3 Expected Result

The expected result is the same as in TC1.

4.9 TC6

In this test we will try to set up multiple connections from T1 to D2.

D2

T1

(C1)

4.9.1 Purpose

This test is designed to compare the behavior of D1 and D2 to get a better understanding of the standard. It is also meant to test the performance of D2, the same way D1 was tested in TC3.

4.9.2 Method

This test will be carried out in the exact same way as TC3. The only differ-ence is that this connection will be based on a connection designed for this device.

(41)

4.9.3 Expected Result

The expected result is the same as in TC3.

4.10 TC7

In TC7 we try to connect two different controllers (C1 and C2) to D1.

D1

T1

(C2)

Connection Cycl. data Connection Cycl. data

T1

(C1)

4.10.1 Purpose

This test case will explore a slightly different use case for the test software. The test software will be used to investigate the correctness of two connection request frames from C1 and C2. An attempt has been made at ABB Corporate Research in Norway to connect these two controllers to a PROFINET IO device by Phoenix. The attempt was unsuccessful but it was hard to tell if it was the device or the controllers that are causing the problems. The connections will be recreated here to see if the connections are successful on D1.

4.10.2 Method

The connection sequence will be recreated by loading the actual pcap file recorded in Norway into the test software. The pcap file only contains two connection requests and must therefore be extended with ARP frames to let D1 know the Ethernet- and IP address of the simulated devices.

The configuration of the slots and subslots of D1 differs from the device used in Norway. The easiest way to deal with this is to change the configuration of D1 to match the device in Norway.

(42)

4.10.3 Expected Result

The expected result is two positive connection responses and cyclic data loop-ing from D1 to C1 and C2 until it times out because of the inactivity of the controllers.

(43)

Test Results

5.1 TC1

5.1.1 Result

The final result of this test is just as expected. The connection phase behaves just as with the real controller and the cyclic communication runs for as long as the test lasts. During the performance part of the test, the cycle time of the cyclic communication was reduced to 4 ms, which seems to be the shortest time that D1 could handle. T1 has a slight problem to handle this if it is instructed to perform a Wait For for every incoming cyclic frame. Wait For is relatively performance heavy since it has to compare the expected frame to every incoming frame until it finds a match. There is always the risk that the next frame is received before T1 has finished the Send and Jump instructions and has reentered the wait mode. This results in that it occasionally misses incoming frames. The end result is much better when the Wait For is replaced by a Wait Time. The Wait Time is set to 3 ms which results in an actual cycle time of approximately 4 ms.

5.1.2 Modifications Needed

Some modifications where needed before the connection was completely success-ful. At the first attempt, no logic was implemented into any of the PROFINET IO protocols, and the frames were just copied straight off. Some logic can be implemented through the user interface and the global register, but since the functionality is rudimentary, which is described in 3.4.3, some things have to be implemented in the source code of the protocols. Three issues had to be fixed before the connection was successful:

(44)

CHAPTER 5. TEST RESULTS 36

• D1 uses semi-random UDP Source Port for its Application Ready Request. T1 must answer the right port

• D1 uses random RPC Activity UUID for its Application Ready Request. T1 must answer with same UUID.

• The sequence counter of cyclic data trailer is incremented every cycle. Must increment with correct value.

To fix the two first issues you need exactly the functionality that the user in-terface to the global register offers. We just need to save two incoming values (Source Port and Activity UUID ) and use them in outgoing frames. This is straightforward enough and needs no further explanation. To resolve the third issue, slightly more advanced functionality is needed, and therefore it has to be implemented in the source code of the software. The value used to increment the sequence counter has to be calculated by multiplying the Send Clock Factor and Reduction ratio of the IOCR Block Request in the Connect Request. The sequence number has to be incremented with this value each time a new cyclic data frame is sent. This is really not advanced functionality, and it would be sufficient to implement addition and multiplication into the user interface of the global register to be able to simulate this behavior. The replacement of the Wait For with the Wait Time instruction is also a modification and it’s described above.

5.1.3 Lessons Learned

This test has showed us a few practical things of the connection procedure of PROFINET IO. It has also revealed a performance weakness of the test software, i.e. the Wait For instruction. If an answer arrives to fast, the Wait For runs the risk of missing it.

5.2 TC2

5.2.1 Result

The end result is the same as expected. T1 behaves just like C1, which is the desired result.

5.2.2 Modifications Needed

A couple of modifications were needed in the PNIO-NDR protocol. The field CMInitiatorMacAdd needed to have the same value as the MAC addresses of the frame. The CMInitiatorObjectUUID had to be unique for each connection.

(45)

Since the connection means establishing a new AR, the ARUUID needed to be unique for the two connections.

The RPC protocol needed one modification. It was the UUID of the Activity that needed a unique value.

Another important thing that was not revealed in TC1 was about the identifica-tion number of the cyclic data. In the connecidentifica-tion request, the controller decides what ID the device should use for the cyclic frames that are to be sent. In the response, the device tells the controller the same thing. If only one device is connected, the ID from the device is always the same, but when a second controller connects, the device chooses another ID to separate them. The hard coded ID has to be replaced with a dynamic one, which could be done with the global register.

5.2.3 Lessons Learned

We learned more about the different protocols, but the most important lesson was about the multi controller status of the device. We now know that it handles multiple controllers, and some details about how it works.

5.3 TC3

5.3.1 Result

The result of the connections is the same as expected. All connections run without problem.

The question about what sets the limits when it comes to the number of si-multaneous connections in this test, seems to have several answers. First of all, it seems like D1 has quite enough resources like memory and computational power. It easily outperforms T1 at the task of sending cyclic data.

The first thing that limited the number of connections was a setting in the source code of the device, which specifies the maximum number of AR’s. This was increased to keep on testing.

The thing that finally limits the number of connections in this test is that T1 is not fast enough when it reaches a certain workload. The specific problem is most of all an implementation issue of the test software. The sequence flow is too slow at a high workload, so T1 misses responses to its requests because it is still in send mode when the answer arrives. Introducing some smart buffering could help this, but this had to be ignored because of lack of time.

T1 manages to connect and to maintain 5 connections before the performance problems grows too large to handle. The test is later performed with two test

(46)

CHAPTER 5. TEST RESULTS 38

hosts with 4 connections each, which shows that the device handles 8 connec-tions at once. At the test with two test hosts and 8 simultaneous ARs and cyclic data, the timeliness of the cyclic data was measured as described in the test specifications (section 4.6.3). The expected cycle time was 8 ms. The average cycle time from 10 cycles was 7.995 ms with an average deviation of 0.36%.

5.3.2 Lessons Learned

Now we know that the test software is the bottleneck in these tests. We have also seen that it is possible to resolve this by using more than one test host.

5.4 TC4

5.4.1 Result

D1 accepts all connections until we reach the maximum number of ARs de-scribed in the result of TC3 (section 5.3.1), which was set to 20. I considered this to be sufficient test, and the maximum limit was not increased again. The send-time of the cyclic data was measured at two different tries. The average send-time was 0.170 ms for 10 connections and 0.310 ms for 20 connections. This is an indication that the send-time grows more or less in direct proportion to the number of connections, or at least not more.

The cycle time in this test was 4 ms. According to the assumptions in the test specifications for this test case, the maximum send time for cyclic data would be 2 ms. This gives us a theoretical limit of about 120 connections.

5.4.2 Lessons Learned

We now have a rough estimation of D1s performance capabilities when it comes to computational power, and we see that they are reasonable.

5.5 TC5

5.5.1 Result

(47)

5.5.2 Lessons Learned

Now we know that the connection sequence used before also works on this device.

5.6 TC6

5.6.1 Result

Both the connection sequences used in this test works on their own, but never together. They are the same sequences that have worked together before on D1. The error message form D2 is the same that was received from D1 when the preset maximum number of ARs was reached.

5.6.2 Lessons Learned

The circumstances above gives us reason to think that in this older version of the stack, the maximum number of ARs is set to 1, i.e. no multi controller use is possible.

5.7 TC7

5.7.1 Result

Both connections are accepted.

5.7.2 Lessons Learned

I draw the conclusion that there is nothing wrong with the controllers used in Norway. I see two possible explanations to why the connections did not work in Norway. Either the device is not ready for multi controller use at all, like D2, or the device does not accept the configuration of the connections, either on stack or application level. The standard leaves much to the designer of the device to decide how multiple controllers can connect. It would for example be possible to restrict more than one controller to access the same slot/subslot.

Industrial Ethernet and new possibilities - Simplifying function tests of industrial devices