You are on page 1of 50

An objectobject-oriented design approach for SCADA kernel

Author
Truong Dinh Chau, Chau, Ph.D Ho Chi Minh City Univ. of Tech. chau.truong@hcmut.edu.vn chau.truong@hcmut.edu.vn chau.truong@me.com chau.truong@me.com (+84 (+84) 84) (0 (0)91. 91. 543543-7474-40 linkedin.com/in/truongdinhchau

Topics
Overview of SCADA software in industrial market Design principle of SCADA kernel A hierarchical object model of SCADA kernel Description of objects in the kernel Approaches for connection with control devices Hierarchical technique Serialization Soft link between components in the kernel Simple demos on several Protocols

Objectives
Have a glance inside structure of SCADA software Understand working mechanisms of components in SCADA software Understand connection mechanisms of SCADA software with control devices Be able to assess a SCADA software Be able to choose a SCADA software for your project

Demo

SCADA Overview: Functions


Information data acquisition from controllers located in the low level Saving the obtained data in storages Processing of obtained information Graphical interpretation Receiving command from operator and transfer them to controllers Event registration regarding to control process and personal actions Prevention or notification about events and alarms Reporting Data exchange with enterprise automated control systems Direct automatic control of processes

SCADA Overview: Keywords


Graphics displays, tools >> Tag >> Alarms, Events Trends: Real-time, historical >> Report >> I/O driver, I/O server >> Protocol supports: Process centric & Remote centric >> Real-time, Multitasking >> Openness, Scalability, Data access, Database >> Networking, Client/server distributed processing >> Fault tolerance, Redundancy, Communication recovery >>

Functions of the Kernel


The developed Kernel of the system solves and consists of some key tasks, techniques and properties: Configuration a project and serialization into XML format Serialization the project configuration from XML format and running the project Techniques for connection of SCADA with control devices Real-time and multitasking Data access

Design principle

Illustration: XML file

Component of the Kernel

Illustration: AnalogInput.cs

Hierarchical Architecture of Kernel

Illustration: Project file structure

Approaches for connection with control devices

Illustration: Devices

Direct drivers

Higher level object space

Device A Device B

I/O Device A

I/O Device B

Device C

I/O Device C

SCADA
Illustration: Modbus Device

Direct drivers
User C/C++/C# code

Driver A - DLL

I/O Device A

General part (EXE)

Driver B - DLL

I/O Device B

Driver C - DLL
Specific part

I/O Device C

SCADA

DLL approach
EXE
Tag Tag DAQ Tasks Tag Tag
bool Config() { ... } bool Reconfig() { ... } float ReadAnalogInput(int Channel) { ... } bool WriteAnalogInput(int Channel, float Data) { ... }

DLL

Tag

DLL approach
EXE
Tag Tag DAQ Tasks Tag Tag

DLL
bool Config( ) { ... } bool Config( ) { ... } Run( ) { }

Tag Tag Tag Tag

...

Tag

Tag

DLL approach
EXE
Tag Tag DAQ Tasks Tag Tag

DLL
bool Config() { ... } bool Reconfig() { ... } float Read( DWORD Channel) { ... }

Tag Tag Tag Tag

Tag

bool Write(DWORD Channel, float Data) Tag { ... } DAQ Tasks

Connect with DDE Servers

Illustration: Connect with Excel cells

SCADA

SCADA

Server 1 Group Group 12 Item 1 Item 2 Item 3


OPC Server

Server 2 Group Group 12 Item 1 Item 2 Item 1

Item 1

Device 1 Tag 1 Tag 2 Tag 3

Device 2 Tag 1 Tag 2

Illustration: Connect OFS, S7-200 PCAccess PCAccess, Communication recovery

Connect with OPC Servers

Component Task

Illustration: Task.cs

Component Display

Illustration: AnimationSymbol.cs, Display.cs

Hierarchical technique

Illustration: MySCADA.Liquidate(),

Serialization

Illustration: SCADA.Serialize(),

Soft link technique

Soft link technique

Illustration: Runtime Tag remove

Network supports

>>

Illustration: C# Modbus TCP/IP Client

Appendix: I/O Tag quantity and Price


Description Vijeo Citect, Full, 75 Points Vijeo Citect, Full, 150 Points Vijeo Citect, Full, 500 Points Vijeo Citect, Full, 1500 Points Vijeo Citect, Full, 5000 Points Vijeo Citect, Full, 15000 Points Vijeo Citect, Full, Unlimited Points Europ. Europ. Ref. Price Removed Removed Removed Removed Removed Removed Removed USD Ref. Price Removed Removed Removed Removed Removed Removed Removed

<<

Appendix: Graphics interfaces, tools


Run applications: GeniDAQ as a simple SCADA software Intouch: easily to develop an application Citect uses Symbols, Genie and SuperGenie PowerLogic SCADA for electrical distribution
ClearSCADA: Vector graphic

<<

Appendix: Realtime and Historycal Trends


Run applications: Realtime and Historical Trends with GeniDAQ, Realtime and Historical Trends with Intouch, Realtime Trend and Process Analyst with Citect

<<

Appendix: Reports
ASCII report in Citect >> HTML report in Citect >> Excel report in Citect >>

<<

Appendix: I/O Drivers and I/O Servers


DLL files in GeniDAQ >> DLL files in Citect >> Intouch: DDE-oriented RSView32: DDE, OPC -oriented ClearSCADA: Telemetry-oriented

<<

Appendix: Process centric & Remote centric

Appendix: Process centric & Remote centric

Appendix: Modbus vs. DNP3


The Polling Process Master and Slave Relationship
Traditionally, protocols are based on Master and Slave relationship; The Master sends a request, the slave response; For large IO networks, data payload is huge and response time could be slow.
iSCS Software RTU 1 2 3 4 5 6 7 8 Poll 1 2 3 4 5 6 7 8 Poll 1 2 3 4 5 6 7 8 Poll

Status Points

Appendix: Modbus vs. DNP3


Slow Cycle Time The larger the network, The Slower
When a network is large, if the communication medium is serial, the time before each controller is polled may be long.
request

response request

response request

response

Appendix: Modbus vs. DNP3


Missed Events Blind to Fast Changing Events
Slow Cycle Time could result in Missed Events Suppose the Master is not polling only one slave but many, there is a high chance that high speed events will be missed.
iSCS Software RTU 1 2 3 4 5 6 7 8 Poll

During this period, master is polling other slaves on same media.

Poll 1 2 3 4 5 6 7 8

PACs 3 3 3 NOT Detected!!

Status of 3 Changed

Appendix: Modbus vs. DNP3


Event Time Inaccurate Sequence of Events
With process protocols, because of cycle polling, all status or measured changes are detected by SCADA at the same time; The time in which the alarm occurs on screen is not the true time of the event change on location.

All hell broke loose at 14:44:33.

Polling request at 14:47:00

Coolant Pressure Low Fuel Pressure Low Alarm Pump Overheat Alarm Fire Alarm
Polling response at 14:47:01

Which occurred First??

Appendix: Modbus vs. DNP3


Reliance on Network Suitable for Process and small Locale Only
Process protocols relies heavily on network high availability; Suitable for closed industrial environment;

Appendix: Modbus vs. DNP3


Reliance on Network Not suitable for Unstable Network
Process protocols not recommend to be used with network that offers limited bandwidth and intermittent connections; High disconnection rate of network will result in data loss; Limited bandwidth will caused device communication timeout.

GPRS/EDGE/3G

Appendix: Modbus vs. DNP3


Not automatic backback-filling
Data logged in RTU during transmission loss is not back-filled in SCADA when communication resumes

Data

Time

Appendix: Modbus vs. DNP3


Event Updates Slaves interrupt Masters
Telemetry Protocol Behaviour With such protocols, Slaves interrupts the master immediately when there is change; This is known as unsolicited messages in DNP or balanced mode in IEC.
RTU 1 RTU 2 SCADA

3 3 5

Status of 5 Changed Status of 3 Changed

Appendix: Modbus vs. DNP3


Event Poll Response. Bandwidth Savings Event Polling
Where unsolicited or balanced mode is not suitable, we can set the communication to behave like in a traditional master-poll-slave mode; The uniqueness of telemetry protocol is, we can poll for changes. We do not need to poll all points, this reduces bandwidth consumption greatly.

Poll Res

Time

Poll 1 2 3 4 5 6 7 8 Res Poll 1 2 3 4 5 6 7 8 5 7 Res

Appendix: Modbus vs. DNP3


Sequence of Events. Time Stamping
Telemetry Protocol with Time Stamps DNP, IEC-101 and IEC-104 protocol supports timestamps to help build an accurate sequence of events.

All hell broke loose at 14:44:33.

Fire Alarm 14:40:17 445 msec Coolant Pressure Low 14:42:45 238 msec Pump Overheat Alarm 14:43:03 225 msec Fuel Pressure Low Alarm 14:43:03 658 msec

Appendix: Modbus vs. DNP3


Automatic backback-filling
Data logged in RTU during transmission loss is back-filled in SCADA when communication resumes Illustration on ClearSCADA and M340 RTU

Data

Time

<<

Appendix: Realtime. Multitasking


Reatime and Multitasking in GeniDAQ

<<

Appendix: Data access


Excel connects with Citect Excel connects with Intouch Intouch connects with Citect

<<

Appendix: Distributed Architecture

<<

Appendix: Distributed Architecture

Individual tasks may be enabled on a single


Report Server Client Alarm Server Trend Server I/O Server

server or distributed using a Client/Server architecture

Report Server

Alarm Server

Trend Server

I/O Server

Client

<<

Appendix: Fault tolerance. Communication recovery


Divide on zero in GeniDAQ Divide on zero in Intouch Divide on zero in Citect Citect communicates with S7-200 via direct driver Intouch communicates with S7-200 via OPC Server Citect communicates with S7-200 via OPC Server

<<

<< Click to edit Master title style

Thank you for your attention