an automated test framework for hard real-time...

55
An Automated Test Framework for Hard Real-Time Communication Systems MITHUN HANUMANAHALLI NAGAIAH Master of Science Thesis Stockholm, Sweden 2012 TRITA-ICT-EX-2012:234

Upload: others

Post on 13-Jul-2020

8 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

An Automated Test Framework for HardReal-Time Communication Systems

MITHUN HANUMANAHALLI NAGAIAH

Master of Science ThesisStockholm, Sweden 2012

TRITA-ICT-EX-2012:234

Page 2: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

ತಂ ಾ ಸಮ

Till mina kära föräldrar

ii

Page 3: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

An Automated Test Framework forHard Real-Time Communication

SystemsMaster thesis project carried out at ABB Corporate Research Center

Västerås, Sweden

MITHUN HANUMANAHALLI NAGAIAHmithun[at]kth.se

Stockholm 2012

Supervisors: Morgan E. JohanssonMattias Rehnman

Examiner: Prof. Axel Jantsch

TRITA-ICT-EX-2012:234

Page 4: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

AcknowledgementsI would like to thank my supervisor Morgan E. Johansson at ABB Corporate Research for hisvaluable guidance during this thesis. I am grateful to my examiner Prof. Axel Jantsch. I wouldlike to thank my project partner Nian Tang for his help and understanding during the thesiswork. It was a nice experience working with him. I would like to thank Mattias Rehnman andPradyumna Sampath for giving me an opportunity to do this project at ABB Corporate ResearchCenter, Västerås, Sweden.I would also like to thank my fellow thesis workers at ABB, my friends Anand Nagarajan, ArulJesu Praveen John, Paulus Alexander Breijder, Rafet Ogul Türkel, Shivashankar Periaswamy,Sriram Yagnaraman, Tuton Chandra Mallick, Vinay Kumar Nagaraj and Vishwanath Rao for allthe fun times and interesting conversations during my Master studies in Sweden.I am grateful for the opportunity to study in Sweden, it has taught me some valuable life lessons.I would like to take this opportunity to thank all my teachers who have steered me in the rightdirection.I am deeply thankful for my parents, my sister and her family for their constant encouragementand motivation.

Page 5: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

AbstractIn the field of Industrial automation there is a huge demand for real time communication networks [1] andthere are several different protocols[2] like EtherCAT[3], PROFINET IO, SERCOS competing each other inthe market[5]. Many of the products in this industry are subjected to hard real-time communication require-ments. The purpose of this thesis is in introducing tools to automatically test the various requirements thatare helpful in deciding the performance of Real time communication systems. Developing a well-defined testframework is one of the important tasks in this thesis project. The end users of the test framework can focusmore on managing and analyzing the results from the framework instead of the design process.

The thesis work presents the test requirements, design of test system and automating the measurementprocess by selecting appropriate hardware. The report also explains the design of commands, method usedfor communication between different systems and also discusses the different methods that could be appliedfor measuring the performance, the limitations of some of these methods when applied to the framework. Thearchitecture and the working of the framework is covered in later chapters. The framework uses EtherCATmaster communication stack developed in-house at ABB[4]. EtherCAT is just used as a pilot test case, butin general the framework could be applied to other Ethernet based industrial communication protocols withsuitable hardware or software modifications.

v

Page 6: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

CONTENTS

Contents1 Introduction 1

2 Purpose of document 1

3 Motivation 1

4 Requirements 34.1 Requirements on test specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34.2 Requirements on test framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34.3 General structure of Ethernet based Real Time communication systems . . . . . . . . . 3

5 Design of the test framework 55.1 Definition of the test framework architecture . . . . . . . . . . . . . . . . . . . . . . . . 55.2 Architecture Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

5.2.1 Globally synchronized clock with PTP . . . . . . . . . . . . . . . . . . . . . . . 65.2.2 Round Trip Latency Measurement . . . . . . . . . . . . . . . . . . . . . . . . . 75.2.3 Absolute Latency Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

5.3 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95.4 Types of slaves . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.5 Data transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5.5.1 Communication pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105.5.2 Design of Datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.5.3 Packet design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6 The I/O Controller or Counter 146.1 Function of I/O Controller during different test case execution . . . . . . . . . . . . . . 14

6.1.1 Round Trip Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146.1.2 Jitter of latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.1.3 Cycle time measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166.1.4 Jitter of cycle times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.2 TestManager and I/O Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7 Software Implementation 207.1 The Programming language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.2 Automated execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207.3 Test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

8 Test Case Design 228.1 Test case: External network latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.2 Test case: Jitter for external network latency . . . . . . . . . . . . . . . . . . . . . . . . 228.3 Test case: Startup time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228.4 Test Case: Deviation of cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238.5 Test Case: Jitter of cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248.6 Test Case: Internal network fault tolerance . . . . . . . . . . . . . . . . . . . . . . . . . 248.7 Test Case: Slave node time synchronization . . . . . . . . . . . . . . . . . . . . . . . . . 26

9 Pilot test case on EtherCAT 289.1 Introduction to EtherCAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289.2 Implementation of Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299.3 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9.3.1 Test cycle time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309.3.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

vi

Page 7: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

CONTENTS

10 Conclusion 34

11 Future work 34

A Appendix 35A.1 Design for command in the framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35A.2 Instructions for compiling the Test Manager with Boost.Python library . . . . . . . . . . . . 39A.3 Driver for NI-PCI 6624 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39A.4 Electrical Connections for NI PCI - 6624 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

A.4.1 Specifications of the Counter: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.4.2 Accessories of the counter: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40A.4.3 Pin Assignments of NI 6624 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41A.4.4 Circuit connections for round Trip Latency Measurement . . . . . . . . . . . . . . . 44A.4.5 Circuit Connections for Cycle Time Measurement . . . . . . . . . . . . . . . . . . 45

vii

Page 8: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

LIST OF FIGURES

List of Figures1 Figure 1: Structure of real time communication systems . . . . . . . . . . . . . . . . . . . 42 Figure 2: Test framework blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Figure 3: Measuring latency using a Global clock . . . . . . . . . . . . . . . . . . . . . . . 64 Figure 4: Global synchronized clock with PTP . . . . . . . . . . . . . . . . . . . . . . . . 75 Figure 5: Round Trip Latency Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Figure 6: Absolute Latency Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Figure 7: Datagram Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Figure 8: Communication pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Figure 9:Round trip latency measurement using two edge separation method . . . . . . . . 1510 Figure 10:Two Edge Separation Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1611 Figure 11:Pulse Width Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1712 Figure 12:Pulse Width Measurement Method . . . . . . . . . . . . . . . . . . . . . . . . . 1813 Figure 13:Test Manager and I/O controller . . . . . . . . . . . . . . . . . . . . . . . . . . 1914 Figure 14:Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115 Figure 15:External network latency sequence . . . . . . . . . . . . . . . . . . . . . . . . . 2216 Figure 16:Startup Time Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2317 Figure 17:Deviation of Cycle time sequence . . . . . . . . . . . . . . . . . . . . . . . . . . 2418 Figure 18:Jitter of cycle time sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2419 Figure 19:Fault Tolerance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2520 Figure 20:Fault tolerance testing sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . 2521 Figure 21:Slave node time synchronization function . . . . . . . . . . . . . . . . . . . . . 2622 Figure 22:Slave node time synchronization sequence . . . . . . . . . . . . . . . . . . . . . 2723 Figure 23:EtherCAT States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2824 Figure 24:Listen2InputSend2Output command sequence . . . . . . . . . . . . . . . . . . . 2925 Figure 25:SendOutputCycle command sequence . . . . . . . . . . . . . . . . . . . . . . . 3026 Figure 26:Oscilloscope measurement of cycle time . . . . . . . . . . . . . . . . . . . . . . 3127 Figure 27:Oscilloscope measurement of latency . . . . . . . . . . . . . . . . . . . . . . . . 3228 Figure 28:Inaccuracy in measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3329 Figure 29:Switch setting for SCB-100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4130 Figure 30:Connector Pinout of I/O Controller . . . . . . . . . . . . . . . . . . . . . . . . . 4231 Figure 31:Electrical connections used for measurement . . . . . . . . . . . . . . . . . . . . 45

viii

Page 9: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

LIST OF TABLES

List of Tables1 Table 1: Comparison of different real time communication networks . . . . . . . . . . . . . 22 Table 2: Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 Table 3: GetStructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354 Table 4: SetupInputListenerD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 Table 5: SendOutput2NodeD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356 Table 6: SetupAllInputListenerD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Table 7: SendAllOutputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Table 8: SendAllTSOutputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Table 9: Listen2InputSend2OutputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3610 Table 10: GroupOutputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3711 Table 11: GroupInputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3712 Table 12: SendOutputGroupD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3713 Table 13: Listen2InputGroupD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3714 Table 14: DismissGroup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3815 Table 15: ConnectIntputD2GOutputD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3816 Table 16: SendOutputCycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3817 Table 17: CloseUp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3818 Table 18: Counter Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4019 Table 19: Counter Pin Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4320 Table 20: Counter Pin Connections cont’d . . . . . . . . . . . . . . . . . . . . . . . . . . . 4421 Table 21: Counter Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4422 Table 22: Pin Connections for pulse generation . . . . . . . . . . . . . . . . . . . . . . . . 4423 Table 23: Pins for edge detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

ix

Page 10: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

3 MOTIVATION

1 IntroductionHard real time communication is usually used in safety critical systems. The performance of these systemsnot only depends on the correctness of the task but also on the time it takes to perform the task and missingof deadlines can prove fatal.

Hard Real Time Systems commonly finds its application in manufacturing industries, chemical factories,paper mills etc. For example, in a paper mill for controlling the thickness of the paper, sensors are usedwhich regularly monitor the thickness of the paper and sends its value to the controller which then computesthe error and sends these corrected values to the actuators which in turn corrects these errors based on thisfeedback. This complete process is expected to take place in real time. There are several similar exampleswhere the performance of the communication system plays a key role.

Ethernet IEEE 802.3 is not suitable for the hard real time communication systems as it is non-deterministicin real time. However, Ethernet based communication protocols have been used in automation industriesbecause of lower cost, easier wiring and maintenance, and availability of large number of hardware thatworks with Ethernet. Ethernet with software or hardware modifications or both can give better performanceand hence it is used commonly in many of the protocols like PROFINET, Ethernet POWERLINK, SERCOSIII, Ethernet TCP/IP, INTERBUS, MODBUS TCP, EtherCAT and others [5].

This report concentrates mainly on EtherCAT as the hard real time communication protocol whose perfor-mance is under test. But the framework may be applicable to many of the Ethernet based industrial communi-cation protocols as the framework is designed to be independent of the underlying communication protocol.This report also describes the design methodology for the framework based on the factors that are consideredto be critical in defining the performance of the hard real time systems like jitter, cycle time, latency, timesynchronization, payload, fault tolerance [5]. At the time of this project there is no tool known which doesthis kind of automated testing.

EtherCAT protocol follows the master - slave principle. The master is implemented on a CPU board withEthernet controller and running a real time operating system like Windows CE 6.0 in our case. The mastersoftware is developed in house [4]. The slave requires special controller chips implemented in FPGA or ASICwhich "processes the data on the fly". In the EtherCAT technology the communication is done only in thehardware and hence the performance is increased. The increased application of EtherCAT in the industry andease of availability of EtherCAT based devices in the market makes it very suitable for this thesis.

2 Purpose of documentThe purpose of this report is to explain the work carried out as a part of the thesis project. This documentalso gives a picture of the end to end testing. It specifies all the different components in the test system, thefunctionality and their interaction with the developed program.

3 MotivationThere are several hard real-time communication protocols used in the Industrial automation systems. Eventhough these hard real-time communication protocols are different, a set of common features can be testedand compared. Also, manually testing the performance of each protocol is time consuming because it needsconsiderable effort from the developer to understand the protocol and design test cases for the protocol. Asthere are many test cases which could be applied to several different real-time communication protocols,finding a way to reuse and automate these test cases can reduce the effort needed for repeatedly implementingthem.

The project is a part of iFEST (industrial Framework for Embedded Systems Tools)[6] which aims atspecifying and developing a tool integration framework for HW/SW co-design of heterogeneous and multi-core embedded systems.

The aim of this thesis project is to make an automated test framework for hard real-time communicationprotocols. The test framework should be very flexible so it can be applied to several different communicationprotocols. Making a requirement for the framework is the first part of the project. The second part will be

1

Page 11: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

3 MOTIVATION

definition of the framework and architecture design including both hardware and software modules. Laterthe implementation of the framework and pilot case study with EtherCAT is discussed. The future work isdiscussed in detail which involves managing this test framework using other test management tools.

The important features of the various Ethernet based Real -Time communication protocols are listed be-low:

Table 1: Comparison of different real time communication networksImportant features ofthe real-time communi-cation protocols

EtherCAT Ethernet Power-link

PROFINETIRT

SERCOS III

Minimum cycletime[7]

30µs 200µs 250µs 31.25µs (62.5µs,125µs, 250µs,500ms, ...)

Amount of Real Timedata per cycle

4 GB address space 1500 byte - OHper node

NA 4x1500 byte input,4x1500 byte output

Topology Line, Star, Tree, Ring Hub structurerecommended,(Line, Star)

Ring orLine (otherpossibilities)

Ring or Line

Jitter <1µs <1µs <1µs <1µsTime synchronization 1µs (20ns with dis-

tributed clocks)1µs 1µs 1µs

Network speed 100 Mbps 100 Mbps and 1Gbps

100 Mbps 100 Mpbs

Fault tolerance (whathappens if one or morenodes fail)

If line, risk of losing thedown-stream nodes. Ifring, one fault can betolerated. If open modesegments can be madeindependent.

If hub structureindividual nodefaults should notaffect the others.Central hub is asingle point offailure.

Ring Ring

2

Page 12: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

4 REQUIREMENTS

4 Requirements4.1 Requirements on test specification

After a study on requirements[8] of several hard real-time systems within the field of Industrial automation, anumber of critical requirements have been selected to be a part of the test framework. Below is a short list ofthe requirements which needs to be tested in the framework:

1. Deviation of cycle time: It is the difference in the cycle time specified by the manufacturer and themeasured cycle time. Cycle time is a very important criterion of a real time communication system becausealmost all the real-time communication protocols are running cyclically. In each cycle, the master of thereal-time system sends out instruction to slaves and then gathers data from these slaves.

2. Jitter of cycle time: It is the difference in the maximum and minimum cycle time measured at thesame nodes.

3. External network latency: The time taken for communication between one node to another. Ex:Master to Slave, Slave to Slave, Slave to Master. Unlike internal network latency, here we do not separate theprocessing time of the master and slave nodes from the measured value.

4. Jitter of the external network latency: Is the difference measured in maximum and minimum latency.5. Internal network fault tolerance: It is the ability of the network to operate normally even after a node

is affected due to a fault.6. Slave node time synchronization: The degree of accuracy to which each slave node is synchronized.

4.2 Requirements on test framework

To execute the measurement and ensure the quality of testing, a number of requirements should be made onthe test framework.

1. Digital input and output modules: these modules can be used to listen to signals from the targetsystem and generate signals to the target system. We tested using the EtherCAT slave devices available fromBeckhoff Automation [9].

2. Accuracy of latency, cycle time, node synchronization: the accuracy of these testing items shouldbe within 1 microsecond [10] [11] .

3. Automated executions: as the test framework is automated, the test script should be interpreted andexecuted automatically.

4. Test report generation: after testing the framework, the test framework must create a test report whichcontains the testing results.

4.3 General structure of Ethernet based Real Time communication systems

In general, a hard real time communication system uses a master-slave arrangement; the master is usually ahardware module running a real time operating system like WinCE, VxWorks, and Linux etc. The mastercontroller is connected to the slave nodes which are the Industrial I/O nodes that are used to control thesensors and actuators. The structure of a very simple EtherCAT communication system is shown in theFigure 1 below.

3

Page 13: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

4 REQUIREMENTS

Figure 1: Structure of real time communication systems

In our tests we use the EtherCAT devices from Beckhoff Automation [9] as the input and output slavenodes.

4

Page 14: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

5 Design of the test frameworkAs the goal of the test framework is to reduce the human effort for testing, the test process in the frameworkshould be automated. The framework will follow the test description and finish the testing according to testdescription files. The test case script will be automatically generated and managed by other tools which arebeyond the scope of this thesis project. For this test framework, the test script is the input of system and testresult will be generated as output.

Figure 2: Test framework blocks

In this chapter, few designs of the test framework will be discussed first and then the most suitable designis selected. Finally, the design for different components will be illustrated.

5.1 Definition of the test framework architecture

The automated test framework has two main components one is a TestManager and other is a MasterCon-troller. Normally, the communication system under test is an independent system. We also need anotherstandalone system with suitable measuring instrument or method that can supervise the testing procedureand generate and acquire signals. The MasterController implements the functions to be tested, while theTestManager is responsible for creating related scenarios. In order to create testing environment, the Test-Manager should know which function the MasterController is executing, so the TestManager could controlthe behaviour of the MasterController.

The TestManager is a computer with following features:1. Contains a hardware component for measuring and generating signals/pulses, in our report we call it

the I/O controller.2. Reads the test script and create scenarios according to the test script.3. Communicates with master node application for instant sending of instructions and collecting data.4. Keeps a log of all the events.5. Runs on a standard OS platform.6. Integrates and processes the data from different sources (Master node application, I/O device, Test

script)7. Stores the test results in a file or a database so that these results can be used for further automation and

report generation.The MasterController is an application installed on master of the target communication system. It is

responsible for receiving instructions from the TestManager, executing them and then sending feedback tothe TestManager.

5.2 Architecture Design

In this section, the various possible implementations of test framework are discussed:

5

Page 15: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

5.2.1 Globally synchronized clock with PTP

In order to test the latency of the communication system, a straight forward approach is to have a globallysynchronized clock within the framework. In this approach the latency from the Master Controller to a slavecan be measured easily. The structure of this approach is shown in the figure 4. For example, the MasterController can order one digital output slave to generate a signal change. With a global clock, the time whenMaster Controller sends out the instruction and the time I/O controller receives a signal can be recorded sep-arately on MasterController and TestManager respectively. Then the latency value is the difference betweenthe timestamps at MasterController and TestManager. A simple illustration of this method is shown below3.

Figure 3: Measuring latency using a Global clock

All the timers above are PTP synchronized. Timer Ref is the reference clock which records the timing assoon as master controller sends out the data. Timer 1, Timer 2 ... Timer N are the timers that are connected toslave nodes, the timing is recorded in the I/O Controller based on the time stamp on the timers as soon as thatparticular slave node receives a signal from the Master controller. The latency at a particular node would bethe difference between the timings of the reference time and the respective slave time. In this case the latencyat node 1 is 10:01 - 10:00 = 0.01s. However, in case of real time communication protocols like EtherCAT thistime difference is in sub-microseconds level.

Precision time protocol (PTP) IEEE-1588 is time synchronization protocol which can offer sub-microsecondaccuracy in computer systems. We can use UDP protocol for data transmission in this protocol. UDP wouldbe preferred in the test framework as the requirement for the accuracy of test result is microsecond level. Thestructure of this framework is shown in figure 4. However, having a globally synchronized clock introducesseveral problems, like:

1. Additional hardware for synchronization. In order to achieve sub-microsecond accuracy, additionalhardware is needed for each component within the synchronized system.

2. Product Availability. There are not so many products which support IEEE 1588 in the market at the

6

Page 16: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

moment.3. Availability of Hardware interfaces. Interfacing the PTP device to MasterController which is an

industrial pc could be a problem. MasterController board in our case does not provide interfaces like PCI,PCI-E for the additional PTP hardware.

4. Additional Jitter. The Operating System software layers may introduce jitter and latency making theresult less accurate because the TestManager needs to read the I/O controller data.

A simple way to understand this is as seen in the figure 4 below, here the Master Controller is sending outthe data to the slave nodes.

Figure 4: Global synchronized clock with PTP

5.2.2 Round Trip Latency Measurement

The second approach for testing latency is to measure the round trip time. The basic idea is to just measurethe latency from the time an input is given to the target system and time when an output is received oncorresponding channel. What the TestManager needs to do is to start the counter when a signal is generatedby the I/O controller and stop counter when it receives a signal change at the corresponding slave. Thestructure of this solution is shown in the figure 5.

The advantage of this method is that as timings are measured on a single device by using hardware timer,the accuracy of results is very high. Finding a device with digital counter is not a big problem as digitalcounters are very common in the market. Also, no additional hardware is needed on the MasterControllerside and the functionality of each component becomes clear by using this strategy.

7

Page 17: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

The disadvantage of this approach is that since the internal latency measured is the average time of inputand output, it is not the absolute time of input or output.

Figure 5: Round Trip Latency Measurement

5.2.3 Absolute Latency Measurement

The last design for the structure of the framework is that the signal is also measured on the Master of thecommunication system. The strategy is based on an assumption that the Master device has the output func-tionality. The latency from the MasterController to an output slave can be measured in this way. Initially theMasterController instructs the output slave to generate a signal change, for which the corresponding outputslave responds by generating a signal on its own output port. Then the digital counter can be used to mea-sure the duration of these two signals i.e. signals from output port of MasterController and the output slaverespectively.

The merit of this strategy is that the absolute latency could be tested as the signals are probed at eachdevice itself. But at the same time, the Master of the target system needs to have an output functionalitywhich is not quite common. The structure of Absolute latency measurement is shown in Figure 6.

After careful consideration the second structure (5.2.2) of the test framework is chosen to be implemented.As the aim of the framework is, a design to be applicable to several different communication protocols, toomany requirements on the MasterController should be avoided.

Summarizing it all, the first approach (5.2.1) requires additional hardware for synchronization and unpre-dictable software delay, and the third design (5.2.3) needs the MasterController to have I/O functionality, sothey are not suitable to the automated test framework.

8

Page 18: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

Figure 6: Absolute Latency Measurement

5.3 Command

A list of common actions of the MasterController is defined and each action is called a Command. Thereare a number of reasons for defining these Commands. The first reason is for testing the performance of thetarget system the MasterController needs to be able to finish a set of actions, for example, generate a signalchange at a digital output slave, listen to a signal change at a digital input slave, listen to a signal changeat a input node and generate a signal at a output slave. Secondly, when the TestManager is controlling theMasterController, the TestManager needs to know which action the MasterController is capable of. The finalreason being, using these Commands makes the system design simpler. For each Command the correspondingfunction can be designed and developed in MasterController.

As the test framework aims to be applied to several different communication systems, defining theseCommands makes the MasterController portable to different protocols just by implementing these Commandson it. The TestManager will remain the same even though the system under test is different.

1. The command for initialization. Normally the target communication system has several different states.For example, EtherCAT stack has five different states. But only when the device is in Operational mode, itis ready to perform the function it has been assigned (e.g. an output slave is able to generate signal). So thesystem under test must be initialized before responding to any other Command. Cycle time of the systemshould be provided to this Command as the system runs cyclically.

2. The command for getting the structure of the target communication system. In order to improve theusability, the Test Framework should be aware of the structure of system under test. So before each Command

9

Page 19: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

is sent to the MasterController, the Test Manager will check the device type to ensure the Command could befinished.

3. The command for generating a digital signal change every cycle at an output device. For this Command,a signal change (from logic 0 to 1 or from logic 1 to 0) will be generated every cycle at output slave node.This Command can be used for testing the cycle time.

4. The command for listening to an input slave and generating a signal change on the correspondentoutput slave. The target system listens to an input channel on a specified node. After receiving a signalchange on that channel generate a signal change to a corresponding output channel on specified output node.The Command could be used for testing the latency.

5. The command for sending output signals at all output slaves with time stamping functionality. In theoperation for this Command, all the output devices with timestamp functionality, the MasterController willorder them to generate signal change according to a common timestamp value.

The full list Commands along with description, MasterController action and parameters can be found inthe appendix A.1.

One common behaviour for these output Commands is that all the output ports will be set to logic 0 afterfinishing these Commands. In this way, the MasterController does not have to remember the status of slavesas it knows all the output ports are in the same default status.

5.4 Types of slaves

For different communication system, there are hundreds of slave devices on the market. For example, Beck-hoff [9] offers more than 50 different devices for EtherCAT systems. In order to represent different devices,several Device Types are defined in the Test Framework according to different functionalities and features.Because the Test Framework just uses basic functions of the communication system, all the devices fall intoone of these categories:

1. Digital input2. Digital output3. Analog input4. Analog output5. Other typesIn the future there is a provision to extend this list by introducing, many other different device types.

Other types of information about slave devices such as time stamping functionality, number of channels arealso collected.

Since it is possible to cover our test requirements just with digital slave nodes, we don’t deal with analogslave nodes here.

5.5 Data transfer

The TCP/IP protocol is used for data transmission between the TestManager and the MasterController. Asthe TCP/IP protocol is supported by most Operating Systems including Windows, Windows CE, Linux, Real-time Linux etc., it is easy to transfer data even when the TestManager and MasterController use differentOperating Systems. In that sense, the test framework could be portable to different Master Controllers if TCPprotocol is supported by that controller. Another benefit for using TCP is that delivery is guaranteed in theprotocol so the program doesn’t need to take care of the data delivery and error checking issues.

The physical connection between the TestManager and the MasterController is Ethernet. Ethernet inter-face is very common for normal computers, so it is reasonable to consider Ethernet as a good candidate forbuilding the connection. Of course, other types of physical media can also be used in the Test Framework aslong as TCP/IP protocol can run on it.

5.5.1 Communication pattern

As the Commands are defined in the previous session, a protocol needs to be introduced for data encodingand decoding and executing Commands. A common communication pattern is designed for these Commands

10

Page 20: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

so that all Commands share the same communication structure. The communication starts after the TCPconnection between the TestManager and the MasterController is established.

5.5.2 Design of Datagram

The layout of the datagram needs to be determined so that the program is capable of writing and readingmessages. The first part of the datagram indicates which type of message it belongs to, as there are severaltypes of message for communication. The messages are divided into five categories:

1. Connecting, disconnecting,2. Error,3. Command,4. Acknowledgement (ACK),5. Finish.The message body is empty if the message is a connection message. For the error message, the message

should specify the type of error. Normal communication messages such as Command, ACK and Finish havemessage ID field to indicate communication sequence. If the message is a Command or Finish message, thenext part after message ID specifies the type of Command. In the Finish message, there is field indicatingwhether the Command has completed successfully or not. The rest of the datagram relates to that particularCommand. The structures for different messages can be found in figure 7.

To make the program on the MasterController more scalable, the MasterController program is divided intotwo parts: the communication part which is responsible for sending and receiving messages and parsing dataand another part that actually implements the Commands. In order to test different protocols, the functionsfor commands need to be realized. The communication part will be identical for all the testing protocols.

5.5.3 Packet design

Every Command originates from the TestManager since the Commands are ordered by the TestManager andexecuted by the MasterController. Firstly, the TestManager sends a Command to the MasterController withdata related to specific Command. When the MasterController receives a Command message, it returns anacknowledgement (ACK) message to the TestManager indicating the Command has been received. Thenthe MasterController continues executing the Command for a certain amount of time. After the executionof Command, the MasterController sends a Finish (FIN) along with the gathered data (depending on theCommands, it could also be empty) to the TestManager.

11

Page 21: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

Figure 7: Datagram Structure

12

Page 22: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

5 DESIGN OF THE TEST FRAMEWORK

Figure 8: Communication pattern

13

Page 23: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

6 The I/O Controller or CounterThe I/O Controller is the device which measures important data in the Test Framework. It is responsiblefor measuring the latency, cycle time of the communication system. The I/O controller should have highresolution digital hardware counter which is able to measure the latency values. In order to achieve sub-microsecond accuracy, the controller should have more than 1MHz frequency. Another functionality the I/OController needs to have is to have the capacity of generating and acquiring signals with industrial voltageswhich varies from 0V to 48V.

National Instrument PCI-6624 Digital Counter will be used as the I/O Controller of the Test Framework.PCI - 6624 has 34 unidirectional PFI lines (Programmable Function Interface) of which 26 are inputs and 8are outputs. This device has 8 hardware counter channels and a 20MHz time base, so the requirement on theaccuracy of the test results is satisfied.

NI Data Acquisition (DAQ) provides the driver for NI PCI-6624. It also contains a library with a numberof basic functionalities such as pulse generation, edge detection, frequency separation and two edges separa-tion. These basic functions can be invoked from the TestManager to execute the testing. For instance, pulsegeneration and two edges separation can be used for measuring the round trip and absolute latency and for thecycle time measurement we can use the pulse width measurement function. The detailed testing procedure isdiscussed in later chapters.

For checking the time synchronisation, I/O controller has to listen to all the channels. For this operation,in our implementation we make the first channel to constantly generate pulse to all other channels whichwill be executing two edges separation. It must be noted that the first channel cannot be used for listeningto the pulses. The pulse generated by the first channel will be considered as the first signal of the two edgeseparation. Then the counter on each listening channel will start counting after receiving the signal and waitfor the second signal. In this way, the timing difference of several input signals can be tested. This operationcan be applied to test internal network latency. But generating a signal on all channels is not necessary. Theonly way to do it is to just use one channel to create the signal and connect it to several devices.

6.1 Function of I/O Controller during different test case execution

6.1.1 Round Trip Latency

There are few different operations defined for the I/O controller.First operation is to select a physical channel which corresponds to the counter on the I/O controller which

is used for measurement. Next we need to send out the signal through one of the Input slave node and start thecounter simultaneously; this input node is connected to the Master Controller which sends out a signal changeon the output slave node as indicated in the command. The counter stops counting as soon as it receives asignal on the output slave node. This measures the round trip latency. Then we approximate the latency tohalf of the measured round trip latency.

14

Page 24: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

Figure 9: Round trip latency measurement using two edge separation method

15

Page 25: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

Figure 10: Two Edge Separation Method

6.1.2 Jitter of latency

The latency values are measured for up to 10 times and the difference between the maximum and the minimumvalues of the latency gives the Jitter of latency.

6.1.3 Cycle time measurement

Cycle time is equivalent to the time duration of the single pulse that appears across the output slave node. TheOutput slave node is made to change its state every cycle, so if it remains high in the current cycle it is setlow in the next cycle. The pulse width measurement program runs on the counter device and it measures theduration for which the pulse remains high which gives the cycle time of the communication system.

16

Page 26: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

Figure 11: Pulse Width Measurement

6.1.4 Jitter of cycle times

The cycle times are measured for up to 10 times and the difference in the maximum and minimum values ofthe jitter gives us the jitter in cycle time.

17

Page 27: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

Figure 12: Pulse Width Measurement Method

6.2 TestManager and I/O Controller

In the TestManager, there are two functions which have to run at the same time. One for controlling theMasterController and another for operating the I/O Controller. These two functions should work together toexecute the test cases as one task selects the Commands on the Master Controller and the other one createsa measurement environment. A mechanism therefore needs to be devised to synchronize these two tasks.With the help of synchronization, it is possible to make implement the combination of different Commandson Master Controller and I/O controller operations.

There are some operations on the I/O controller which needs to be setup before the Commands is executedby the MasterController. For instance, if the TestManager orders the MasterController to generate a digitaloutput signal then a corresponding channel on the I/O controller should be set to listening status before theMasterController executes the output Command. The opposite scenario is when the TestManager instructsthe MasterController to listen to a signal change on one input slave then the listener has to be established onthe MasterController before the I/O controller does any action.

The task for controlling I/O controller is running separately and most of the time this task is waitingfor the event from the TestManager. To execute a specific operation on the I/O controller, the TestManager

18

Page 28: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

6 THE I/O CONTROLLER OR COUNTER

has to first select the operation on the I/O controller, and then the TestManager signals the event which I/Ocontroller is waiting for. After this, whether the operation starts immediately or still needs to wait for theoccurrence of a second event is highly related to the operation itself. In most of the cases, if it is a listeningoperation the I/O controller should start working immediately. But when we are generating a signal on theI/O controller, it should wait for the second event to do the operation because this time the related setup onthe MasterController has to be done first. However, sometimes one of the channels on the I/O controller isused to trigger the counting of other channels and in these cases the output can be done before receiving thesecond event from the TestManager.

After the TestManager receives the finish message from the MasterController, the TestManager couldread data from the I/O controller since finish messages symbolize the operation has been completed by theMasterController. Otherwise some error must have occurred in the Test Framework. Then the I/O controlleris waiting for another event to start next operation. If the TestManager is not making use of the functionalityof the I/O controller, the command can still be executed by the Test Framework for other tasks.

Figure 13: Test Manager and I/O controller

19

Page 29: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

7 SOFTWARE IMPLEMENTATION

7 Software Implementation7.1 The Programming language

Choosing a suitable programming language to implement the basic programming part of the Test Frameworkcould be a problem. As we decided to use TCP/IP protocol as the communication protocol between the Test-Manager and the MasterController and TCP has an implementation named “Winsock” on Windows platformin C language, the language must be able to call these APIs directly. The APIs for the I/O controller fromNational Instruments are in C language as well. C language seems to be good candidate. However, in orderto make the Test Framework more Object-Oriented, C++ is chosen for our program since it also can use Cprograms directly.

7.2 Automated execution

As the testing process is automated, the Test Framework should be able to read test scripts and execute thetesting procedure according to the test script. One of the ways for achieving automated execution is to designa scripting language which is later used to describe the testing process and develop an interpreter to decodethe test script and execute it on the real program. Another approach to implement automated execution isusing existing scripting language and exposing the real C++ program to the scripting language. Then theC++ functions can be invoked directly from the scripting language. Apparently, the first approach would costa lot of effort for developing a new language and implementing parser for it. The goal of the project is todesign a Test Framework, rather than invent a new scripting language for testing. As a result, the secondmethod for using an existing scripting language is chosen as it will reduce the difficulties of developing theTest Framework.

There are a number of different scripting languages available which can be binding with C++ programsuch as Python, Perl, Lua, TCL, and Ruby. Most of these languages support Object-Oriented programmingfeatures directly or indirectly. Python, Perl and Ruby are native Object-Oriented scripting languages whileTCL and Lua realize Object-Oriented in other means. Python is chosen as the scripting language for theframework due to the following two reasons:

1. Development of python is much quicker compared to other scripting languages mentioned above.2. Python has a clearer syntax compared to other scripting languages.SWIG is tool which can automatically generate scripting language interfaces from an interface specifica-

tion. It takes ANSI C/C++ declarations and turns into scripting language interfaces. SWIG supports manydifferent scripting languages such as Python, Perl, Lua, TCL and etc. However, SWIG cannot interface com-plex data type in C++. It needs to write Python C-API code for type conversions when creating interface.What is more is that it has more overheads when generating interface file.

Boost.Python is dedicated to bind the C++ libraries with python. We write simple function to describefunctions and/or class you want to export to Python program and Python can read the library which is gener-ated by boost tool as a python module. The Advantage is that it can deal with complicated type conversionand is also good for binding existed C++ libraries.

Because of the above reasons Boost Python will be used for binding our C++ program with Python.

7.3 Test procedure

In the Test Framework, hardware connections such as Ethernet connection between TM and MC, electricalcircuits should be setup appropriately. After that, these are the steps that have to be followed:

1. TestManager starts and initializes the NI counter device and allocates related resource.2. The MasterController begins to run and waits for the TestManager to connect to it.3. With the IP address of the MasterController, the TestManager builds up the communication channel

between the TestManager and the MasterController.4. The TestManager should send Initialization Command to the MasterController so the target system can

enter into the operational state.5. The TestManager should detect the structure of the system under test so it can check the device type

before sending out the Command to the MasterController.

20

Page 30: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

7 SOFTWARE IMPLEMENTATION

6. The Test Framework will then be ready to execute tests on latency, jitter, cycle time, fault tolerance andtime synchronization.

7. The TestManager could stop the target communication system. Then the TestManager can send Initial-ization Command to the MasterController with different cycle time values and the test flow should go to step4. Otherwise the whole test process is over.

Figure 14: Test Procedure

21

Page 31: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

8 Test Case Design8.1 Test case: External network latency

Requirements for the system under test: one digital input slave node and one digital output slave node.Test description: The round trip strategy is used for testing external network latency of the target system.

When the input slave receives a signal change from PCI-6624 counter, the corresponding output device willgenerate a signal change. The command Listen2InputSend2OutputD is used to build the connection betweenthe input slave and the output slave on Master Controller. The command Listen2InputSend2OutputD willsetup a listener on Master Controller which listens to signal change on the specified input device and thentriggers a signal change on a particular output slave.

The input channel on the input slave, the input slave address, the output channel on the output slave andthe output slave address should be provided to command. Two counters channels are needed to finish thenetwork latency test. The PCI-6624 counter on Test Manager will use one counter channel to generate a pulseto the target system and trigger the second counter to start counting. When the second counter receives asignal from the output slave, it stops counting and the counter value is the round trip latency of the targetsystem.

Every time the latency is calculated, it will be compared with required value of external network latencyfrom the specifications.

Figure 15: External network latency sequence

8.2 Test case: Jitter for external network latency

Requirements for the system under test: one digital input slave node and one digital output slave node.Test description: The above method for calculating the external network latency will be used to test jitter

of external network latency as well. The latency values are computed ten times and the difference betweenthe maximum and the minimum value of these latency values is the jitter of external network latency for thegive input and output slave nodes.

8.3 Test case: Startup time

Requirements for the system under test: cycle time of Master Controller.

22

Page 32: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

Test description: Test Manager needs to send the initialization command to Master Controller. When theTest Manager receives the ACK message from the Master Controller it starts the software timer and when theTest Manager receives the finish message, it will stop the timer.

Figure 16: Startup Time Sequence

8.4 Test Case: Deviation of cycle time

Requirements for the system under test: One digital output slave node and PCI -6624 Counter.Test Description:The test framework should have the ability to test the difference in the cycle time of

target system and the cycle time from the specifications.The test manager should generate a signal change every cycle by using the command CMDSendOutput-

Cycle. The output channel of the output slave, the output slave address and the duration for running thecommand should be provided to command. The PCI-6624 counter on Test Manager will calculate the pulsewidth for the signal. The pulse width is the cycle time of the target system as the signal will keep logic 1 forone cycle and change to logic 0 at the next cycle. The cycle time is taken and compared with the specificationof the communication system under test to get the deviation of the cycle time.

23

Page 33: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

Figure 17: Deviation of Cycle time sequence

8.5 Test Case: Jitter of cycle time

Requirements for the system under test: One digital output slave node and PCI -6624 counter.Test Description:The test manager should generate signal change every cycle by using the command CMDSendOutput-

Cycle. The output channel of the output slave, the output slave address and the duration for running thecommand should be provided to command. The process for testing the cycle time will repeat for 10 timesand ten cycle time values will be gathered. The difference between the maximum and minimum of the cycletimes is taken system under test to get the deviation of the cycle time.

Figure 18: Jitter of cycle time sequence

8.6 Test Case: Internal network fault tolerance

Requirements for the system under test:

24

Page 34: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

The IO device should be able to power off the specified slave node, at least 3 slave nodes are needed totest this.

Test description:The test manager signals the EtherCAT output device which is connected to DI810 unit of the AC800M

controller. The controller is programmed to operate in such a way that, whenever DI810 receives the input itsends the DO810 output unit to switch off the outputs to particular nodes which can be pre-configured. Thuswe test the fault tolerance by testing the effect of bringing down a node on the communication system andevaluating its performance,

Figure 19: Fault Tolerance Testing

Figure 20: Fault tolerance testing sequence

EtherCAT Input:

25

Page 35: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

The EtherCAT input device EL2202 is used to activate the controller into the Fault Tolerance test casemode. The EL2202 module is a Digital output device from Beckhoff which is connected to the DI810 unit ofthe controller.

EtherCAT power supply:The power supply of the EtherCAT slave nodes are controlled by the DO810 unit of the controller. When-

ever there is an input received from the EL2202, the DO810 switches off the power supply for the pre-determined node (Slave 2 in our test case).

Run the EtherCAT stack normally and note down if there is a difference in the communication network.This test case was successfully executed and we could prove the internal network fault tolerance of the

EtherCAT system.

8.7 Test Case: Slave node time synchronization

Requirements for the system under test: Digital output slave nodes with time stamping ability, PCI-6624counter.

Test description:The test framework should have the ability to test the time synchronization accuracy target systems. The

TestManager should first initialize the I/O Controller by setting all the listening channels to Two Edges Sep-arating task. Then one output channel will generate a pulse to trigger all listening channels to start counting.In this way, all the counters are guaranteed to start at the same time.

After that the TestManager sends the Command SendAllTSOutputD to the MasterController. For theCommand SendAllTSOutputD, digital output slave nodes with time stamp will generate signals accordingto a same specified time stamp. When the counter channel receives a signal from the system under test,the counter will stop counting. The difference of the counter values is the difference of the local clocks ondifferent output slave. The accuracy of time synchronization is tested by applying above procedure.

Figure 21: Slave node time synchronization function

26

Page 36: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

8 TEST CASE DESIGN

Figure 22: Slave node time synchronization sequence

27

Page 37: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

9 Pilot test case on EtherCAT9.1 Introduction to EtherCAT

EtherCAT is hard real-time communication technology based on master and slave architecture. The commu-nication part is using Ethernet but the datagram in EtherCAT system is modified in order to apply EtherCATprotocol. The master device is an industrial PC with Windows CE real time operating system running on it.The slave modules are from Beckhoff Automation which includes EL1252 (2 channel digital input terminalwith Time-Stamp), EL2202 (2 channel digital output terminal). EtherCAT master software application is de-veloped by ABB in-house. The master software provides access to read data from the slaves and write datato the slaves [4]. The slave nodes time synchronization is also implemented on the master software.

EtherCAT slaves have five different states: Init, Pre-Operational (Pre-Op), Safe-Operational (Safe-Op),Operational (Op) and Boot. Initially, after the device is powered-on, all the slaves will be in the state ofInit. Then the state of the whole system should be set to Pre-Op. After that the state of the system should betransferred from Pre-Op to Safe-Op. Finally, the system must enter Op state so the whole system is functional.In this process, the cycle time of the system is setup and other initialization operations are finished. Basically,the operations above have to be completed for the Command Initialization.

Figure 23: EtherCAT States

Process Data Objects (PDOs) originally defined in CANopen (Controller Area Network) are used inEtherCAT systems. PDOs which contain control and status data are highly related to the functions on theslaves. For example, a PDO referring to a port on a digital output slave can be used control the status of theport, whether it is in low or high state.

The EtherCAT master software provides read and write methods to get access to PDOs on the EtherCATsystem.

For reading PDOs, Process Data Listener which runs every cycle can be used to monitor PDO. At first,the Data Listener must be created. Then the PDOs that need to be listened to should be subscribed to the DataListener. Then the PDOs could be checked every cycle as the Data Listener executes cyclically.

To write the PDOs for controlling data, the master software offers a post method for PDOs. The PDOswhich are posted by the master stack will be sent to slaves.

28

Page 38: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

9.2 Implementation of Commands

This part of the report illustrates how the Commands are implemented by using the EtherCAT master software.The implementations for Command SetupInputListenerD and SendOutput2NodeD are quite straightforwardby applying the methods given by master software.

To realize the Command Listen2InputSend2OutputD, a Data Listener has to be established. The DataListener is separate from the main task for handling the Commands. The PDO corresponding to the specifiedport on the input slave should be subscribed to the Data Listener. After subscribing the PDO to the DataListener, the main task will wait for an event from the Data Listener which indicates the target signal has beenreceived. As the Data Listener runs cyclically, the changes on the input channels will be detected at the nextcycle. As soon as the Data Listener recognizes the change of PDO, the Data Listener will signal the eventwhich the main task is waiting for. The main task will post the PDO for the related output port as soon aspossible.

Figure 24: Listen2InputSend2Output command sequence

For the Command SendOutputCycle, the same approach of Command Listen2InputSend2OutputD is ap-plied to realize this Command. After the Data Listener is constructed, no PDO will be assigned to this listener.So instead of listening to any PDO, the Data Listener is just used to signal the event for the main MasterCon-troller task every cycle. The main task will continuously wait for synchronization event. Every time when themain task receives the event, the main task will change the PDO for the digital output slave which is differentfrom previous one.

29

Page 39: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

Figure 25: SendOutputCycle command sequence

9.3 Test Results

So far, the Test Framework is ready to experiment with EtherCAT as the underlying real time communicationprotocol. In this chapter, the Test Framework will conduct several tests on EtherCAT system and measureslatency and cycle time. In order to verify the quality of test result of the Test Framework an Oscilloscope willbe used to measure signals in different test cases and comparison of the test results from the oscilloscope andthe Test Framework should be made to check the correctness and accuracy of the Test Framework. For theEtherCAT system under test the cycle time of the bus is set to 900 microseconds.

9.3.1 Test cycle time

The test framework is setup as described in test case for testing the cycle time. One of the counter channelsis connected with a digital output slave. As the Command SendOutputCycle is sent to the Test Manager, thedigital output port will change its state every cycle. The NI counter will measure the pulse width of the outputport. In the output port, an oscilloscope probe will be also used to trace the signal changes.

30

Page 40: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

Figure 26: Oscilloscope measurement of cycle time

As it is shown in the picture, the pulse width of the signal is roughly 896 us which means the EtherCATsystem is actually on the frequency as it is supposed to operate. The cycle time read out from the Test Manageris 906000ns. Even though the results from the oscilloscope and the Test Manager are not exactly the same, thereason might be that it is very difficult for human to get the exact value from the oscilloscope. We prefer thevalue obtained from the digital counter hardware running on a 20MHz clock as it is should be more accurate.

31

Page 41: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

9.3.2 Latency

Figure 27: Oscilloscope measurement of latency

The test case for latency is applied for measuring the latency of the EtherCAT system. In this test case, onedigital output slave EL2202 and one digital input slave EL1252 will be used. The Master Controller willsetup a Data Listener for the input slave and once the signal change is detected by the Data Listener at Inputslave, the EtherCAT master software will send the PDO for output signal to EL2202. Two counter channelson the NI counter board will be used, as one generates the signal to EL1252 and starts the second counter andthe other measures the latency value by counting the duration between the first signal to EL1252 and secondsignal from EL2202. Two channels seen in the figure 27 corresponds to an Input Signal and the output signalin this test.

The latency from oscilloscope is 2.55 ms whereas the value read at the TestManager is 2.565ms. Thelatency value is larger than what is expected. The delay from input slave to output slave should be lessthan 2 cycle time (2 x 900ns = 1.8ms in this case) as in the first cycle the signal change is captured by theMaster Controller and the output signal will be generated at the second cycle. The reason is because of thenature of EtherCAT. In EtherCAT system every cycle the master of the network sends out an EtherCAT packetcontaining the controlling instruction and collecting data from slaves in the system.

1. The master receives the signal change on the input slave when the packet for the first cycle comes backto the master.

2. The master needs to wait for the next cycle where the packet for changing the output signal could besent out.

However, the latency is significantly larger than the value we predicted. Even with different cycle timevalues of the system, the latency values measured by our framework is always longer than 2 cycle time. Thereason for this was not being established during the thesis work.

32

Page 42: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

9 PILOT TEST CASE ON ETHERCAT

Figure 28: Inaccuracy in measurement

As we have seen so far, the test result from the test framework is accurate when the oscilloscope is usedas a comparison for it.

33

Page 43: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

11 FUTURE WORK

10 ConclusionIn this report, we have described the full design of the automated test framework for hard real-time systemsincluding software and hardware modules to realize it. The test framework has the possibility to be extendedto other Master-Slave based real-time communication systems as the requirements on the test framework aregathered based on several different real-time communication protocols. However, in order to test a specificsystem, extra implementation for Commands on the Master Controller application is needed.

Abstractions for the operations in each parts of the framework are made to modularize the design of ourframework. A list of Commands has been made to define the common behaviours of the communicationsystems. These Commands have the same communication scheme between the TestManager and the Master-Controller. In the later stages if more Commands need to be added to the test framework, the communicationpattern should be followed. The operations for the I/O controller are determined as well.

Pilot test case on EtherCAT master software has been carried out to verify the correctness of the testframework. As we have seen in chapter 6, critical characters such as cycle time, latency of the EtherCATsystem were successfully measured.

Additionally, the test framework also fulfilled the requirement of automatically executing the test scriptsby interfacing the functions for testing to Python. In the later stages the test cases will be managed using NITestStand and the Python interface can be eliminated.

11 Future workThe test framework is able to test basic requirements of a real-time communication system, but there are stillmore related work needs to be done. Since in the current implementation only digital I/O devices are used formeasuring, other types of devices such as analog I/O devices could be included in the framework.

One of the drawbacks of this framework is that the absolute latency is not calculated as the result of usingthe round trip approach. However, if the controller of the target system has the output functionality, then ourframework could easy adapted to measure the absolute delay from the master to a slave or from a slave to themaster device. Slightly changing the behaviour of the Command SetupInputListenD and SendOutput2NodeDcan make the framework support measurement of absolute latency value. For the Command SetupInputLis-tenD, when the input listener detected the PDO change, the master device should generate an output signalon its output interface. Considering Command SendOutput2NodeD, the Master Controller should generatean output signal on its output interface before instructing the corresponding slave to generate a signal. Thenthe I/O controller should be able to measure the latency with two edges separation function.

Payload is another sensitive issue in the real-time systems. But measuring the payload in the real-timesystems is extremely difficult as it is highly related to the specific protocol underlying. In this test framework,we haven’t managed to conduct tests regarding to payload and bandwidth issues because relating the payloadwith the performance of the real-time system could be very complicate. In the future, new methods can bedeveloped to test this issue.

34

Page 44: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

A AppendixA.1 Design for command in the framework

1. Initialization

Table 2: InitializationDescription Command the Master Node to finish initialization process (e.g. put all devices in

Operational mode).Parameter cycle timeFeedback Ack, FinishTM action When this command it sent out, the TM starts a timer. When received a Finish,

stops the timer.

2. GetStructure

Table 3: GetStructureDescription Get the structure of our target communication system.ParameterFeedback Ack, Finish and Number of slaves in the target system, the functionality for each

slave (digital input or output device, with time stamp or not, number of I/Ochannels).

TM action Compare the structure specified in the test script

3. SetupInputListenerD

Table 4: SetupInputListenerDDescription Setup a digital signal listener on the channel of a specified input node and delete the

listener after fixed duration.Parameter The input node ID and the channel number it wants to listen to. Duration of the

listener.Feedback Ack. Finish and timestamp if the input device has the time stamping functionality.TM action Generate a signal change from I/O controller to the slave node

4. SendOutput2NodeD

Table 5: SendOutput2NodeDDescription Generate a digital signal on a channel at the specified output node and reset the

signal state to original state after a fixed duration.Parameter The output node ID and the channel number on which it wants to generate a signal

change and the duration to change it back.Feedback Ack, Finish and timestamp for Master node controller.TM action Read a signal change from the slave node using I/O controller.

35

Page 45: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

5. SetupAllInputListenerD

Table 6: SetupAllInputListenerDDescription Setup listener on all general input channels for signal changes and delete these

listeners after fixed duration.Parameter Duration of the listenersFeedback Ack. Finish and for the inputs whether they has received signal changes or not.TM action Generate a signal change from I/O controller to the slave nodes at the same time.

6. SendAllOutputD

Table 7: SendAllOutputDDescription Generate signal change on all output general channels on all output nodes and reset

the signal states to the original states after a fixed duration. If the target systemcontains digital outputs with timestamp function, send out signals at the same timeaccording to the time stamp.

Parameter Duration of Outputs.Feedback Ack. Finish.TM action Read signal changes from the slave node on I/O controller.

7. SendAllTSOutputD

Table 8: SendAllTSOutputDDescription As the target system contains digital outputs with timestamp function, instruct the

nodes to send out signals at the same time according to the time stamp.Parameter Duration of Outputs.Feedback Ack. Finish.TM action Read signal changes from the slave node on I/O controller.

8. Listen2InputSend2OutputD

Table 9: Listen2InputSend2OutputDDescription The target system listens to an input channel on a specified node. After receiving a

signal change on that channel, generate a signal change to a corresponding outputchannel on specified output node.

Parameter The port number of input device, input device ID, The port number of output deviceand the output device ID.

Feedback Ack. Finish.TM action Generate the signal and start the timer on I/O controller. Stop the timer when the

I/O controller gets a signal from the target system.

36

Page 46: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

9. GroupOutputD

Table 10: GroupOutputDDescription Group a number of channels on different digital output nodeParameter Number of node you want to group and a list of node IDs and a channel on each

node.Feedback Ack. Finish. Group ID.TM action

*As the test framework mostly focuses on timing, the command will only take one channel of each deviceto the group.

10. GroupInputD

Table 11: GroupInputDDescription Group a number of channels on different digital input node.Parameter Number of node you want to group and a list of node IDs and channel(s) on each

node.Feedback Ack. Finish. Group IDTM action

*As the test framework mostly focuses on timing, the command will only take one channel of each deviceto the group.

11. SendOutputGroupD

Table 12: SendOutputGroupDDescription Generate digital signals on channels at the specified output nodes and reset the

signal states to original states after a fixed duration on all the output nodes.Parameter The output node IDs and the channel number it wants to generate signal change and

the duration to change these signal states back.Feedback Ack. Finish.TM action Read signal changes from the slave nodes on I/O controller.

12. Listen2InputGroupD

Table 13: Listen2InputGroupDDescription Bind digital signal listeners on the channels of specified input nodes and unbind

these listeners after fixed duration.Parameter The input node IDs and the channel numbers it wants to listen to. Duration of

binding of these listeners.Feedback Ack. Finish and timestamps if the input devices have the time stamping

functionalityTM action Generate a signal change from I/O controller to the slave node

37

Page 47: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

13. DismissGroup

Table 14: DismissGroupDescription Dismiss the group which is created by GroupOutputD or GroupInputD and free the

correspondent resource.Parameter The group ID.Feedback Ack. FinishTM action

14. ConnectIntputD2GOutputD

Table 15: ConnectIntputD2GOutputDDescription The target system listens to an input channel. When receiving a signal from the

channel, generate a signal change to a corresponding output group which is createdby GroupInputD.

Parameter The channel number of input device, input device ID and the port number of outputgroup ID.

Feedback Ack. Finish. If the input and output devices have time stamp function, the resultshould also contain these timestamps.

TM action Generate the signal and start the timers on I/O controller. Stop the timer when theI/O controller gets a signal from one channel of the target system.

15. SendOutputCycle

Table 16: SendOutputCycleDescription Send out a signal change every cycle.Parameter The port number of output device and the output device ID. Duration of sending out

the signal changes.Feedback Ack. Finish.TM action Start a timer when get the signal change. Stop the timer when the I/O controller gets

a signal from the target system read the timer value. Then start the timer and repeatthe process again.

16. CloseUp

Table 17: CloseUpDescription Command the Master Node to enter Init mode (e.g. put all devices in Init mode).ParameterFeedback Ack. FinishTM action

38

Page 48: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

A.2 Instructions for compiling the Test Manager with Boost.Python library

The C++ program for the Test Manager is actually compiled to dynamic library format and exposed to Pythonso the C++ program can be invoked for Python script. Python needs to be installed on the computer

Install Boost library:Download Boost library packet from its official website www.boost.orgUnzip the Boost library under C:\ drive Execute bootstrap.bat under command line and bjam.exe will be

created which is later used to compile the boost library.The following parts need to be added to the file C:/ boost_1_46_0/tools/build/v2/user-config.jam###########################################################using python: 3.2 # Version: C://Python32//python.exe # Python Path: C://Python32//Include # include path(s) -they may be not really needed here: C://Python32//libs # lib path(s) - they may be not really needed here: <python-debugging>off <define>BOOST_ALL_NO_LIB=1;using python: 3.2 # Version: C://Python32//python.exe # Python Path: C://Python32//Include # include path(s) -they may be not really needed here: C://Python32//libs # lib path(s) - they may be not really needed here: <python-debugging>on <define>BOOST_ALL_NO_LIB=1;###########################################################Then compile the boost library with bjamC:\boost_1_46_1> bjam.exe –link= shared runtime-link=shared -with-python stage releaseThe compiling process could take a few minutes of even longer.Tutorial exposing C++ classes to python can be found in the link below:http://www.boost.org/doc/libs/1_46_1/libs/python/doc/tutorial/doc/html/

python/exposing.htmlCompiling with Boost library in Visual StudioIn order to compile with Boost library, several properties in project setting need to be changed in project

properties in Visual Studio.1. Change the project type to Dynamic Library in Configuration Properties -> General -> Configuration

type.2. In C/C++, add C:\Python32\include;"C:\Boost\include\boost-1_46.1 to Additional Include Directories.3. Add BOOST_THREAD_DYN_LINK to Preprocessor Definitions.4. C:\Boost\lib;C:\Python32\libs need to be added to Additional Library Directories at the Linker -

>general5. Change the output File to $(OutDir)\$(ProjectName).pyd6. Add python32.lib to the Additional Dependencies in Linker ->input.7. Then recompile to whole project8. Copy the boost_python-vc90-mt-gd-1_46_1.dll from C:\boost\boost_1_46_1\stage\lib to directory

where is xxx.pyd file is created, typically under the Debug folder of the project.In the folder where the TestManager.pyd is generated, open python software in CMD. Then import the

xxx.pyd and the C++ class is ready to be called in Python.

A.3 Driver for NI-PCI 6624

NI DAQmx is software which contains driver and APIs for using NI-PCI6624. After installing DAQmx,the PCI-6624 is ready to use. However, there are some properties have to be setup in C++ project so theC++program can call the APIs for PCO-6624:

39

Page 49: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

1. $(ProgramFiles)\National Instruments\Shared\ExternalCompilerSupport\C\include has to be added toAdditional Include Directories in C/C++ page at project properties.

2. $(ProgramFiles)\National Instruments\Shared\ExternalCompilerSupport\C\lib32\msvcs need to be addedto Additional Library Directories at the Linker ->general

3. Add odbc32.lib,odbccp32.lib,nidaqmx.lib to additional dependencies at Linker -> InputWhen the NI DAQmx is installed, there are examples of C programs and manual of the APIs in C ap-

pended in the directory.

A.4 Electrical Connections for NI PCI - 6624

A.4.1 Specifications of the Counter:

Table 18: Counter SpecificationsGeneralOperating System/Target Real-Time , Linux , Mac OS ,

WindowsMeasurement Type Quadrature encoder ,

FrequencyIsolation Type Ch-Ch IsolationCounter/TimersCounters 8Number of DMA Channels 3Buffered Operations YesMaximum Range 0 V , 48 VMax Source Frequency 20 MHzMinimum Input Pulse Width 1 usPulse Generation YesResolution 32 bitsTime base Stability 50 ppmLogic Levels TTLI/O Connector 100-pin female 0.050 D-typeTiming/Triggering/SynchronizationTriggering Digital

A.4.2 Accessories of the counter:

The counter has a shielded I/O connector block. The connector provides us access to the Input and outputs of6624. The shielded 100-conductor cable connects the PCI 6624 with 100-pin connectors. The shielded blockand shielded cables together provides a very low-noise signal termination.

The switch setting for counting is shown below in figure 29. [12].

40

Page 50: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

Figure 29: Switch setting for SCB-100

A.4.3 Pin Assignments of NI 6624

In the figure 30 you can find the pin connections for NI-6624 [13]

41

Page 51: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

Figure 30: Connector Pinout of I/O Controller

The eight counters that can be used from the 100 pins from the connector are [13]:

42

Page 52: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

Table 19: Counter Pin ConnectionsChannelNo.

PinNumber

Signal Name Counter ChannelNo.

PinNumber

Signal Name Counter

0 1 PFI 39+ CTR 0 SRC+ 4 51 PFI 23+ CTR 4 SRC+2 PFI 39- CTR 0 SRC- 52 PFI 23- CTR 4 SRC-3 PFI 38+ CTR 0 GATE+ 53 PFI 22+ CTR 4 GATE+4 PFI 38- CTR 0 GATE- 54 PFI 22- CTR 4 GATE-5 PFI 37+ CTR 0 AUX+ 55 PFI 21+ CTR 4 AUX+6 PFI 37- CTR 0 AUX- 56 PFI 21- CTR 4 AUX-7 PFI 36 Vdd CTR 0 Vdd 57 PFI 20 Vdd CTR 4 Vdd8 PFI 36 Vss CTR 0 Vss 58 PFI 20 Vss CTR 4 Vss9 PFI 36 CTR 0 OUT 59 PFI 20 CTR 4 OUT10 PFI 36 Vss CTR 0 Vss 60 PFI 20 Vss CTR 4 Vss

1 11 PFI 35+ CTR 1 SRC+ 5 61 PFI 19+ CTR 5 SRC+12 PFI 35- CTR 1 SRC- 62 PFI 19- CTR 5 SRC-13 PFI 34+ CTR 1 GATE+ 63 PFI 18+ CTR 5 GATE+14 PFI 34- CTR 1 GATE- 64 PFI 18- CTR 5 GATE-15 PFI 33+ CTR 1 AUX+ 65 PFI 17+ CTR 5 AUX+16 PFI 33- CTR 1 AUX- 66 PFI 17- CTR 5 AUX-17 PFI 32 Vdd CTR 1 Vdd 67 PFI 16 Vdd CTR 5 Vdd18 PFI 32 Vss CTR 1 Vss 68 PFI 16 Vss CTR 5 Vss19 PFI 32 CTR 1 OUT 69 PFI 16 CTR 5 OUT20 PFI 32 Vss CTR 1 Vss 70 PFI 16 Vss CTR 5 Vss

2 21 PFI 31+ CTR 2 SRC+ 6 71 PFI 15+ CTR 6 SRC+22 PFI 31- CTR 2 SRC- 72 PFI 15- CTR 6 SRC-23 PFI 30+ CTR 2 GATE+ 73 PFI 14+ CTR 6 GATE+24 PFI 30- CTR 2 GATE- 74 PFI 14- CTR 6 GATE-25 PFI 29+ CTR 2 AUX+ 75 PFI 13+ CTR 6 AUX+26 PFI 29- CTR 2 AUX- 76 PFI 13- CTR 6 AUX-27 PFI 28 Vdd CTR 2 Vdd 77 PFI 12 Vdd CTR 6 Vdd28 PFI 28 Vss CTR 2 Vss 78 PFI 12 Vss CTR 6 Vss29 PFI 28 CTR 2 OUT 79 PFI 12 CTR 6 OUT30 PFI 28 Vss CTR 2 Vss 80 PFI 12 Vss CTR 6 Vss

3 31 PFI 27+ CTR 3 SRC+ 7 81 PFI 11+ CTR 7 SRC+32 PFI 27- CTR 3 SRC- 82 PFI 11- CTR 7 SRC-33 PFI 26+ CTR 3 GATE+ 83 PFI 10+ CTR 7 GATE+34 PFI 26- CTR 3 GATE- 84 PFI 10- CTR 7 GATE-35 PFI 25+ CTR 3 AUX+ 85 PFI 9+ CTR 7 AUX+36 PFI 25- CTR 3 AUX- 86 PFI 9- CTR 7 AUX-37 PFI 24 Vdd CTR 3 Vdd 87 PFI 8 Vdd CTR 7 Vdd38 PFI 24 Vss CTR 3 Vss 88 PFI 8 Vss CTR 7 Vss39 PFI 24 CTR 3 OUT 89 PFI 8 CTR 7 OUT40 PFI 24 Vss CTR 3 Vss 90 PFI 8 Vss CTR 7 Vss

43

Page 53: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

Table 20: Counter Pin Connections cont’dChannelNo.

PinNumber

Signal Name Counter ChannelNo.

PinNumber

Signal Name Counter

41 PFI 0+ 91 PFI 4+ na42 PFI 0- na 92 PFI 4- na43 NC na 93 NC na44 NC na 94 NC na45 NC na 95 NC na46 NC na 96 NC na47 NC na 97 NC na48 NC na 98 NC na49 NC na 99 NC na50 NC na 100 NC na

A.4.4 Circuit connections for round Trip Latency Measurement

The output from the counter 0 is connected to both Beckhoff input device (EL1252) [9] and also the AUX+pin of the counter 1 which serves as the starting pulse of the two edge separation method. The input devicesends the signal to the master controller which then sends this signal to an output device (EL2202) whoseoutput channel is connected to the GATE+ pin of counter 1. This signal is the stopping pulse of the two edgeseparation method.

The NI PCI 6624 has 8 counters, so one of the 8 counters can be used for the detection of starting pulseand one from the remaining 7 counters can be used for receiving pulses from the output slave [13]

Counters that can be used for latency measurement:

Table 21: Counter ConfigurationsMeasurement Ctr0 Ctr1 Ctr2 Ctr3 Ctr4 Ctr5 Ctr6 Ctr7Latency Measurement Start PFI

37PFI33

PFI29

PFI25

PFI21

PFI17

PFI13

PFI9

Stop PFI38

PFI34

PFI30

PFI26

PFI22

PFI18

PFI14

PFI10

For the pulse generation at the input node we can use the following ports:

Table 22: Pin Connections for pulse generationPulse generation Ctr0 Ctr1 Ctr2 Ctr3 Ctr4 Ctr5 Ctr6 Ctr7Outputs PFI

36PFI32

PFI28

PFI24

PFI20

PFI16

PFI12

PFI8

44

Page 54: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

A APPENDIX

Figure 31: Electrical connections used for measurement

A.4.5 Circuit Connections for Cycle Time Measurement

On the PCI counter we make use of the gate of counter 1 along with the edge detection program.

Table 23: Pins for edge generationMeasurement Ctr0 Ctr1 Ctr2 Ctr3 Ctr4 Ctr5 Ctr6 Ctr7Period/FrequencyMeasurement (LowFrequency with One Counter)

PFI38

PFI34

PFI30

PFI26

PFI22

PFI18

PFI 14 PFI 10

Period/FrequencyMeasurement (HighFrequency with TwoCounters)

PFI39

PFI35

PFI31

PFI27

PFI23

PFI19

PFI 15 PFI 11

Period/FrequencyMeasurement (Large Rangewith Two Counters)

PFI39

PFI35

PFI31

PFI27

PFI23

PFI19

PFI 15 PFI 11

45

Page 55: An Automated Test Framework for Hard Real-Time …kth.diva-portal.org/smash/get/diva2:619211/FULLTEXT01.pdf · 2013-05-02 · An Automated Test Framework for Hard Real-Time Communication

REFERENCES

References[1] International Electrotechnical Commission, , Industrial Communication Networks Fieldbus specifica-

tions - Part 3- 12: Data-Link Layer Service Definition - Part 4-12: Datalink layer protocol specification- Type 12 elements , IEC, dec 2007, 61158-3/4-12 (Ed. 1.0)

[2] Jean-Pierre Thomesse; Institut National Polytechnique de Lorraine - LORIA , Fieldbus Technology inIndustrial Automation , 10th IEEE International Conference on Emerging Technologies and FactoryAutomation(ETFA) 2005: 651-653

[3] EtherCAT Technology Group http://www.ethercat.org

[4] Rehnman M., Gentzell T.; Dept. of Autom. Networks, ABB Corp. Res., Västerås, Synchronization in aForce Measurement System Using EtherCAT , IEEE International Conference on Emerging Technolo-gies and Factory Automation(ETFA), 2008: 1023 - 1030

[5] Prtyz, G.; ABB AS Corp. Res. Center, Billingstad, Norway , A performance analysis of EtherCATand PROFINET IRT , IEEE International Conference on Emerging Technologies and Factory Automa-tion(ETFA), 2008: 408-415

[6] industrial Framework for Embedded Systems Tools http://www.artemis-ifest.eu/

[7] J. Robert, J.-P. Georges, E. Rondeau, T. Divoux; Université de Lorraine , Minimum Cycle Time Analysisof Ethernet-Based Real-Time Protocols , International Journal of Computers, Communications andControl (IJCCC) 2012: 743-757

[8] Felser, M.; Inst. of Eng. and Archit., Bern Univ. of Appl. Sci., Switzerland , Ethernet TCP/IP in automa-tion: A short introduction to real-time requirements , 8th IEEE International Conference on EmergingTechnologies and Factory Automation(ETFA) 2001: 501 - 504 vol.2

[9] Beckhoff Automation http://www.beckhoff.com

[10] Jae Chol Lee, Seong Jin Cho, Yong Han Jeon, Jae Wook Jeon ; Sch. of Inf. and Commun. Eng.,Sungkyunkwan Univ., Suwon, South Korea , Dynamic drift compensation for the Distributed Clockin EtherCAT , IEEE International Conference on Robotics and Biomimetics (ROBIO),2009: 1872 -1876

[11] Cena, G. and Bertolotti, I.C. and Scanzio, S. and Valenzano, A. and Zunino, C. ; IEIIT, CNR, Torino,Italy ,On the accuracy of the distributed clock mechanism in EtherCAT , 8th IEEE International Work-shop on Factory Communication Systems (WFCS), 2010: 43 -52

[12] NI - SCB 100 manual http://www.ni.com/pdf/manuals/371224b.pdf

[13] NI 6624 Online Manual http://www.ni.com/pdf/manuals/372142a.pdf

This report uses TEX typesettings

46