opc support opc servers validation tests -...

European Laboratory for Particle Physics Laboratoire Européen pour la Physique des Particules CH-1211 Genève 23 - Suisse

OPC support

OPC servers validation tests

Document Version: 4Document Date: 20 March 2003Document Status: FinalDocument Author: IT-CO-FE

Abstract The document describes against which will be validated OPC servers prior to be recommended by IT-CO-FE.

Introduction

IT-CO will recommend some OPC servers for the LHC Experiment DCS. These servers will be used with the SCADA system selected by JCOP, the ETM PVSS II.

In order to select these OPC servers or to define installation and start procedures, these OPC servers will have to be tested against special conditions. To identify the source of the problem, if any, the tests will be run initially with simple OPC clients and then with PVSS.

Final page 1

OPC support OPC servers validation tests Test catalog Version/Issue: 1/1

Test catalog

General (Test #1.)

Cold start

Tests dealing with the problems which may occur when starting a system form scratch.

Test #1.1: The OPC client starts before the OPC server.

An OPC client starts before the OPC server and its devices. This case usually happens when the OPC server is not a service, these OPC servers are meant to be started by the first OPC client attempting to connect.

• Can the OPC server be actually started by the OPC client?

• Is an NT service required?

• What are the consequences if the devices are not yet operational?

There are indeed two sub cases. In the first case (Test #1.1), the devices are already operational, the OPC server should easily initialize its communication with them when it is started. In the second case (Test #1.2) the devices are not yet operational, the OPC server can have problem in establishing the communication with the devices, it may be unable to create OPC items.

It is expected that the OPC Client is able to start the OPC server. It is as well expected that the OPC server will creates the OPC groups and OPC items irrespective of the availability of the devices. If the devices are not available the quality flags of the corresponding OPC items should reflect the problem till the devices become accessible.

Test #1.2: The OPC server starts before the OPC client.

When the OPC server is a NT service or “attached” to an NT service, the OPC server can be started without any request from any OPC clients. Problems may arise when the devices are not yet available.

• Is the server able to access the devices when they are successfully started?

• Are the Clients allowed to create OPC items and groups before the devices are accessible by the OPC server?] This question is equivalent to test 1.2

It is expected that the OPC Client is able to start the OPC server. It is as well expected that the OPC server will creates the OPC groups and OPC items irrespective of the availability of the

page 2 Final


devices. If the devices are not available the quality flags of the corresponding OPC items should reflect the problem till the devices become accessible.

Warm restart

Test #1.3: The OPC Client (or the PC it is running on) crashes;

The OPC client has been brutally disconnected from the OPC server.

• Can this Client reconnect to the OPC server?

It is expected that the OPC client can re-connect to the OPC server and successfully create its OPC groups and items.

Test #1.4: The OPC Server (or the PC it is running on) crashes;

• Can the OPC server restart and successfully reconnect to the devices;

• Can the client reconnect to the server?

According to the OPC specification the OPC server has not to create OPC item and group without being requested by OPC clients. This may be a problem for the SCADA if it does not execute again the OPC group and item creation procedure.

There are two cases, the PC crashes (can be simulated by a restart) or the OPC server crashes (can be simulated by a kill command)

Ideally the OPC client should be able to re-connect to the OPC server and re create the OPC groups and items.

Test #1.5: The devices become inaccessible (network problem or device problem)

• What is the diagnostic information the OPC server provides the OPC clients with?

• Are these pieces of information updated when the devices are accessible?

• Shall the OPC server be restarted?

Ideally, the OPC server should report about the unaccessibility of the devices by means of the OPC items quality flags. The OPC server should as well re establish a working connection with the devices when they are available. It should not be necessary to restart the OPC server.

Final page 3


Load tests

Test #1.6

Purpose

Test to see if the OPC server will read all the OPC items it suports.

Procedure

From the OPC client - subscribe to all the OPC items available within the OPC server - use a refresh rate of 20sec.

Expected Result

The OPC server will function correctly and read all the items subscribed to.

Test #1.7

Purpose

Test to see how the server behaves under a heavy load.

Procedure

Follow procedure for test #6, but decrease the refresh rate for the OPC group to 1msec.

Expected Result

The server should not crash - Note it is unlikely that all items can be updated in this time, hence some of the values that could be read in test #6 may know have a ‘last known value’ quality.

Conformance Test

Test #1.8

Test the conformance of the OPC server with the OPC standard. For this purpose the OPC foundations’ ‘OPC Data Access Compliance Test’ tools is to be used (version 1.1).

Procedure

The tester shall, using the test tool, connect to the OPC server and subscribe to all the OPC items of one node. The tester shall then start the execution of the test cases (takes about ten minutes to complete)

page 4 Final

OPC support OPC servers validation tests Detailed descriptions (Test #2.) Version/Issue: 1/1

Expected Result

The test tool produces a report indicating the compatibility of the Server with the version of the OPC standard that the server claims to support. If there are imcompatabilities they will be enumerated in the report.

Detailed descriptions (Test #2.)

For each of the recommended fieldbuses, PLC or devices, the test of the corresponding OPC server will be detailed below.

Fieldbus

Profibus (Test #2.1.)

a. Network description

• two Wago nodes with PT100 and DI/DO.

• two PCS, one for the Profibus card, one for the client

b. Software configuration

• an OPC server with a profibus configuration for the nodes

• an OPC client with a predefined set of 3 OPC groups, two with OPC items linked to data of a single node, one with OPC items attached to several nodes.

Test #2.1.1

• Switch ON the wago node power supplies;

• Log on the OPC Client PC;

• Start the OPC Client;

• Start the automatic OPC Group and Client creations (e.g. by opening a configuration file);

• Result: The OPC server should be automatically started, the OPC Groups and items created and the value refreshed;

Final page 5


Test #2.1.2

• Switch OFF the wago node power supplies;



• Start the automatic OPC groups and clients creations (e.g. by opening a configuration file);

• Result: The OPC server should be automatically started, the OPC groups and items created and the value tagged as bad;

• Switch ON the wago nodes power supplies;

• Result: The values should be updated as well as the quality of the items;

• [Repeat with the set of nodes partially started]

Test #2.1.3

• Switch ON the wago node power supplies;

• Log on the OPC server PC;

• Check if OPC server has been started;

• Log on the OPC client PC;

• Start the OPC client;

• Start the automatic OPC group and client creations (e.g. by opening a configuration file);


Test #2.1.4

1. Switch ON the wago node power supplies;

2. Log on the OPC Client PC;

3. Start the OPC Client;

4. Start the automatic OPC Group and Client creations (e.g. by opening a configuration file);

5. The OPC server should be automatically started, the OPC Groups and items created and the value refreshed;

6. When the values are successfully started, switch off the OPC client PC;

7. Wait 1 minute;

8. (If the OPC server comes with diagnostic tools...);

9. Restart the PC;



page 6 Final



13. Result: The values should be updated as well as the quality of the items;

14. Repeat from 6, but waits more than 6 minutes.

Test #2.1.5






6. When the values are successfully started, switch off the OPC server PC;

7. Wait 1 minute;

8. The values should appear as “BAD” on the OPC client (if not wait more than 6 minutes) or a message returned;

9. Restart the PC;

10. Result: See if the values are updated as well as the quality of the items;

Test #2.1.6






6. When the values are successfully started, switch off one of the Wago node (with AI);

7. Wait 1 minute;

8. The values of the items related to this module should be flagged as “bad”.

9. If Yes, restart the node;


Final page 7


CANopen (Test #2.2.)

Test #2.2.1

Purpose

Can linterfaces going an off line mode if no Can node responds to a Can message that is transmits. This test is to determine if the OPC server can recover from this when at least one node becomes available again.

To carry out this test, one Can node of a type accessable by the server is required. This should be correctly installed.

Procedure

1. Create an OPC group with one item in it that will cause a transmission to be sent from the OPC servers interface - this item should be a readable/writeable.

2. Write to the item and read it back.

3. Disconnect the servers interface.

4. Write to the item, leave one miinute then read it back.

5. Reconnect the servers interface.

6. Write to the item and read it back.

Expected Result

After step 2. the writen value should be read back.

After step 4. the writen value should NOT be rad back.

After step 6. the writen value should be read back.

WorldFIP

PLC

Siemens PLC (Test #2.3.)


• two S7-300 PLC with ethernet module and I/O modules.

• two PCS, one for the server, one for the client


• an OPC server with a S7 OPC server;

page 8 Final


• an OPC client with a predefined set of 3 OPC groups, two with OPC items linked to data of a single PLC, one with OPC items attached to several PLCs.

Test #2.3.1

• Switch ON the PLCs;





Test #2.3.2

• Switch OFF the PLCs;







• [Repeat with the set of nodes partially started]

Test #2.3.3








Final page 9


Test #2.3.4

1. Switch ON the PLCs;






7. Wait 1 minute;


9. Restart the PC;






Test #2.3.5







7. Wait 1 minute;

8. The values should appear as “BAD” on the OPC client (if not wait more than 6 minute) or a message returned;

9. Restart the PC;


page 10 Final

OPC support OPC servers validation tests Device specific (Test#3.) Version/Issue: 1/1

Test #2.3.6






6. When the values are successfully started, switch OFF one of the S7-300 (with AI);

7. Wait 1 minute;




Schneider PLC

Modbus TCP/IP

EthWay?

Device specific (Test#3.)

CAEN OPC server - SY1527 (Test#3.1.)


• A SY1527 with two boards.



• an OPC server with the CAEN OPC server;

• an OPC client with a predefined OPC groups.

Final page 11


Test 3.1.1

• Switch ON the SY1527;





Test 3.1.2

• No configuration file yet created;

• Switch OFF the SY1527;





• Switch ON the SY1527s;


Test 3.1.3


• Make sure NO CAENHVOPCServer is running on Server PC;

• Use the CAEN HV OPC Server Configurator to add entry to the SY1527 (PS Name, TCP/IP, IP address);

• Configure entry by defining items and send file to the OPC Server (can be done on either Server PC or Client PC);


• Add OPC Groups and preconfigured items to the Client;

• Result: The CAENHVOPCServer is running and the items are RED and quality BAD.


• Result: After approximately 15 seconds items should turn GREEN, quality GOOD and values displayed correctly;

page 12 Final


Test #3.1.4








Test #3.1.5

1. Switch ON the SY1527;






7. Wait 1 minute;


9. Restart the PC;






Test #3.1.6





Final page 13




7. Wait 1 minute;


9. Restart the PC;


Test #3.1.7

1. Switch ON the SY1527s;





6. When the values are successfully started, switch OFF the SY1527 (and/or disconnect ethernet plug;

7. Wait 1 minute;




CAEN OPC server - SY127 (Test #3.2.)


• A SY127 with two boards.



• an OPC server with the CAEN OPC server;

• an OPC client with a predefined OPC groups.

Test 3.2.1



page 14 Final





Test 3.2.2

• No configuration file yet created;






• Switch ON the SY127s;


Test 3.2.3


• Make sure NO CAENHVOPCServer is running on Server PC;

• Use the CAEN HV OPC Server Configurator to add entry to the SY127 (PS Name, TCP/IP, IP address);

• Configure entry by defining items and send file to the OPC Server (can be done on either Server PC or Client PC);


• Add OPC Groups and preconfigured items to the Client;

• Result: The CAENHVOPCServer is running and the items are RED and quality BAD.


• Result: After approximately 15 seconds items should turn GREEN, quality GOOD and values displayed correctly;

Test #3.2.4




Final page 15






Test #3.2.5







7. Wait 1 minute;


9. Restart the PC;






Test #3.2.6







7. Wait 1 minute;


page 16 Final


9. Restart the PC;


Test #3.2.7

1. Switch ON the SY127s;





6. When the values are successfully started, switch OFF the SY127 (and/or disconnect ethernet plug;

7. Wait 1 minute;




Weiner (Test #3.3.)

Unless otherwise stated the tests are designed for use with a single Wiener node. The OPC server is given a generic configuration (the node has access to all the protocol features offered by the OPC server) file for that node - thus simplifying the configuration process for the tests. These tests assumes the Wiener node is in correct working order. At the start of each test both the client and the server are running. The client is not subscribed to any items.

Because of the varying physical characteristics of Wiener HW, it is important that the Tester is aware of the characteristics of the node being tested.

Test #3.3.1

The purpose of this test is to ensure that the voltage of all the channels of a Wiener node may be read.

Procedure

The tester shall create an OPC group named Voltages and into this insert the voltageValue0-7, the GetOverVoltageProt, GetVoltageFlags and GetNoErrors OPC items.

Expected Result

Final page 17


For the channels that exist in the crate, the tester should read a correct voltage from the OPC client, with a quality of ‘good’. The tester should confirm the correctness of each voltage value with that displayed on the console.

GetOverVoltageProt and GetVoltageFlags should both have value of 0.

GetNoErrors should have a value of 8 (no errors).

Test #3.3.2

Test node trips on if a channel goes over voltage.

Procedure

Create an OPC group named Voltages. To this group add GetVoltageFlags, GetTripIfAnyErrorEnabled, GetNoErrors, OnOffCrate and getPowerOn. For a channel that exists in the node add to the group OverVoltageCompSetPoint and voltageValue.

Switch on crate (write 1 to OnOffCrate), note the voltage value. Write a value less than this into OverVoltageCompSetPoint. Then restore the original value. Switch the crate on.

Expected Result

Before writing to OverVoltageCompSetPoint:-

• GetTripIfAnyErrorEnabled = 64

• GetNoErrors = 8

• getPowerOn = 1

• GetVoltageFlags = 0

When a value less then voltageValue is written to OverVoltageCompSetPoint:-

• The node should switch off - getPowerOn = 0.

• GetVoltageFlags should be none zero

• GetNoErrors = 0

After the original value has been written to OverVoltageCompSetPoint and node switched on:-

• getPowerOn = 1

• GetVoltageFlags = 0

• GetNoErrors = 8

Test #3.3.3

The purpose of this test is to ensure that the currents of all the channels of a Wiener node may be read.

Procedure

page 18 Final


The tester shall create an OPC group names Currents and into this insert the currentValue0-7, GetCurrentFlags and GetNoErrors OPC items.

Expected Result

For the channels that exist in the crate, the tester should read a correct current from the OPC client, with a quality of ‘good’. The tester should confirm the correctness of each current value with that displayed on the console.

The GetCurrentFlags OPC item should be 0.


Test #3.3.4

The purpose of this test is to ensure the node trips off when the current limit is exceeded.

Proceedure

Create an OPC group named Currents. To this group add GetCurrentFlags, GetTripIfAnyErrorEnabled, GetNoErrors, OnOffCrate and getPowerOn. For a channel that exists in the node add to the group OverCurrentCompSetPoint and currentValue.

Switch on crate (write 1 to OnOffCrate), note the current value. Write a value less than this into OverCurrentCompSetPoint. Then restore the original value. Switch the crate on.

Expected Result

Before writing to OverCurrentCompSetPoint:-

• GetTripIfAnyErrorEnabled = 64

• GetNoErrors = 8

• getPowerOn = 1

• GetCurrentFlags = 0

When a value less then currentValue is written to OverCurrentCompSetPoint:-

• The node should switch off - getPowerOn = 0.

• GetCurrentFlags should be none zero (bit field - value indicates channel in error)

• GetNoErrors = 0

After the original value has been written to OverCurrentCompSetPoint and node switched on:-

• getPowerOn = 1

• GetCurrentFlags = 0

• GetNoErrors = 8

Final page 19


Test 3.3.5

The purpose of this test is to ensure that the temperatures of all the sensors in a Wiener node may be read.

Procedure

The tester shall create an OPC group named temperatures and into this insert the tempValue 1-8, GetTempErrorFlags and GetNoErrors OPC items for the node.

Expected Result

For the sensors that exist in the crate, the tester should read a correct temperature from the OPC client, with a quality of ‘good’. The tester should confirm the correctness of each temperature value with that displayed on the console.

The GetTempErrorFlags item should have a value of zero.


Test 3.3.6

Test the trip off/over temperature detection function of the node.

Procedure

Follow procedure of 3.3.5. Added to the group the following OPC items, TempLimit, TempWarning for an existing sensor and OnOffCrate.

Switch on the node.

Set TempWarning to the temperature value of the sensor -3.

Set TempLimit to temperature value of the sensor -6.

Restore original values. Switch node back on.

Expected Result

When TempLimit and TempWarning are set to values below the value being read from that sensor:-

• GetTempErrorFlags (or GetExtTempErrorFlags) should be none zero (bit value indicates the sensor in Error).

• GetNoErrors = 0.

• Crate should be switched off?

After original values are restored and crate is switched on:-

• GetTempErrorFlags (or GetExtTempErrorFlags) = 0.

• GetNoErrors = 8

• Node should be running.

page 20 Final


Test 3.3.7

The purpose of this test is to ensure that the fanspeeds of all the fans in a Wiener node may be read.

Procedure

The tester shall create an OPC group named Fans and into this insert the FanSpeed1-6, MiddleSpeed (mean), NominalSpeed (requested), GetFansOK and GetNoErrors OPC items for the node.

Expected Result

For the fans that exist in the crate, the tester should read a correct speed from the OPC client, with a quality of ‘good’. The tester should confirm the correctness of each speed value with that displayed on the console.

The speed of the Fans should match/be close to that of the NominalSpeed.

The GetFansOK status should read 16(OK).


Test 3.3.8

The purpose of this test is to show that the fan speed can correctly be changed by the tester.

Procedure

Follow procedure 3.3.5 to setup and populate the Fans OPC group. Add the opc item ChangeFansSpeed for the node being tested. Select the ChangeFansSpeed item in the running client and change the fan speed of the crate to a value between 2000 - 3000 rpm.

Expected Result

The NominalSpeed should change ‘immediately’ to the value set via the ChangeFansSpeed, the MiddleSpeed and speeds of the existing fans should quickly match that of the NominalSpeed. (Note - the Wiener protocol defines fan speed in RMS whereas the OPC server works in RPM - this there is some loss of precision when the fanspeed is set and read back).The GetFansOK status should read 16(OK).

Test 3.3.9

The purpose of this test is to show test the GetFansOK OPC item when the Fans are in a bad state.

Procedure

Follow procedure 3.3.5 to setup and populate the Fans OPC group. Start the Wiener node, stop the node. Make some change to the node such that one of the fans will not turn when the crate is switched back on again. Turn the crate on.

Final page 21


Expected Result

Before switching the node off the tester should check the that results are those detailed in the results of test Ft1.

After switching on the node after restraining one of the fans:-

• the value for the restrained fan should be 0.

• The GetFansOK status item should be 0.

• GetNoErrors should be 0 (error).

Test 3.3.10

The purpose of this test is to switch the Wiener crate off/on and ensure the Channel/fan values change accordingly.

Procedure

Crate groups as detailed in Fv1, Fc1 and Ff1. Additionally create a OPC group NodeControl and add to it GetPowerOn and OnOffCrate OPC items.Ensure the node is switched on. Note the values of the FanSpeed, Current and Voltages. Switch the crate off by writing 0 to OnOffCrate. Then switch the crate on again by writing 1 to OnOffCrate

Expected Result

When the node is switch off:-

• the GetPowerOn item should read 0.

• Fan, current and voltage values should read 0.

• GetNoErrors should read 8.

When the node is switched on:-

• the GetPowerOn item should read 1.

• Fan, current and voltage values should quickly return to (or close to) their original values.

• GetNoErrors should read 8.

3.3.11

Test the vmeSysReset of the node.

Procedure

Create OPC group crateCtrl. Add to the group VMESyreset. Write 1 to this item.

Expected Result

The node should reset. This may be seen from the console of the node where the LED display should read “VME system reset”.

page 22 Final


Test 3.3.12

The purpose of this test is to show that the ‘static’ information about a Wiener node can be read.

Procedure

Create a OPC group called staticNodeInfo. To this group add the following nodes. IDStringPS, IDStringFan, SoftwareVersionPS, SoftwareVersionCrate and SoftwareVersionFan.

Expected Result

The quality of all items in the staticNodeInfo group should be good. The values of each items should appear to be a sensible value (I am not aware of a means of verifying that the value is indeed sensible.)

Test 3.3.13

The purpose of this test is to ensure the PowerSupply and Fan operating times update only when the Wiener node is switched on.

Procedure

Set up and populate the NodeControl OPC group as described in 3.3.10. Additionally create a group dynamicNodeInfo and added to it the OperatingTimePS and OperatingTimeFan OPC items.Ensure the node is switched on leave it 2 minutes, switch off the node. Leave it for two minutes.

Expected Result

Whilst the node is switched on the tester should observer both OpertingTimePS and OpertingTimeFan incrementing twice. Then the node is switched off the value should remain constant.

Final page 23


page 24 Final

opc support opc servers validation tests -...

Documents