21402169 opc xml-da extension doku v10 e

7/30/2019 21402169 Opc XML-da Extension Doku v10 e

1/93

Application for Communication

Visual Basic .NET OPC Client for the XML-DA

Interface of the SIMATIC NET OPC Server

Extension


2/93

Warranty, Liability and Support

Data Exchange via XML-DA Beitrags-ID: 21402169

V1.0 26.04.05 2/93

CopyrightS

iemensAG2

005Allrightsreserved

21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Warranty, Liability and Support

We accept no liability for information contained in this document.

Any claims against us - based on whatever legal reason - resulting from theuse of the examples, information, programs, engineering and performancedata etc., described in this document shall be excluded. Such an exclusionshall not apply in the case of mandatory liability, e.g. under the GermanProduct Liability Act (Produkthaftungsgesetz), in case of intent, gross neg-ligence, or injury of life, body or health, guarantee for the quality of a prod-uct, fraudulent concealment of a deficiency or breach of a condition whichgoes to the root of the contract (wesentliche Vertragspflichten). However,claims arising from a breach of a condition which goes to the root of thecontract shall be limited to the foreseeable damage which is intrinsic to thecontract, unless caused by intent or gross negligence or based on manda-tory liability for injury of life, body or health. The above provisions does notimply a change in the burden of proof to your detriment.

The Application Examples are not binding and do not claim to be completeregarding the circuits shown, equipping and any eventuality. They do notrepresent customer-specific solutions. They are only intended to providesupport for typical applications. You are responsible for ensuring that thedescribed products are used correctly. These Application Examples do notrelieve you of the responsibility in safely and professionally using, installing,

operating and servicing equipment. By using this application example youaccept that Siemens is not liable for any damages except for those speci-fied in the above liability clause. We reserve the right to make changes tothese Application Examples at any time without prior notice. If there are anydeviations between the recommendations provided in this application ex-ample and other Siemens publications e.g. Catalogs the contents of theother documents have priority.

Copyright 2004 Siemens A&D. Any form of duplication or distribu-tion of these application examples or excerpts hereof is prohibitedwithout the expressed consent of Siemens Energy & Automation, Inc.

For questions about this document please use the following e-mail address:

mailto:[email protected]
mailto:[email protected]:[email protected]


3/93

Foreword


V1.0 26.04.05 3/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Foreword

Objectives of the application

Exchanging process data between logic controllers and computers via OPCis a core element of automation technology.

The application on hand shows a possible procedure for independentlygenerating individual OPC clients using the programming language VisualBasic .NET by Microsoft.

A visualization of a mixed process is hereby realized in Visual Basic .NET.The programming paradigm ".NET by Microsoft is used here.

Main contents of this applicationThe following teaching materials are provided with this application:

Installation and configuration of a web server (in this example the web-server of the internet information services of Windows). This web serveris used for accessing the OPC server.

User security (authentication and authorization of clients) for accessingthe web-server and the OPC XML-DA web service.

Demonstration in dealing with web services in .NET, especially the OPCXML-DA web service.

Demonstration of the most important OPC XML-DA methods for ac-cessing the process variables (browsing the OPC Server for availableprocess variables, synchronous writing and reading, asynchronousreading, operator control and monitoring)

Demonstration of error handling with .NET

Generating an OPC client as Windows application as well as ASP.NETweb application (for calling a web browser) with similar function range.

Delimitation

This application does not contain a complete description

of network safety aspects (encoded communication via SSL, applicationof firewalls, using VPNs)

of the .NET framework,

of the OPC specification as well as

deeper level ASP.NET mechanisms

Therefore, basic knowledge in the area of object oriented programming isrequired. Further knowledge in UML (Unified Modelling Language) is anadvantage.


4/93

Foreword


V1.0 26.04.05 4/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Structure of the document

The documentation of this application is divided into the following mainparts:

Introduction

Extension

Demonstration

In addition, two setup programs (for application in Windows and ASP.NETrespectively), which also contain the source code of the application, as wellas the STEP 7 code, are available.

This second document, the Extension part, is aimed at persons who wantto have a more detailed overview.

Part Description

Introduction

Application Descriptionand Function Principles

Provides a general overview of the contents. Youwill learn about the components used (standardhardware and software components and the spe-cially created software).

Extension

Function Principles in de-tail and Program Structure

Discusses the detailed function processes of theinvolved hardware and software components, thesolution structures, and where sensible the con-crete implementation of this application.

This part is necessary if you want to learn about theinteraction of the solution components, for examplein order to use them as the basis for own develop-ment.

Demonstration

Structure, Configurationand Operation of the Ap-plication

This part leads you step by step through the struc-ture, important configuration steps, commissioningand operation of the application.

An additional component available is the S7 program code.

Part Description

Setup Program of theWindows Application

Installs the Windows application on your PC. Thesource code of the application is available in theprogram directory.

Setup Program of theASP.NET Application

Installs the ASP.NET application on your PC. Thesource code of the application is available in theprogram directory.

S7 program codeThe S7 program code contains the code and a userinterface.


5/93

Foreword


V1.0 26.04.05 5/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Reference for Automation and Drives Service & Support

This entry originates from the internet application portal of the A&D Serviceand Support. The following link takes you directly to the download page ofthis document.

http://support.automation.siemens.com/WW/view/en/21402169
http://support.automation.siemens.com/WW/view/de/21402169http://support.automation.siemens.com/WW/view/de/21402169


6/93

Foreword


V1.0 26.04.05 6/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Table of Contents

Table of Contents ......................................................................................................... 6

Introduction................................................................................................................... 7

1 Document on Hand......................................................................................... 7

Function Principles and Program Structures ............................................................ 8

2 General Function Mechanisms...................................................................... 8

2.1 Internet Information Services (IIS) .................................................................... 8

2.2 Safety aspects of the Internet Information Services ....................................... 10

2.3 Introduction into XML...................................................................................... 16

2.4 SOAP protocol ................................................................................................ 17

2.5 Web services .................................................................................................. 18

2.6 Including a web service in Visual Studio .NET ............................................... 20

2.7 Function mechanisms of.NET Framework...................................................... 24

2.8 ASP.NET ........................................................................................................ 26

2.9 Safety settings of an ASP.NET application..................................................... 31

3 Function Mechanisms of this Application.................................................. 35

3.1 The OPC XML-DA interface ........................................................................... 35

3.2 Synchronous and asynchronous methods of the OPC XML-DA interface...... 39

3.3 Used objects and methods of the XML-DA interface...................................... 41

3.4 Cyclic reading of process values (subscriptions)............................................ 42

3.5 Data flow model .............................................................................................. 44

3.6 Logic data interface between controller and OPC client................................. 45

3.7 Managing the OPC items in the OPC client.................................................... 48

3.8 Structure of the Windows application ............................................................. 49

3.9 Structure of the ASP.NET application............................................................. 52

4 Explanations on the Example Program ...................................................... 54

4.1 Explanation for the simulation program (S7 program) .................................... 54

4.2 Saving the configuration data ......................................................................... 55

4.3

Windows applications ..................................................................................... 57

4.4 ASP.NET application ...................................................................................... 68

5 Configuration ................................................................................................ 79

5.1 Configuration of an OPC Server with STEP 7 ................................................ 79

5.2 Configuration of the Internet Information Services ......................................... 84

Appendix and List of Further Literature................................................................... 89

6 Glossary ........................................................................................................ 90

7 Literature ....................................................................................................... 92

7.1 Bibliographic References................................................................................ 92

7.2 Internet links ................................................................................................... 92


7/93

Introduction

Document on Hand

Data Exchange via XML-DA Entry-ID: 21402169

V1.0 26.04.05 7/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Introduction

1 Document on Hand

This document is the extension of the document "OPC Client for XML-DAinterface of the SIMATIC NET OPC Server Introduction".

The Introduction part describes the basic application structure and youshould be familiar with its contents before reading the Extension part.

Supplementary to the Introduction part, the document on hand includesfurther in-depth information on the application. However, it is not a substi-tute for a manual.


8/93

Function Principles and Program Structures

General Function Mechanisms


V1.0 26.04.05 8/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Function Principles and Program StructuresContent

Discusses the detailed function processes of the involved hardware andsoftware components, the solution structures, and where sensible the con-crete implementation of this application.

2 General Function Mechanisms

Here you will find further information on

the internet information services (IIS) and its safety aspects. You will beprovided with a brief introduction into XML, SOAP, web services, .NET-Framework as well as ASP.NET.

Table 2-1

Chap. Title Relevance Page

2.1 Internet Information Services (IIS) general 8

2.2 Safety aspects of the Internet Infor-mation Services

general 10

2.3 Introduction into XML general 16

2.4 SOAP protocol general 17

2.5 Web services general 18

2.6 Including a web service in VisualStudio .NET

general 20

2.7 Function mechanisms of.NETFramework

general 24

2.8 ASP.NET ASP.NET application 26

2.9 Safety settings of an ASP.NET ap-plication

ASP.NET application 31

2.1 Internet Information Services (IIS)

Introduction

The internet information services (IIS Internet Information Services) arethe services integrated within the Windows operating system in order topublish information via LAN, intranet or the internet. These services enablea relatively simple commissioning and administration of a web server.


9/93




V1.0 26.04.05 9/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Functionality of the IIS

Depending on the services, the IIS provide the following services depend-ing on the installation. When installing the internet information services, youshould only install those services which you actually want to use (seeDemonstration part of this application)

Table 2-2

Service Description

WWW service(or www-server)

Web server enables accessing web sites or web servicesvia HTTP protocol.

In this application, only the www-server is installed and used.

FTP server FTP File Transfer Protocol, enables generating FTP sites

for transferring files.

SMTP service Mail server service for transferring e-mails.

FrontPage 2000extension

Enables generating and managing Websites with MS Front-Page.

Snap-In IIS IIS management user interface (internet service manger) forthe Microsoft Management Console

Configuration of the IIS

The configuration of the IIS occurs via the internet service manager. A de-scription of the required configuration of the IIS occurs in the "Demonstra-tion" part of this application. The internet services manager is called with:

Start Settings Control Panel Administrative Tools Internet Ser-vices Manager

The WWW-service

As already mentioned, the www-service enables accessing web sites orweb services (see 2.5Web services) via the HTTP protocol. Most web sitesare static html-sites, but increasingly also dynamic ASP, ASPX, PHP orJSP pages. Web services generated with .NET have the extension ASMX.

HTTP protocol

The HTTP protocol is used for data exchange within computer networks(internet, intranet or local networks) and is based on TCP/IP. It providescertain http request methods which clients can use to request informationfrom servers. The server then returns the desired information to the client.

HTTP is a stateless protocol, i.e. no fixed connections are established be-tween a client and a server (as opposed to a configured S7 connection).This causes the information from former client requests being lost. Thisalso affects the application of the OPC XML-DA interface, which in return isbased on SOAP and HTTP (see 3.1The OPC XML-DA interface).


10/93




V1.0 26.04.05 10/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Standard website and virtual directories

The data which the www-service provides on a client server, is available onthe standard website. The standard website contains so-called virtual direc-tories. These virtual directories represent a connection with a real directoryon the server (or a network release or to an URL which is not discussedfurther within the framework of this application). The client gains access tocertain areas (directories or files) on the server.

Structure of the standard website

The following figure shows the structure of the standard website (DefaultWeb Site) in the internet service manager. The illustrated structure tree isthe standard setup after installation of .NET Framework and IIS. The right

pane, under Path, contains the actual positions of the virtual directories("Name") on the server.

Figure2-1

Access to a web server

The access to the web server of a PC via the intranet or the internet occursfrom a web client (e.g. a web browser) via the URL (see Glossary) of thePC, as well as the name of the virtual directory and the file to be accessed.

This can be set up in various ways: http://[Computer name ]/[Virtual directory]/[File name]

http://[IP-address ]/[Virtual directory]/[File name]

http://[Your domain]/[Virtual directory]/[File name]

2.2 Safety aspects of the Internet Information Services

General information

When using the IIS as web server on the internet, but also the intranet or alocal network, you as the commissioning staff or administrator and user

must place particular emphasis on network safety.


11/93




V1.0 26.04.05 11/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

The mechanisms described below refer mainly to the application safety (au-

thentication and authorization of the application, see Glossary). The wideranging topic of network safety (safe communication via SSL, Firewall, IP-Sec, ...) will not be discussed within the framework of this application.Please refer to\10\.

Overview

The following figure illustrates the safety aspects considered below. Themechanisms in bold print were realized in the application on hand.

The web server authentication and authorization (left box in the picture) areexplained in this chapter. The ASP.NET or web service authentication andauthorization (right box) are discussed in chapter 3.1The OPC XML-DA in-

terface

Table 2-2


12/93




V1.0 26.04.05 12/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Web server authentication

Enabling web server access to only one authorized circle of users, requireseach user/client to identify himself to the server.

The identification occurs mainly via specifying a user name and a respec-tive password. The Client thereby logs in at the Windows user accountwhich exists on the server. Further authorizations are then defined via thisuser account.

The following mechanisms are available for identification of a client on theIIS web server. Please refer to\4\.

Table 2-3

Mechanism Description

Anonymous ac-cess

Safety: none

The access of a client to the web server occurs with the user name"IUSR_Computername" and does not require specifying a user name orpassword. The user "IUSR_Computername" is assigned to the group"Guests".

For this application, the anonymous access is deactivated, so that eachclient must identify himself at the server.

Basic authentica-tion

Safety: low

It is a widely used option for identifying users. This method is based onthe http-specification (from version 1.1) and is supported by all browsers.

Warning

For this method, the unencrypted password is transferred via the network(as BASE64 code) and can be viewed by a third party! Therefore, this

method should only be applied if a safe connection exists between clientand server (e.g. a telephone (dialup) connection or a connection with SSLencryption).

Digest authenti-cation

Safety: high

The digest authentication provides the same features as the basic authen-tication. However, the password transfer is encoded here. This method isdescribed in the HTTP 1.1 standard.

Due to the fact, that this authentication method is only available with theWindows 2000 server, it is not used in this application.

Integrated Win-dows authentica-tion

Safety: high

This authentication method also enables encrypted transfer of the logininformation from the client to the server.

The encryption methods used are hash encryption or the Kerboros stan-dard. This authentication method can be used with all standard browsers

and is also used in this application.The disadvantage here is that the connection between the client and theserver must not occur via a Proxy. This makes the integrated Windowsauthentication favorable for an intranet environment where the server andall clients are located within the same domain.

Client certification

Safety: high

In this method, the client identifies himself to the server with a digitallysigned certificate. This certificate is issued by a credible certification ser-vice (e.g. http://www.verisign.com/).

For authentication of the client the web server uses SSL/TLS.

Due to the fact that issuing a client certificate is not that simple, as well asthe integrated Windows authentication being sufficient for this application,this method is not used here.
http://www.verisign.com/http://www.verisign.com/


13/93




V1.0 26.04.05 13/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Generating the authentication method

The authentication methods of the IIS web server are set via the internetservices manager. Thereby, the method can be defined globally for the ac-cess to the entire web server, or for a certain virtual directory, or a certainfile. Please refer to 5.2Configuration of the Internet Information Services.

Web server authorization

After the client has authenticated/identified himself at the server, the clientis given certain access permissions by the server. These permissions regu-late access to the data of the web server.

The ISS web-server provides different options of granting these access

permissions, which are explained in the following sections.

Web permission

Web permissions are defined directly via the internet services manager(see 5.2Configuration of the Internet Information Services). Thereby, thepermissions can be defined globally for the access to the entire web server,or for a certain virtual directory, or a certain file.

The granted permissions apply equally to all clients at the server (as op-posed to NTFS permissions). The following permissions can be granted:

Table 2-4

Permission Description

Read Clients can read directories or file contents as well as theirproperties. Activated for this application.

Write Clients can change directories or file contents as well as theirproperties. Deactivated for this application.

Script access (Only available if read or write permissions have been granted)Enables the user to access the source code scripts on theserver (e.g. ASP scripts). The script access has been deacti-vated for this application.

Warning

When activating script access, it is possible that the client hasthe option of viewing confidential information, such as user

name and password, in scripts of an ASP application. Theclient may also be able to change the source code on theserver, which considerably restricts security and performanceof the server.

Search direc-tory

The client can have a list of files and sub-directories displayedin this virtual directory. Deactivated for this application.


14/93




V1.0 26.04.05 14/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

User settings

An IIS application (e.g an ASP.NET application or a web service) is firstcreated as a virtual directory with the internet services manager. This con-tains one or several files executable in a web browser (e.g. *.asp, *.aspx,*.asmx). This application also includes all sub-directories and files of thevirtual directory. This virtual directory must be turned into an application(see 5.2Configuration of the Internet Information Services).

The following settings for an IIS application can then be made in the inter-net services manager.

Table 2-5

Setting Description

Execution permissions

None No scripts must be executed (e.g. ASP.NET applications).

Scripts only Only scripts must be executed on the server. This setting isused in this application as well as for the OPC XML-DA webservice, as well as for the ASP.NET application.

Scripts and ex-ecutable files

Scripts and executable files may be executed on the server.

Application protection

Low The application runs in the IIS process. In case of a crashcaused by a program error, the entire web server will also failand must be rebooted manually.

Medium All IIS applications run in a separate process. During a pro-gram error within an application all parallel running IIS appli-cations are terminated, however, the web server is not af-fected. This setting is used in this application as well as forthe OPC XML-DA web service, as well as for the ASP.NETapplication.

High Each IIS application runs in a separate process. A failure ofan IIS application has no effect on other IIS applications orthe web server. For many (>10) parallel running IIS applica-tions, however, this setting reduces the performance.

NTFS permissions

As opposed to the web permissions of the IIS, the NTFS permissions aregranted on the operating system level. On NTFS file systems (for Windowsoperating systems from Windows NTand later versions) different, individualuser access permissions can be provided for each file and each directory.

The most important ones are read, write and execution permission. Thesepermissions apply to all applications (i.e. also for IIS or ASP.NET), whichaccess these files or directories under a certain user. The permissions canbe granted individually for single users or for user groups. The user anduser groups are created and managed in the Windows user administration.


15/93




V1.0 26.04.05 15/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Granting NTFS permissions

NTFS permissions for certain files or directories are granted in the Win-dows Explorer via the Properties dialog of the respective file or directory (inthe "Security settings" tab).

Note If web permissions have been granted at the same time as NTFS permis-sions, the permissions denying access always have priority over the per-missions allowing access.

Restrictions for IP addresses

This method enables allowing or denying access to the website, directoryor file for certain users, computers, several computers, or domains.

As this function is only available with the operating system Windows 2000Server, it is not used in this application.

IISLockdown

The IISLockdown tool enables automating large parts of the securing proc-ess for your web server. You can select a specific server type, whichclosely matches your web server, and then the most important security set-tings for your web server are made automatically. This includes:

Deactivating not required IIS services (e.g. FTP, e-mail etc.)

Executing not required or preventing problematic scripts (e.g. .idq,.shtml, .idc, .printer etc.)

Removing not required virtual directories on the web server (IIS Sam-ples, MSADC, IISHelp, Scripts, IISAdmin)

Deactivating the anonymous access to the web server

Deactivating the WebDAV support (service for editing files on the serverand clients)

Creating the user group "Web Applications" with restricted access per-missions on the PC.

Restricting access permission (executing and writing) for the user group"Web Anonymous Users" (anonymous internet access) and "Web Ap-plications" (ASP.NET applications) to various system files and programs(via NTFS permissions)

Installation of the URLScan ISAPI filter


16/93




V1.0 26.04.05 16/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

URLScan

URLScan is an ISAPI (Internet Server Application Programming Interface,see Glossary) filter, which enables the administrator of the IIS (i.e. you) todefine, which http requests will be processed by the web server.

Depending on the selected web server configuration in the IISLockdowntool, URLScan is automatically configured so that only those http requestsabsolutely necessary for this configuration are processed.

2.3 Introduction into XML

The following chapter explains the basics of XML, on which web servicesare based.

The basis for web services: XML

XML (Extensible Markup Language) is a standard for structured display ofdata. In XML files, data is stored in plain text so it can be read by humansand machines alike. This has the advantage, that XML-files can be proc-essed on any systems with any (text processing) programs.

XML enables adding various meta information (additional information) tothe contained data. Further information on XML is available under the link\6\.

Example of an XML file

The following example of an XML-file shows all typical signs of XML. Itgives a concrete description of a fictitious box with its contents.

Figure 2-3


17/93




V1.0 26.04.05 17/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Structure of an XML file

The XML-file structure corresponds to a hierarchical tree structure. The fol-lowing table describes the XML elements.

Table 2-6

Element Description

XML Declara-tion

Contains information on the XML file on hand.

means, that this XML-file corresponds tothe XML specification version 1.0.

Element Made up of a start tag and an end tag. The content of the element is located betweenboth tags. Elements without content manage with one tag: Attributes Represent the meta information of an element. They are defined

in the start tag of an element:

Comments Provide a better understanding of the XML document and do notcontain specific data:

2.4 SOAP protocol

Introduction

The SOAP-protocol is used for data exchange between computer systems

(in this application between the client and the web service). The data of aSOAP message is displayed as text in XML format. This data can be trans-ferred with any transport protocols. The most commonly used transport pro-tocol, which is also used in this application, is HTTP. HTTP can be simplyadministrated and protected by means of a firewall.

Structure of a SOAP message

A SOAP message is always divided into two sections:

Table 2-7

Section Description

Head Optional. Contains the meta information of the message, e.g. viarouting, the encoding, or a particular transaction.

Body Contains the actual message data. This data corresponds to acertain XML scheme.


18/93




V1.0 26.04.05 18/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Communication via the SOAP protocol

The communication via SOAP is always divided into two steps:

Table 2-8

No. Step Description

1 SOAP Request The client sends a request (as XML telegram) to theserver, e.g. to perform a particular function.

2 SOAP Response After processing the request, the server returns the re-sult to the client in an XML telegram, e.g. the result ofthe called function.

Communication via the SOAP protocol

The following figure illustrates once more the sequence of a SOAP com-munication.

Figure2-4

2.5 Web services

What are web services?

Web services are based on open standards (XML, SOAP, WSDL) and en-able establishing connections between software components. Due to thestandardization, this connection is independent of programming languages,platforms or operating systems (as opposed to the COM model by Micro-soft).

This enables software components (clients) to call other software compo-nents (services) and use their functionality. The software components canbe located on the same PC or any networks be interconnected (e.g. Inter-net/Intranet). For the client to use the web service, this does not make any

difference (apart from the different data runtime between client and server).


19/93




V1.0 26.04.05 19/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Components of a web service

The following table describes the four most important components of a webservice (see link\7\).

Table 2-9

Component Description

Service A software component which is capable of processing data fromXML documents. The XML documents can be transferred fromone client to the service in any manner. Frequently used is thetransport via HTTP. How the service processes the informationof the XML document is not important for now. The result of theprocessing is sent to the client in an XML document.

Document The XML document, which is sent to the service, is the mostimportant feature of web services. It contains all application-specific information.

The documents which are exchanged between a client and theservice, correspond to a certain XML scheme. This ensures, thatboth sides generate and process valid XML documents. TheXML scheme, to which both sides must have access, is referredto as WSDL (Webservice Description Language, see below).

Address The address of the server specifies where it can be found whenusing a certain protocol (e.g. HTTP).

Envelope The envelope is a protocol for encapsulating the XML document.This ensures, that the service-specific information of the XML

document can be clearly separated from other information whichcould be exchanged between the client and the server.

The protocol used for this is SOAP (see above).

Operating description with WSDL

In order for a client to use a web service, it must know which operations theweb service has provided. Furthermore, the client must know how the XMLdocuments or SOAP messages for communication between client and webservice are structured. For this purpose, the operating description can bepolled for each web service in WSDL format (Webservices Description

Language).The operations of the web service which can be called by the client are de-fined in WSDL. This includes the parameters for these operations as wellas the structure of the XML documents or SOAP messages required forcalling these operations.

The Microsoft Visual Studio .NET development environment can use webservices and automatically reads the WSDL information. This provides thefunctions of the web service to the user (see 2.6Including a web service inVisual Studio .NET).


20/93




V1.0 26.04.05 20/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

An example for a web service

The OPC Foundation (an interest grouping of well-known manufacturers forthe further development of the OPC standard) provides a web service foraccessing an example OPC server.

The address of the web service is:http://opcfoundation.org/XmlDaSampleServer/Service.asmx. Clicking thelink opens the web service in a web browser. The displayed website isautomatically generated by the web service and lists the available opera-tions of the web service.

Clicking the displayed operations displays the respective SOAP messages(SOAP Request and respective SOAP Response). These telegrams show

which parameters are transferred to the operation and which return valuesare delivered by them.

Clicking on Service Description displays the respective WSDL file.

2.6 Including a web service in Visual Studio .NET

Introduction

This chapter explains how to use a web service in your .NET application. Itdoes not make any difference here, which .NET programming languageyou use (C++, C# or Visual Basic .NET) or which application you realize(Windows application or ASP.NET web application), as the development

environment used here (Visual Studio .NET 2003) is always the same.In the following part, the OPC-server web service of the OPC Foundationwill be integrated into a Windows application. The programming langueused is Visual Basic .NET.

Generating a new Windows application

In this section you learn how to create a new Windows application using theprogramming language Visual Basic .NET in Visual Studio .NET 2003. Ifyou wish to integrate the web service into your own application, you canskip this section.

Table 2-10

No. Instructions Note

1 Start Visual Studio .NET 2003 with:

Start Programs Microsoft Visual Stu-

dio .NET 2003 Microsoft Visual Studio.NET 2003

2 Open the "New Project" window by selecting:

FileNewProject...
http://opcfoundation.org/XmlDaSampleServer/Service.asmxhttp://opcfoundation.org/XmlDaSampleServer/Service.asmx?WSDLhttp://opcfoundation.org/XmlDaSampleServer/Service.asmx?WSDLhttp://opcfoundation.org/XmlDaSampleServer/Service.asmx


21/93




V1.0 26.04.05 21/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

3 Make the following settings:

Project typesVisual Basic projects

Templates:Windows applications

Name Name for your application

Save as Filing path for your project

4 Create the new project with OK. The new project is generatedand opened.


22/93




V1.0 26.04.05 22/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Integrating a web service

Here you will learn how to integrate a reference to a web service into an ex-isting Visual Studio .NET 2003 project. This will be explained using the ex-ample of the OPC-Server web service of the OPC Foundation. This re-quires your PC being connected to the internet.

Table 2-11


1 In the project folder explorer you open the context menuof your project and selectAdd web reference...

2 In the URL field you specify the URL of the OPC-Serverweb service of the OPC Foundation:

http://opcfoundation.org/XmlDaSampleServer/Service.asmx

3 Click the Go to button. The service description of theweb service is displayed.

4 If the error message is to be displayed on the right, your

proxy settings are configured automatically. However,Visual Studio .NET cannot use the automatic settings.Therefore, you need to adjust your proxy settings. To dothis, please follow the steps below:

1. Open the internet options with: Start Set-tings (Control Panel ) Internet

Options.

2. In Internet Properties you select the Connec-tions tab.

3. Open the LAN settings with the LAN Settings...button (at the very bottom).

4. Mark the checkbox Use a proxy server foryour LAN....

5. In the fieldsAddress and Port you enter address


23/93




V1.0 26.04.05 23/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc


and port of your proxy server. Should you not knowthese details, please request them from your net-work administrator.

6. Confirm all details with OKand perform steps 2 and 3in Visual Studio once more.

5 As soon as the web service has been found, a name issuggested in the field Web reference name. You canchange it or keep it.

Add the web reference to your project withAdd refer-ence. Den Webverweis sehen Sie nun

im Projektmappen-Explorer:

Utilizing the functions of a web service

After including the web reference into your project, the operations of theweb service can be utilized in your program.

First, you create a new name space for all relevant web service compo-nents using the WSDL information. This name space contains all classesrequired for the access to the operations of the web service.

These classes are so-called proxy classes which enable accessing the ac-tual operations of the web service. They encapsulate the entire communi-cation to the web service via SOAP and HTTP and need not be further at-tended to with regards to program technology.

This equally enables accessing the operations of the web service as well asthe methods of any other class.

The classes of a web service in the object browser

The classes of a web service can be displayed in the object browser. Allmethods and properties of the individual classes can be viewed there.

Access to the operations of a web service

The access to the web service from the program then occurs via creating anew instance of the web service class. The operations of the web service

can then be called via this instance. This is illustrated in the figure below.


24/93




V1.0 26.04.05 24/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Figure2-5

2.7 Function mechanisms of.NET Framework

Introduction

.NET Framework is a development and execution environment. They en-able the interaction between different, .NET-capable programming lan-guages and libraries for creating .NET applications.

These .NET applications are, similar to Java, not directly compiled to themachine code running directly on the CPU of the PC, but compiled into anintermediate language. This intermediate language is only compiled to ma-

chine code by a special runtime environment when starting the application.

Overview

The following figure shows the structure of.NET Framework. The individualcomponents are described in the following sections.


25/93




V1.0 26.04.05 25/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Figure2-6

WIN32 API

Win32 API (Application Programming Interface) is the basis of .NETFramework. Win32 API provides system functions. These system functionsare used by Windows applications, in order to gain access to the operatingsystem.

Common Language Runtime (CLR)

Common Language Runtime (CLR) is based on Win32 API. It constitutes aruntime environment comparable with a Java Virtual Machine model. Itcompiles Just In Time (JIT), a type of byte code, into machine code (whichdepends on the respective processor architecture). Microsoft refers to it asIL-Code (Intermediate Language).

Intermediate Language, Garbage Collector and unmanaged Code

The advantage of the IL code is the fact that it is independent of the plat-form. It is also possible to execute this code on Linux (Unix) systems, if aCLR has been implemented there (i.e. http://www.mono-project.com/).

The CLR does not only perform the JIT compiling of the IL code, but alsothe entire memory management. Similar to Java, a Garbage Collector (GC)was developed, who releases un-referenced memory areas within the CLRafter an unspecified time. Code subjected to the access of the GarbageCollector is also referred to as managed Code.

In order for it to be possible in certain cases to still control the release ofmemory areas manually, the developed code can be declared as "unman-
http://www.mono-project.com/http://www.mono-project.com/


26/93




V1.0 26.04.05 26/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

aged". This enables protecting certain code areas or entire programs ex-

plicitly from the access of the Garbage Collector.

Base Classes

Regarding the libraries of partly varying extend of the classic Windowsworld, Microsoft has now implemented a uniform base class library whichcan be accessed independently from the .NET programming language.

Visual Studio .NET

Visual Studio .NET provides a uniform development environment for the dif-ferent .NET languages.

This enables realizing .NET components in different languages. Interactionbetween the .NET components is possible with Visual Studio .NET withoutgreater efforts.

Mainly the easy to handle integration options within the .NET componentsenable a faster development.

2.8 ASP.NET

Introduction

ASP.NET is a technology by Microsoft for creating dynamic web applica-tions. ASP stands for Active Server Pages, with ASP.NET being a contin-

ued development of ASP.As opposed to static html-pages, ASP.NET (as well as the predecessorsASP, DHTML or Javascript) enable displaying pages with dynamic contents(e.g. results of calculations) in the web browser. As already referred to bythe name ASP, the program logic of the web application runs on the serverand is independent of application displays in the browser of the client. Theclient will not notice any of this and only receives the result of the programlogic as an html-page.

ASP.NET is part of .NET Framework. This allows to create the web applica-tions with each .NET-compatible programming language (e.g. Visual Basic.NET, C# or J#). Further information at\12\.

Overview of the functionality

The following figure shows the sequence during requesting an ASP.NETpage from the client.


27/93




V1.0 26.04.05 27/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Figure 2-7

Description of the functionality

The sequence of the request is further explained here.

Table 2-12

No. Description

1 The client sends a request to the web server (via http) from the internetbrowser. This may be the call of an ASPX page (which are alwaysASP.NET applications) or pressing a button on the ASPX page.

2 The Web server recognizes the request as an ASP.NET request and for-wards it to the ASP.NET application.

3 Depending on the request, certain functions are called in the programcode of the ASP.NET application.

4 At the first call of the program code of the ASP.NET application, it is com-piled into Intermediate Language (IL) by .NET Framework, and executedin the Common Language Runtime (CLR) of .NET Framework.

5 The program code of the ASP.NET application now generates a dynamicASPX page and transfers it to the web server.

6 The web server forwards the generated ASPX page to the client (viaHTTP).

Life cycle of an ASP.NET page

During each call of an ASPX page by the web server, the pages runs

through various states on the server, which are described as life cycle. The


28/93




V1.0 26.04.05 28/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

following table illustrates the life cycle of an ASPX page in its temporal se-

quence.

Table 2-13

State Description

Initialization Initialization of settings which are to apply to the entire du-ration of the request.

Loading the dis-play status

The display status is a list of name/value pairs in whichcontrol elements and the page itself store all informationwhich must be permanently available beyond web requests.

Processing re-turned data

Processing form data, e.g. if the text of a text box haschanged, a respective event is triggered in the server.

Loading the page Loading the page with all control elements and all other,required data, e.g. database inquiries.

Returning thechange notifica-tion

If the status has been changed compared with the previousstatus, a respective method is called.

Returning theevent handling

Calling a server code which was triggered by the client (e.g.by clicking a button).

Phase beforepage display

Preparing the display of the page. Executing short-termupdates.

Saving the dis-play status

The display status of all control elements are saved as wellas the entire page.

Page presenta-tion

Displaying the page.

Unloading thepage

The last life signal of the page, prior to being deleted.Serves for releasing critical resources.


29/93




V1.0 26.04.05 29/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Important ASP.NET features

Table 2-14

Feature Description

.NETFramework

The integration of ASP.NET in into .NET Framework enables ac-cess to the complete functionality of .NET Framework from theweb application. This includes utilizing all .NET-compatible pro-gramming languages.

Compiledcode

The program code (IL) of an ASP.NET application is compiled tomachine code when first calling the CLR (therefore, the first call ofan ASPX page causes a delay for the following calls). This pro-vides a performance advantage compared with previous ASPapplications (where program code is interpreted for each call).

Web Forms Web forms can be used for generating form based websites. Youcan use ASP.NET server control elements, for creating generalelements of the user interface, and program them for generaltasks. With these control elements, web forms can be generatedvery quickly from reusable, integrated or user defined compo-nents, so that the code of a page is simplified.


30/93




V1.0 26.04.05 30/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Saving variables in an ASP.NET application

As described, the transfer of ASPX pages is based on HTTP. This protocolbeing stateless, it is not possible without difficulties to save states (e.g. ofvariables or even whole instances of classes) throughout several calls. If apage is called by a client, the server initially does not know whether thesame client has called this page before or not.

ASP.NET offers different options of saving data throughout several pagecalls. Three possibilities are described in the following table. In this applica-tion, the session state is used.

Table 2-15

State Description

ViewState Saves the state of the page throughout several calls of thesame page (e.g. forms). The state includes the status of inputfields and other control elements on the page, but also userdefined data.

For saving the ViewState, a hidden field named __VIEWSTATEis used on the website. The state is written to this field in codedformat. Due to the fact, that the field is located in the websiteitself, the ViewState data is sent from the client to the server andback with each call. The more data are saved in ViewState, thelarger the data volume to be transferred (cost + time!).

Saving data: ViewState("[any name]") = Data

Read data: Data = ViewState("[any name]")

Session state A session ranges over the entire period of time in which a clientuses a certain web application.

Data saved in session state always remain on the server. Thiskeeps the data volume to be transferred very low.

The identification of a session occurs either by means of acookie (see Glossary) or by means of a session ID in the URLassigned to each client by the server.

Saving data: Session("[any name]") = Data

Read data: Data = Session("[any name]")

Applicationstate

The application state contains data and information which applyfor the entire web application as well as for each user (client).

The application state is filed in the main memory of the serverand is not persistent (i.e. after terminating the web server thesedata are lost).

Saving data: Application("[any name]") = Data

Read data: Application("[any name]") = Data


31/93




V1.0 26.04.05 31/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

2.9 Safety settings of an ASP.NET application

Overview

The following figure illustrates the safety aspects to be considered in thecourse of this application. The ASP.NET application, or the web service re-spectively, are further discussed below. The mechanisms in bold print wererealized in the application on hand.

Figure2-8


32/93




V1.0 26.04.05 32/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

AuthenticationTable 2-16

Method Description

Windowsintegrated

When using the integrated Windows authentication, no furtherauthentication needs to be performed in the ASP.NET applica-tion. It is performed completely by the IIS web server. Therebythe Windows user accounts which exist on the server are usedfor the authentication of the client.

This method is used for this application.

Form based This authentication method does not use the Windows user ac-counts on the server. When the client calls a protected site, the

server will divert him to a login-page. There the client enters auser name and a password. If they are valid, the client receivesa so-called ticket from the server. It is limited in time and issaved on the client computer as a cookie. Using this ticket, theclient can now access the protected sites.

This authentication method is not further considered within thisapplication.

Passport This requires the Microsoft Passport SDK (Software Develop-ment Kit). The authentication occurs with the Microsoft Passportuser database on the internet. User information of all registeredpassport users are filed there.

This service is used, for example, by the e-mail service hotmail

by Microsoft. Hoverer, the Passport-service by Microsoft is notfree of charge, therefore it will not be used in this application.

Defining the authentication method

Defining the authentication method for an ASP.NET application is relativelysimple. It occurs in the configuration file web.config of the ASP.NET appli-cation.

The following figure displays a section from this configuration file. In the"authentication" element, in the attribute "mode", the type of authenticationis specified. For this application, the value is "Windows", as the integratedWindows authentication is used. Further possible values are "Forms",

"Passport" or "None".Figure 2-9


33/93




V1.0 26.04.05 33/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Authorization

Table 2-17

Method Description

URL authori-zation

Verifying the data access with ASP.NET on the basis of the re-quested URL (e.g. "http://localhost/app/mainform.aspx"). It isconfigured in "web.config".

This way, the access to the respective ASP.NET application canbe explicitly allowed or denied for certain users or user groups.In this application, the access to the ASP.NET application isrestricted to members of the user group "Users".

The standard setting (preset: access to all users permitted) hasbeen set in the global configuration file machine.config.

File authori-zation

See also 2.2Safety aspects of the Internet Information Services

When starting the ASP.NET application from a client, it is exe-cuted on the server with the user account ASPNET (if no im-personation is used, see below). You must ensure that the datarequired by the application are allowed for the user "ASPNET",which normally will be the case.

.NET-Roles This method enables you to define in the source code of theASP.MET application whether the current client is authorized toaccess certain resources or execute certain operations. Youverify the client by his user name and/or its respective usergroup.

This functionality is not performed in this application directly.

However, a brief example is described in the source code of theapplication as a comment.

Setting the authorization in the "web.config" file

The following figure shows the authorization settings for the application onhand. Here, only the user "OPC-Client" has access to the ASP.NET appli-cation ("allow" element). All other users are denied access (deny element)

Figure 2-10


34/93




V1.0 26.04.05 34/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Impersonation

If an ASP.NET application is called by a client, it will normally be executedon the server under the user account "ASPNET". This account is memberof the group Users which gives it relatively few permissions.

If you wish to grant the clients individual permissions during executing theASP.NET applications (by data authorization), you can use Impersonation.The ASP.NET application on the server takes on the identity of the client(on the server it runs under the user account to which the client has loggedon). Now the same access permission on file levels apply for the ASP.NETas for the user account of the client.

The Impersonation is defined in the configuration file web.config of the

ASP.NET application. However, as Impersonation is not used in this appli-cation, it is not further discussed here.


35/93


Function Mechanisms of this Application


V1.0 26.04.05 35/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

3 Function Mechanisms of this Application

Here you will find information on

the functionalities offered by the OPC XML-DA interface, such as structureof the data interface between controller and head-end, how OPC items aremanaged in the Windows application, and how the Windows application isstructured.

Table 3-1

Chap. Title Relevance Page

3.1 The OPC XML-DA interface general 35

3.2 Synchronous and asynchronous meth-ods of the OPC XML-DA interface

general 39

3.3 Used objects and methods of the XML-DA interface

general 41

3.4 Cyclic reading of process values (sub-scriptions)

general 42

3.5 Data flow model general 43

3.6 Logic data interface between controllerand OPC client

general 45

3.7 Managing the OPC items in the OPCclient

Windows application 48

3.8 Structure of the Windows application Windows application 493.9 Structure of the ASP.NET application ASP.NET application 52

3.1 The OPC XML-DA interface

Data Access interfaces of the SIMATIC NET OPC server

The figure below illustrates the Data Access interfaces available in the SI-MATIC NET OPC server. The left half represents the "classical" interfacesbased on COM. The right half represents the new interface based on a webservice and SOAP.


36/93




V1.0 26.04.05 36/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Figure3-1

What is OPC XML-DA

OPC XML-DA (Data Access to an OPC server via XML) is, like the classicOPC Data Access, an interface for variables of an OPC server. This is,however, completely platform independent (unlike for the COM technologyused for OPC Data Access) and is also supported by the development en-vironment Visual Studio .NET.

Data access by means of OPC XML-DA has a function scope based onOPC Data Access, however, only write and read services are available.

Change controlled feedback messages about data changes, like for COMor DCOM OPC DA interfaces, are not planned for OPC XML-DA due to theloose internet connection (see 2.1Internet Information Services (IIS)).

SOAP vs. DCOM

In this application the utilization of the SOAP based OPC SML-DA interfacehas priority. Due to the fact that COM technology, or respectively DCOMbeyond computer boundaries, were used so far, SOAP and DCOM are nowbeing compared here.


37/93




V1.0 26.04.05 37/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Table 3-2

Advantages Disadvantages

SOAP Platform independent (clientside)

Simple administration asbased on HTTP and XML

Not suitable for transferringlarge data volumes

A web server is required atthe head-end

DCOM Enables feedback from serverto client

Higher data throughput

Windows-based

Not directly supported by.NET

Complicated administration

Security settings for OPC XML-DA Web Service

Apart from the access protection to the OPC server, which can be config-ured in STEP 7, you can configure an additional access protection for OPCXML-DA web service. OPC XML-DA web service being an ASP.NET appli-cation, it has a configuration file "web.config".

As described in chapter 3.1The OPC XML-DA interface, the authenticationand authorization method for the web service can be defined in"web.config".

The "web.config" of the OPC XML-DA web service is available at:

"\[Siemens installation directory]\SIMATIC.NET\opc2\binXML\"

The "web.config" of the OPC XML-DA web service is available in this application

The following figure illustrates the user-defined settings of the "web.config"of the OPC XML-DA web service for this application. The "authentication"element was kept at the standard value (mode="Windows"). The "authori-zation" element with its sub-elements was added (see "Demonstration" partof this application).

Figure 3-2

Access permissions granted by "web.config"

The above section of the "web.config" of the OPC XML-DA web servicegrants the following access permissions:


38/93




V1.0 26.04.05 38/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Access allowed for the user "OPC-Client" and "ASPNET" on the PC

"Head-end".

Access denied for all other users


39/93




V1.0 26.04.05 39/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Important differences to the DA 2.05 interface of the OPC serverCompared with the (classic) DA 2.05 interface of the OPC server, the OPCXML-DA interface has the following differences:

The access to the OPC items is only allowed via the item-ID, there is nospecial OPC item object. There are no Client- or ServerHandles for theindividual OPC items.

The OPC items are not organized in OPC groups. On being called, theoperations (e.g. reading or writing) are given a so-called item list, whichcontains the item-IDs.

Resource handling needs not be focused on, unlike for the DA inter-

faces based on COM mechanisms. With the exception of subscriptions, all write and read operations are

performed directly to the controller (the DEVICE).

The subscription ping rate corresponds to the UpdateRate at OPCgroup objects.

The XML-DA interface does not contain an OnDataChange mechanism,i.e. the server cannot automatically inform the client of a changing proc-ess variable. Subscriptions are used for this, which must be polled aftera certain time defined by the OPC client.

Logging off the OPC client at the OPC server is not possible. When es-

tablishing the connection, it is verified whether the OPC server exists.When accessing the OPC server, it is started. If within a timeout intervalthere is no access to the OPC server, it is stopped again.

3.2 Synchronous and asynchronous methods of the OPC XML-DAinterface

Introduction

The methods of a web service are principally asynchronous. This means,that the client sends a request (SOAP request) for processing a method tothe web server. After the web service terminates processing, it sends theresult back to the client (SOAP response). The time when the web servicereturns the result is not defined. After sending the SOAP Requests the cli-ent can continue with program processing and needs not wait for the SOAPResponse (asynchronicity).

However, if the web service does not respond to a request within a givenperiod of time (Timeout), an error is output by the called function. The time-out interval can be defined by the user.

The methods of the OPC XML-DA web service can be called asynchronousas well as synchronous (whereby Request and Response are combined in

one call).


40/93




V1.0 26.04.05 40/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Data flow diagrams for synchronous and asynchronous functions

The following figure illustrates the difference between an asynchronous (2-5) and a synchronous call (6-9) of the same operation in the web service. Inthe normal program sequence (1) an asynchronous function is called first,and then a synchronous function. A precise explanation of the processesoccurs directly after the diagram.

Irrespective of whether a synchronous or an asynchronous function iscalled, SOAP request and SOAP response are always the same for thesame web service operation (3 = 7, 4 = 8).

The graphic also applies for remote OPC clients.

Figure 3-3

Asynchronous methods

From the normal program sequence (1) the method for sending a request iscalled first (2). The method names for sending a request starts with Begin(e.g. BeginRead()). The name of the function to be called when the webservice has processed the request, is transferred to the callback parame-ter. The method then generates a SOAP Request and sends it to the webservice (3). After sending the SOAP request, the client can continue withprogram processing. If the web service has terminated the request, it sendsa SOAP response to the client (4). The callback function is thereby called.

The web service result is polled with an end-method, e.g. EndRead() (5).


41/93




V1.0 26.04.05 41/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Principally, asynchronous method calls are suitable for executing options

with a higher data volume and longer runtimes. The operation runs in thebackground and the user interface can still be operated.

Synchronous methods

These methods consists only of a method call (e.g. Read() ). After themethod was started (6), the program initially continues being executed. Themethod first generates a SOAP Request and sends it to the web service(7). Then it waits until the SOAP response is returned by the web service(8). During this wait time the program is stopped. After receiving the SOAPresponse, the program is continued (9). If the response of the web servicedoes not occur within the timeout interval, the method is terminated with an

error (an exception is triggered).Due to the fact, that synchronous methods interrupt the program sequence,the program cannot be operated during the call. Therefore, long executiontimes of synchronous methods (e.g. at high data volumes) should beavoided or asynchronous methods be used.

3.3 Used objects and methods of the XML-DA interface

Introduction

This chapter provides you with an overview of the methods or operations ofthe OPC XML-DA web service used in this application. Irrespective of its

actual implementation in the source code of this application, the executionof these methods are described as synchronous methods.

A detailed description of the functions are available in the commented codeas well as in 4Explanations on the Example Program.

RequestOptions

These are call options, which are transferred to each method of the XML-DA interface. Here you can define, whether after executing the operationthe XML-DA interface returns certain values for each of the affected OPCitems. These include e.g. item name, time stamp or diagnostics information.

GetStatusA GetStatus request verifies the web service and queries manufacturer-specific information, which are not accessible to other OPC methods. Themost important information hereby is the operation status of the OPCserver ("running", "failed", "noConfig" etc.)

Browse

The browse method is used for navigating within the hierarchical addressspace of the OPC server. It can be used for displaying all process variablesexisting in the address space of the OPC server.


42/93




V1.0 26.04.05 42/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Write (Read)

The Write method executes a write job for one or several items, wherebyeach item represents a process variable. Analog, the Read method exe-cutes a read job for one or several items.

Further methods

Further methods used are Subscirbe, SubscriptionPolledRefresh and Sub-scriptionCancel. These are discussed in greater detail in the following chap-ter.

Comparing the Read and SubscriptionPolledRefresh methods

The following table compares the Read method with the SubscriptionPolle-dRefresh method (see following chapter for them as a component of a sub-scription). It shows, which method is suitable for cyclic (i.e. continuousmonitoring) and which method is suitable for acyclic reading of processvariables.

Table 3-3

Operation Read SubscriptionPolledRefresh

Cyclic reading - +

Acyclic reading + -

3.4 Cyclic reading of process values (subscriptions)

Introduction

The OPC XML-DA web service offers the client the possibility of establish-ing a loose connection to the OPC server throughout several method calls.

The client has the option of logging on a Subscription at the web service.When logging on, the client transfers the list of items (i.e. process vari-ables) which should be contained in the subscription.

The client can continuously poll the logged on subscription (polled refresh).With each polled refresh from the client, the web service returns those

items including values, whose values have changed since the last polling.This mechanism helps reduce the latent time until completion of the valuechanges of a process variable, as well as reducing the communication loadbetween client and server.

Overview

The following figure gives a clear overview of the life cycle of a subscrip-tion. The three phases, logging on, polling, and logging off of a subscriptionare described below.


43/93




V1.0 26.04.05 43/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Figure 3-4

Logging on a subscription ("Subscribe" method)

The subscribe method is used for logging on a subscription at the web ser-vice. The client transfers a so-called Itemlist to the web service as well asvarious options. This Item list contains all items which the web service is tomonitor for changes within the framework of this subscription.

The parameter "SubscriptionPingRate" (in mili-seconds) determines thetime interval in which the server verifies the existence of the client. If theclient has not communicated with the server within the specified period oftime, the server can release all resources necessary for the subscriptionprocess of the client.

The method returns the ServerHandle (data type string) for this subscrip-tion. This ServerHandle is used to identify the previously logged on sub-

scription during all following calls. When requested, the method also returnsthe actual values of the items in the item list.

Polling a subscription ("SubscriptionPolledRefresh " method)

With this method, the client requests from the server (web service) an up-date of those items transferred when the subscription is logged on. The cli-ent transfers the previously received ServerHandle to the server.

The response from the web service contains an item list, which containsitems which have changed their value since the last polled refresh of thesubscription. Depending on which options were selected during logging onthe subscription, the web service delivers additional information for each

item, e.g. time stamp, item name, etc..


44/93




V1.0 26.04.05 44/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Logging off a subscription ("SubscriptionCancel" method)

With this method the client logs off the subscription at the web service withthe given ServerHandle. The web service can then release the respectiveresources.

3.5 Data flow model

Introduction

This chapter explains the data flow model of the XML-DA interface of theSIMATIC NET OPC server. Here you will learn how the individual methodsof the XML-DA interface exchange data with the controller.

Overview

The following figure shows an overview of the three methods of theXML-DA interface, which are used for exchanging process variables. Theseare:

polling a subscription (Refresh, 1 + 2),

direct reading of process values from the controller (Read, 3)

writing process values into the controller (Write, 4).

Figure 3-5


45/93




V1.0 26.04.05 45/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Explanation

The following table further explains the data flow for the three discussedmethods.

Table 3-4

No. Explanation

1 Polling a subscription always delivers values taken from a cache memory ofthe OPC server. So this polled refresh always delivers the value of a vari-able whose value has changed since the cache was last updated.

2 The cycle time at which the cache is updated is defined when configuringthe OPC server in the STEP 7 project. As soon as a subscription is loggedon, the OPC server starts the cyclic update of the cache.

3 The "Read" method always reads the current process value (irrespective ofwhether the call is synchronous or asynchronous). Each Read request tothe OPC server causes the server to read the process value from the con-troller and to return the current value to the OPC client.

It must be noted that frequent reading of a large number of process values,

possibly even from several clients, may lead to an increased bus load andcommunication load of the controller. A subscription should therefore al-ways be used for a cyclic polling of process values.

4 Process values are written directly to the controller. Each Write request tothe OPC server causes the server to immediately write the new value to thecontroller (depending on the access permissions granted in the configura-tion).

3.6 Logic data interface between controller and OPC client

Introduction

In this chapter you will learn which process variables of the controller areaccessed in the OPC client and how the respective OPC items are struc-tured in the OPC client.


46/93




V1.0 26.04.05 46/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Visualized process variables

The interface to the head-end is, on the controller side, implemented withthree data blocks. The contained variables represent the process values ofthe simulated mixing process. The following table describes the setup ofthe data blocks.

Table 3-5

DB Variable Data Type Description

Act_Cooler BOOL Current state cooler

Act_Heater BOOL Current state heater

Act_InValve1 BOOL Current state inlet valve 1

Act_InValve2 BOOL Current state inlet valve 2Act_Mixer BOOL Current state mixer

Act_Niveau REAL Current filling level in tank

Act_OutValve BOOL Current state outlet valve

Act_Temp WORD Current temperature in tank

Data_Act_Val

Act_Time DATE_AND_TIME

Current system time on S7

Data_Control Start_Auto BOOL Start mixing process

Rat_Niveau1 REAL Setpoint value level 1

Rat_Niveau2 REAL Setpoint value level 2

Rat_Temp_Max WORD Setpoint value maximum tem-perature

Rat_Temp_Out WORD Setpoint value outlet tempera-ture

Data_Rat_Val

Temparature_In WORD Setpoint value inlet tempera-ture


47/93




V1.0 26.04.05 47/93

CopyrightS

iemensAG2


21402169_

OPC_

XM

L-DA_

Extension_

DOKU_v10_e.doc

Access of OPC server to process variables

The access of the OPC server to the process variables of the S7 controlleroccurs via a configured S7 connection. This connection has already beenconfigured with the NetPro tool in the respective STEP 7 project. For usingthe XML-DA interface, it is not important whether the S7 connection hasbeen realized as a unilateral or bilateral connection (in this application it isunilateral).

The symbolic access to all process variables is also configured in the STEP7 project (in the Properties dialog of the OPC server in the NetPro tool).The symbolism of the variables in the OPC server is structured as follows:

[Station name].[CPU name].[DB name].[Variable]

e.g.: SIMATIC 300(1).CPU 315-2 DP.Data_Act_Val.Act_Temp

Managing the OPC items

For accessing the process variables from the OPC client, so-called itemlists are used at the OPC XML-DA interface.

These item lists contain an array of items. These items have different prop-erties, which depending on the requirement can be set differently. Theseproperties include, for example, the item name (the symbolic or absoluteaddress of the OPC item), the item value (either of the value to be writtenor the value to be read) and the time stamp (assigned by the OPC server).

For an OPC XML-DA client to be able to access the process variables viathe web service, the service must transfer the respective item lists (the Re-quest-ItemLists) to the web service. The OPC items returned by the webservice are also packaged by

21402169 opc xml-da extension doku v10 e

Documents