SCADA Integration with SAP using SAP PI Part 1

Posted by PRAVEEN KURNI in praveen.kurni3 on Jun 9, 2011 6:28:34 AM

inShare

SCADA Integration with SAP using SAP PI Part 1 - Business case & Systems Involved Before starting my previous project, I was little sceptic about SCADA (Supervisory Control and Data Acquisition) integration with SAP using PI, whether it is achievable or not. But I had an iota of confidence that this can be done somehow. With the help of SAP's XMII expert Pandiarajan .P and .NET consultant Mahesh Patel, I could successfully implement several interfaces integrating SCADA. Since there is no reference about this topic in SDN, so I thought of putting my experience in words as a series of blogs about the Integration. 1. SCADA Integration with SAP using SAP PI Part 1 - Business case & Systems Involved. 2. SCADA Integration with SAP using SAP PI Part 2 Systems Integration. 3. SCADA Integration with SAP using SAP PI Part 3 Interface. Business case: Our client has Indias biggest pipeline connectivity network in Gas distribution, (Downstream Delivery of Natural Gas through Pipeline & Gas Tankers) which is working under Central Government of India. They have Decentralized SCADA Servers providing by different vendors like INVENSYS and TELVENT. These will get Pressure/Volume/Temperature/GCV/NCV etc values from RTUs (Remote Terminal Units)/Flow Meters attached across pipelines. Based on the values SCADA will control the GAS flow in Flow Meters remotely. Business case was to fetch these values in to SAP TSW module and schedule the quantity of the Gas to be delivered on particular day.

Now let me introduce you with the landscape systems involved and brief introduction about them.

SAP ERP 6.0 EHP 4 TSW Module. SAP PI 7.1 EHP 1. SCADA with OPC DA Server (2.0) Decentralized OPC Gateways - OPC Clients. SAP ERP TSW module: TSW stands for Traders and scheduler workbench. Trader's and Scheduler's Workbench (TSW) provides functions for stock projection and for planning and scheduling bulk shipments using nominations. TSW provides the relevant master data to model the supply chain. The stock projection, planning, and nomination processes enable the scheduler to schedule bulk shipments while taking into account supply, demand, and available transportation.

1. 2. 3. 4. 1. 2. 3. 4. 5.

Processes and Functions The following planning tools are provided by the TSW application: Planning (Replenishment Proposals and Safety/Target Stock Calculation) Stock Projection Worksheet (SPW) Location Balancing Worklist The following scheduling tools are provided by the TSW application: Three-Way Pegging (3WP) Berth Planning Board (BPB) Nomination Ticketing Worklist

Since Clients business is to deliver Gas to various dealers, using Pipeline & Gas Tankers, for daily nominations and scheduling the quantity to delivery, this module has been used in the project. [ REF: help.sap.com] SCADA with OPC DA Server (2.0) - Decentralized: What is SCADA? SCADA stands for Supervisory Control And Data Acquisition. As the name indicates, it is not a full control system, but rather focuses on the supervisory level. As such, it is a purely software package that is positioned on top of hardware to which it is interfaced, in general via Programmable Logic Controllers (PLCs), or other commercial hardware modules. SCADA systems are used not only in most industrial processes: e.g. steel making, power generation (conventional and nuclear) and distribution, chemistry, but also in some experimental facilities such as nuclear fusion. SCADA systems used to run on DOS, VMS and UNIX; in recent years all SCADA vendors have moved to NT. SCADA systems are widely used in industry for Supervisory Control and Data Acquisition of industrial processes. Companies that are members of standardisation committees (e.g. OPC, OLE for Process Control) and are thus setting the trends in matters of IT technologies generally develop these systems. SCADA Servers which our client own was provided by following vendors: INVENSYS TELVENT There were multiple instances of these SCADA servers which are decentralized. But servers get synchronized with real time data on periodical intervals. How to communicate with SCADA? These SCADA systems include OPC (OLE for Process Control) Servers inside, other than its own Data Sources. OPC Servers are software applications (drivers) that comply with one or more OPC specifications as defined by the OPC

Foundation. OPC Servers communicate natively with one or more Data Sources on one side and with OPC Clients on the other. In an OPC Client / OPC Server Architecture, the OPC Server is a Slave while the OPC Client is the Master. Versions of OPC Servers released so far:

Data Format in SCADA: Data in SCADA is available in the form of TAGs, something like:

For each tag corresponding value will be updated to SCADA database by the RTUs (Remote Terminal Units) connected to Gas Pipeline. Based on which SCADA will control the flow of Gas through Flow Meters attached to Gas Pipeline. OPC Client machines will request these tag values by specifying the tag name. Client machines got the facility to subscribe the functionality to get updated information of tag values, every second or even shorter time interval. For further information on OPC Server please refer to MatrikonOPC.com OPC Gateways (OPC Clients) OPC Gateways systems are Client machines that will communicate to OPC Server in SCADA system. These Gateway systems with Windows Operating System and ISS installed & running. Communication between the OPC Client and OPC Server is bi-directional meaning the OPC Clients can read from and write to OPC Servers. Classic OPC Servers utilize the Microsoft Windows COM/DCOM infrastructure as a means of exchanging data. This means these OPC Servers must run on the Microsoft Windows operating system. An OPC Server can support communications with multiple OPC Clients simultaneously. But latest releases of OPC Servers supports HTTP Communications so Web Service are provided by OPC Servers can be directly consumed by client applications like SAP PI or ERP directly. OPC Client OPC Server Communication

[Ref: MatrikonOPC.com] These are all the systems and brief information about them. Let us discuss about the Architectural connectivity that we followed in our Systems Integration in my next blog. I hope this blog series helps you get an idea on integration between SCADA and SAP.

SCADA Integration with SAP using SAP PI Part 2

Posted by PRAVEEN KURNI in praveen.kurni3 on Jun 9, 2011 6:23:22 AM
inShare

SCADA Integration with SAP using SAP PI Part 2 Systems Integration In my previous blog, I briefly explained about the systems involved and the business case. Let me share how systems Integration happens in this part. On the high level SAP ERP system will request Tag values for particular SCADA OPC Server Instance, in response OPC Server will reply with Tag values, Quality of the Tag value, Quality of the Tag, OPC Server Status, and Time Stamp. A deep drive in to the Systems Integration: As SAP ERP system makes a request and gets the response, so we made this as Client Proxy communication to SAP PI. On the other hand SAP PI system is connected to OPC Gateway (Technically: OPC Client System) across the Firewall. In OPC Gateway system a standard Web Service is exposed, this will be provided by vendors who supply .NET Wrapper software like MatrikonOPC/Advosol. So SAP PI will consume this Web Service at receiver end. A SOAP request sent by SAP PI will be received by service available in OPC Gateway, now this request has to be passed to OPC Server. In OPC Gateway Web Service request is mapped to a .Net program which will convert HTTP request to COM/DCOM Request and sends the same through ISS to OPC Server. OPC Server will process the request and reply with the necessary Tag Values to OPC Gateway, OPC Gateway will map the response to SOAP response, which will be reached to SAP ERP through Client proxy response. This is how synchronous communication happens between Integrated Systems.

SAP ERP: ERP makes a business request consists of Tag Names: A tag name in terms of SCADA represents a variable to hold various quantitative measures like GCV (Gross Calorific Value), NCV (Net Calorific Value), Pressure, Volume, and Temperature. Each quantitative measure will have its own tag name Because all the data stored in SCADA will be in the form of Tags, ERP system should send relevant Tag Names to get the values. Sample tag names and specific codes for quantitative measures are given in my previous blog. As ERP sends a Proxy request this could be manipulated as a SOAP request by using SOAP Message Protocol as XI, which will point to AAE (Advance Adapter Engine).

OPC Gateway: Clients landscape has 2 OPC Gateway systems. Communication happens with either of the Gateways based on the availability. Each Gateway will be linked to available Instances of SCADA. OPC Gateways are manipulated to handle SOAP request coming from SAP PI and a .Net Client Application (Wrapper Software) in OPC Gateway converts the call in to D[COM] request and sends to OPCSERVER. .NET applications can access OPC servers only through a software layer that is usually called a .NET Wrapper. There are no OPC standard specifications for a .NET interface, so different vendors offer .NET wrapper software with much different interfaces and features. One of the .NET wrapper software we used was ADVOSOL XMLDA.NET wrapper. This supports access to OPC DA and XML DA servers. The Helper classes of wrapper software provide user friendly server access methods for features such as browsing and reading item values.

OPC DA Sample Server & Matrikon OPC Explorer Client Application OPC Gateway (OPC Client Machine) system with ISS installed and .NET wrapper running can be monitored using application called Matrikon OPC Explorer. I have simulated OPC Server and OPC Gateway in my desktop using OPC .NET Sample DA Server Tags and Tag values are maintained here (generally updated by RTUs) and Matrikon OPC Explorer (for OPC Gateway) to view the tags values by installing .NET framework and ISS on Windows OS.

In this OPC DA Sample Server, we can add New Tags, and edit existing Tag properties like Data type, Quality. If this OPC DA Sample Server is connected to RTUs will have real Tags names as I mentioned in my first Blog. Since it is manipulated on my machine to show case the Systems, I could load some dummy Tag names and provide dynamic values in to the Server Instance. [Please note Tag Name in terms of OPC Server is Item ID] Now lets see how to access the Tags available in OPC DA Sample Server in to Matrikon OPC Explorer application: Since I have installed both (OPC DA Sample Server and Matrikon OPC Explorer) on the same host machine, when I open Matrikon OPC Explorer it will automatically detects available OPC Servers on the same host machine. Now we will see how to add the Tags to view the values available in the OPC DA Sample Server Instance in Matrikon OPC Explorer application. Press Add Tags which will open another window, this will allow adding of new Item ID: Tag Name to monitor:

This application (Matrikon OPC Explorer) need to be connected to the OPCSample.OpcDa.20Server.1, to achieve this press Connect button. Once we press this button you can see the Server is connected and Status as Running on the bottom left window with refresh rate.

Now we will see how to add the Tags to view the values available in the OPC DA Sample Server Instance in Matrikon OPC Explorer application.

Press Add Tags which will open another window, this will allow adding of new Item ID: Tag Name to monitor:

Press Browse Menu Item and select Flat Browse as follows:

You can see all the available Tags/Item IDs:

Double click relevant Tags/Item ID you wish to explore, which will be added in to the Tag to be added window.

Now press File -> Update and Return

With this action it will add the Tag to the Matrikon OPC Explorer main window and fetches the value available in: OPCSample.OpcDa.20Server.1 as shown below:

This is how we monitor the Tag values in Matrikon OPC Explorer in OPC Gateway (OPC Client). Other than Matrikon OPC Explorer, you can use any other tools available. Now we see how to get this value with the Web Service request from a web client like SOAPUI testing tool. Web Service and Functions:

With the available Web Service we can Read / Write Tag Values available in OPC Gateways. We can utilizeGetProperties function to get the Tags Properties like Quality and Time Stamp etc. We can utilize GetStatus function to check the status of the Tag value like Active/In-Active.

Once the Web Service is available, this can be used in SAP PI on receiving end. Let us see the Interface details with Read Operation, which will be triggered from SAP ERP TSW in my next blog. I hope this blog provides you little bit knowledge on OPC Gateway and OPC Server Instance.

SCADA Integration with SAP using SAP PI Part 3

Posted by PRAVEEN KURNI in praveen.kurni3 on Jun 9, 2011 6:26:53 AM
inShare

SCADA Integration with SAP using SAP PI Part 3 Interface In my previous blogs, we saw Systems Integration and how they communicate in exchanging Tag values using a testing tool. Let me discuss about the Interface with actual systems involved. I mean Sap ERP TSW, SAP PI, OPC Gateway Systems, and SCADA Servers (OPC Server). Based on the two previous blogs I hope you got an idea on systems involved. If you look in to the Business Case, Interface was demanding communicate with Decentralised SCADA servers. They were 10 instances of SCADA Servers in the Landscape, primarily provided by INVENSYS and TELVENT. All the instances will contain same Tags and Values based on the periodic synchronization of the instances. Our requirement was to fetch the values for specific tags based on the availability of the instances. There were some primary instances which will be given priority and rest of them as redundant instances.

1. 2. 3. 4. 5.

In ERP TSW module this Read Interface has to be executed at a scheduled time every day to get the Tag values and store it in Z Tables. These values are utilized by the module to finalise Allocations, based on which Ticket Creation, Delivery Creation and Billing Creation happens [Refer IMG 1.1: Business Process] in my first blog of this series. So to fetch the tag values in ERP all the Tags relevant to the SCADA server instances are stored in Z Table and used to create a proxy request for Read operation with the relevant tags. Synchronous Communication Onward Journey --> In ERP - TSW module a background program which executes every day at scheduled time sends a client proxy request containing SCADA TAGs to SAP PI. In SAP PI Read Interface is executed which receives client proxy request and transforms message using operation mapping. Resultant of this mapping will be mapped as an Operation Message called ReadSoapIn of Web Service provided by OPC GATEWAYs. Using conditional routing in Read Interface, SAP PI sends to ReadSoapIn operation to available OPC GATEWAY using a SOAP request. In OPC GATEWAY a corresponding Web Service will receive SAP PIs ReadSoapIn request, and sends the request to OPC SERVER in SCADA using .NET program and COM/DCOM technology. Synchronous Communication <-- Return Journey OPC SERVER processes the request and reads the values related to the requested TAGs, and sends response back to OPC GATEWAY.

1.

2. 3. 4.

OPC GATEWAY will send the response using Operation Message ReadSoapOut to SAP PI. SAP PI receives the response using ReadSoapOut Message, this message gets transformed to ERP client proxy response. ERP client proxy program update relevant table with TAG Values for all OPCSERVERS available. TAG Values in table will be used for finalizing allocations, ticket creation, delivery and billing. Now will see abstract of objects which are needed in SAP PI. Sender and Receiver Message Structures with Mappings in PI:

Receiver Determination: In ERP a program controls the flow of Interface, to which Gateway and to which SCADA (OPC Server) request is sent. Based on the source field value the receiver OPC Gateway is determined, and Web Service specifically running for particular OPC Server will be triggered in OPC Gateway based on the request XML.

Receiver Communication Channel:

XML - Request:

XML Response

I hope this blog series helped you in understanding SCADA systems integration with SAP.