Course Notes

Virtual Instrumentation(Subject Code: R09EIE58051/R11EIE1111)

Academic Year: 2013–’14 (II semester)

by

Dr. C. KiranAssociate Professor

Dept. of Electronics & Instrumentation Engg.

VALLURUPALLI NAGESWARA RAO VIGNANA JYOTHIINSTITUTE OF ENGINEERING & TECHNOLOGY

TABLE OF CONTENTS

LIST OF TABLES.................................................................................................. iv

LIST OF FIGURES................................................................................................ v

ACKNOWLEDGEMENTS..................................................................................... vi

SYLLABUS ............................................................................................................ vii

UNIT 1 INTRODUCTION......................................................................... 1

1.1 History of Instrumentation ....................................................................... 1

1.2 Architecture of a Virtual Instrument ........................................................ 3

1.2.1 Sensor Module ............................................................................... 3

1.2.2 Sensor Interface ............................................................................. 4

1.2.3 Database Interface......................................................................... 5

1.2.4 Information System Interface ........................................................ 5

1.2.5 User Interface ................................................................................ 5

1.3 Advantages of using Virtual Instrumentation ........................................... 6

1.4 DataFlow Programming............................................................................ 6

1.4.1 Comparison to Conventional Programming................................... 6

1.4.2 Features of DataFlow Programming.............................................. 6

1.5 Real-time Systems and Embedded Controllers ......................................... 7

1.5.1 Classification of Real-Time Systems.............................................. 8

1.5.2 Real-Time Operating Systems and Environments......................... 9

ii

iii

1.5.3 Embedded Controllers ................................................................... 9

1.6 Open Connectivity (OPC) ........................................................................ 9

1.7 Supervisory Control And Data Acquisition (SCADA).............................. 11

1.7.1 Human-Machine Interface.............................................................. 13

1.8 ActiveX Programming .............................................................................. 13

UNIT A GLOSSARY OF TERMS .............................................................. 15

A.1 Unit 1........................................................................................................ 16

APPENDICES........................................................................................................ 15

BIBLIOGRAPHY................................................................................................... 17

LIST OF TABLES

Table 1.1: Evolutionary phases of virtual instrumentation.................................. 1

Table 1.2: Signal conditioning requirements for various sensors .......................... 4

Table 1.3: Comparison of dataflow programming and conventional programming 7

iv

LIST OF FIGURES

Figure 1.1: Architecture of a Virtual Instrument.................................................. 3

Figure 1.2: Components of the sensor module ...................................................... 3

Figure 1.3: Various methods/protocols of sensor interfacing................................. 4

Figure 1.4: Schematic of a real-time system.......................................................... 7

Figure 1.5: OPC Classic Architecture ................................................................... 10

Figure 1.6: OPC .NET Architecture ..................................................................... 11

Figure 1.7: OPC Unified Architecture................................................................... 11

Figure 1.8: (a) Conceptual block diagram of a SCADA system (b) MonolithicSCADA system (c) Distributed SCADA system (d) NetworkedSCADA system ................................................................................... 13

Figure 1.9: HMI showing multiple monitors communicating through a SCADAsystem................................................................................................. 14

v

ACKNOWLEDGEMENTS

This course notes uses the LATEX template prepared by Dr. Ben Schroder of

Louisiana Tech University, USA. I extend my thanks to him for taking the trouble to

create this template for the benefit of doctoral students who have to ensure that their

Ph.D. dissertation strictly follows the guidelines set by Louisiana Tech University.

vi

SYLLABUS

UNIT I:Virtual Instrumentation: Historical perspective, advantages, block diagram andarchitecture of a virtual instrument, data-flow techniques, graphical programmingin data flow, comparison with conventional programming. Development of VirtualInstrument using GUI, Real-time systems, Embedded Controller, OPC, HMI/SCADAsoftware, ActiveX programming.

UNIT II:VI Programming Techniques: VIs and sub-VIs, loops and charts, arrays, clustersand graphs, case and sequence structures, formula nodes, local and global variables,string and file I/O, Instrument Drivers, Publishing measurement data in the web.

UNIT III:Data Acquisition Basics: Introduction to data acquisition on PC, Samplingfundamentals, Input/Output techniques and buses. ADC, DAC, Digital I/O, countersand timers, DMA, Software and hardware installation, Calibration, Resolution, Dataacquisition interface requirements.

UNIT IV:VI Chassis requirements. Common Instrument Interfaces: Current loop, RS 232C/RS485, GPIB.

UNIT V:Bus Interfaces: USB, PCMCIA, VXI, SCSI, PCI, PXI, Firewire. PXI systemcontrollers, Ethernet control of PXI.

UNIT VI:Networking basics for office & Industrial applications, VISA and IVI.

UNIT VII:VI toolsets, Distributed I/O modules. Application of Virtual Instrumentation:Instrument Control, Development of process database management system

UNIT VIII:Simulation of systems using VI, Development of Control system, Industrial Communi-cation, Image acquisition and processing, Motion control.

vii

CHAPTER 1

INTRODUCTION

This Unit provides an introduction to the undergraduate course on VirtualInstrumentation. The Learning Objectives (LO) for this Unit include:

• Realizing the motivation to choose virtual instrumentation• Learning the basics of a virtual instrumentation system, its configuration,

programming, and the processing of data within a virtual instrumentationsystem

• Appreciating the advantages of graphical programming and using a GUI• Learning the concepts of real-time systems, SCADA, and ActiveX programming

with relevance to Virtual Instrumentation

1.1 History of InstrumentationThe idea of Virtual Instrumentation is the culmination of various technological

breakthroughs from the Industrial Revolution in the early 1930s to the current day;the field continues to evolve as technological advancements in instrumentation andcomputing become available to the industry. Table 1.1 indicates the major phases ofinstrumentation [1].

Phase I involved measurements like the EEG which were recorded on paperand was dominated by instruments such as oscilloscopes, sensors, power supplies, CRTdisplays. Phase II was driven by the advent of relays, PID controllers, integrators, etc.Though digital signal processing started towards the end of this phase, it was limitedto on-board processing in vendor-defined analog systems.

Phase III laid inroads to the idea of a general-purpose computing platform andcreated standards for use in the industry. Ken Olsen’s Digital Equipment Corporation

Table 1.1: Evolutionary phases of virtual instrumentation [1]Phase Period Key Technology

I 1930s–1940s Analog measurement devicesII 1950s Data acquisition & processing devicesIII 1960s–1980s Digital processing on general purpose computing platformIV 1990s–Present Distributed virtual instrumentation

1

2

(DEC) and Hewlett-Packard was a key player in this phase, as it developed theInstrumentation Computer HP 2116A (1966), Instrumentation Coupler/ControllerHP 2570, HP 9100A Calculator, and the HP Interface Bus (HPIB). It was the HP9100A, which was controlled/coupled using HP 2570, that introduced computersto many people including the founder-CEO of Apple Inc., Steve Jobs! HP9100A,which benefited from other interfacing/peripheral HP equipment such as HP2570 andHP9125 plotter, eventually led to the development of more powerful desktop machinesuntil the advent of the IBM PC in 1981.

HP2116A was a 16-bit minicomputer developed with such a forward-lookingprocess architecture that was used by HP for 20 years since then! This InstrumentationComputer, equipped with 16 empty card-slots which can be increased to 48 usingadd-on modules, can interface up to 20 HP instruments including counters, nuclearscalers, electronic thermometers, digital voltmeters, data amplifiers, ac/ohm converters,and input scanners. Further, interface cards were also developed to peripheral devicessuch as teletypewriters, magnetic tape recorders, paper tape readers and punches, andmodems (called “dataphones” then) to the HP2116A. HP2116A is also the first HPsystem to use digital ICs in its design. HP2116A was the brainchild of the ConceptDevelopers Kay Magleby and Paul Stoft (in 1964), while Roy Clay acted as theSoftware Lead for the machine, as outlined by Paul Ely, Jr. in the 1967 HP Journal.HP2116A, which relied on interrupts and i/o modules initially, eventually used DirectMemory Access (DMA) for i/o transfers at the rate of 1.2 MBps. [2]

HP2570, developed based on the work by Geoff Chance and Bob Tinnen at HPLoveland Division in the late 1960s, supported interfacing a variety of HP equipment.The Project Leader of HP2570A, Gibson Anderson, at the Automatic MeasurementDivision at HP, wrote in the 1970 HP Journal: “If computers, instruments, andperipherals could speak, and if they all spoke the same language, there would befew interface problems. Computers tell instruments what to do, and the instrumentswould respond with data.” Eventually, Gerry Nelson and Dave Ricci developed theHPIB in October, 1972, while the HP’s Corporate Interface Engineer Don Loughrywrote how to interface various instruments using the bus. This bus later became theGPIB and then defined the IEEE 488 standard. As IBM PC became available in theearly 1980s, this phase took advantage of the arrival of desktop computing. VirtualInstrumentation reached yet another milestone with the introduction of LabVIEW 1.0for the PC by National Instruments in 1986. Programming of instrument control wasuntil then predominantly done using the BASIC programming language; LabVIEWintroduced graphical user interface (GUI) and visual programming concepts for easierdevelopment of virtual instruments.

Phase IV saw an increase in flexibility and scalability with the rise of theInternet and many private networks and mobile networks. With the assimilation oftechnological advancements in automation and control, instrumentation, programmingand information technology, networking, and so on, virtual instrumentation grewrobust enough to eventually benefit from more advanced concepts such as distributedcomputing and steered itself towards Distributed Virtual Instrumentation systemsthat can communicate across continents!

3

1.2 Architecture of a Virtual InstrumentA Virtual Instrument System is “a software that is used by the user to develop

a computerized test and measurement system” [1]. Thus, each of a real instrument’scomponents are represented by functionally identical software components. Thearchitecture of a generalized virtual instrument is shown in Figure 1.1.

Figure 1.1: Architecture of a Virtual Instrument [1]

1.2.1 Sensor ModuleFigure 1.2 shows the various components of the Sensor Module in general.

Please note that the actual signal conditioning requirements depend on the particularsignal and thus on the particular sensor. Some such requirements are listed in Table 1.2.

Figure 1.2: Components of the sensor module [1]

4

Table 1.2: Signal conditioning requirements for various sensors [?]Process Parameter Transducer Signal Conditioning Methods Em-

ployed

TemperatureRTD Amplification, Filtering/Current or Volt-

age excitationThermistor Amplification, Filtering/Linearization,

Voltage excitationThermocouple High Amplification, Filtering, Cold junc-

tion compensationStrain Strain Gauge Current or Voltage Excitation, Amplifica-

tion, Linearization, Bridge CompensationDisplacement LVDT AC Excitation, Linearization, Demodula-

tion

1.2.2 Sensor InterfaceFigure 1.3 shows the various methods/protocols of interfacing sensors to the

process module.

Figure 1.3: Various methods/protocols of sensor interfacing [1]

Wired Interfaces

Serial Communication Interfaces: Serial communication interfaces enable bit-by-bit transmission of data between two devices. Examples of serial interfaces includethe Universal Serial Bus (USB), FireWire/IEEE 1394, RS 232C or RS 485 may beused to interface the Sensor Module to the Process Module. The particular applicationneed may help choose the best interface that offers the required data transfer speedwithin the stipulated costs. The data transfer rates vary from about 20 kbps for RS232C standard to 10 Gbps for USB 3.1 specification or 20 Gbps for Intel Thunderbolt2 specification.

Parallel Communication Interfaces: Parallel communication enables simultane-ous transfer of multiple bits of information through individual wires bundled together.However, due to the overhead of parallel communication and the signal interferenceissues, serial communication is preferred over parallel communication in most cases.HP Interface Bus (HPIB) or General-Purpose Interface Bus (GPIB) referred to in

5

Section 1.1 may be used to interface and control specific devices. Small ComputerSystem Interface (SCSI) allows communication between hosts and hosts or peripheraldevices to transfer data. Peripheral Component Interconnect (PCI) eXtensions forInstrumentation (PXI) is a modular instrumentation platform to interface varioustest, control, measurement, and automation equipment to the Process Module. VersaModule Europa (VME) eXtensions for Instrumentation (VXI) is a computer busarchitecture that offers an open standard platform for automated testing.

Wireless Interfaces

IEEE 802.11a/b/g/n define the specifications for wireless local area network(WLAN). The latest version, 802.11ad is expected to reach a data transfer rate of up to6912 Mbps. While General Packet Radio Service (GPRS) provides transfer rates of 56–114 kbps on 2G data services over GSM (Global System for Mobile communications),the transfer rates are as high as 1 Gbps for 4G data services. Bluetooth standardversion 4.0 can offer data rates up to 24 Mbps. The advantage of wireless interfacing isthat multiple devices can be connected without requiring any communication channels.

1.2.3 Database InterfaceThe Database Interface provides connectivity between the Database and the

Process Module. Thus, it is defined by software components such as the following:

• Markup Language: The de facto choice is the eXtensible Markup Language(XML), which defines a set of rules for encoding documents in a format that isboth human-readable and machine-readable.

• Database Server: A database management system (DBMS) such as SQL Serveror Oracle are used to store the database(s) and allow data access to its clientsthrough the server.

• Database Connectivity: Typcially, middleware such as Open Database Connectiv-ity (ODBC) and Java Database Connectivity (JDBC), and ActiveX Data Objects(ADO) and Data Access Objects (DAO) provide the necessary connectivity tothe database servers.

1.2.4 Information System InterfaceThe Information System Interface uses User Interface (UI) components such as

ActiveX objects along with more commonplace aspects such as the Uniform ResourceLocator (URL); each virtual instrument is identified uniquely by its URL. This interfacealso provides connectivity between various objects present in the data, so as to enableinteroperability.

1.2.5 User InterfaceThe User Interface (UI) display and control is achieved through text-based

terminals such as using the SMS service for mobile alerts, graphical systems thatdisplay the relevant and necessary data graphically, multi-modal systems that enable

6

sonification and haptic rendering possible (includes touch-screens and audiovisualsystems such as those found at ATMs), and virtual/augmented reality systems whichcan allow data to directly interact with the virtual and/or real world around them.

1.3 Advantages of using Virtual InstrumentationThe use of virtual instrumentation in the industry provides considerable

advantages: [3]• Combining mainstream commercial technologies, such as PC, with flexible

hardware and a wide variety of measurement and control hardware,• Testing, controlling, and designing applications, thereby enabling accurate analog

and digital measurements,• Creating user-defined systems that meet particular application needs,• Improving system productivity, reliability, safety, optimization, and stability in

automated process industries,• Improving efficiency, capability, features of instrumentation, system identification

and control, and• Allowing rapid adaptability.

1.4 DataFlow ProgrammingDataFlow is the software architecture based on the idea that changing the

value of a variable should automatically force recalculating the values of all dependentvariables. The same analogy can also be extended to redrawing images in a graphicalprogram or dynamically change any form of output based on changes in the input [7].

1.4.1 Comparison to Conventional ProgrammingThe Table 1.3 outlines the various advantages of using dataflow programming

over conventional programming.

1.4.2 Features of DataFlow ProgrammingDataFlow programming can be:

• Flow-based,• Cell-based, or• Reactive

Flow-based programming refers to following a flowchart, where the programmingexecuting cannot reach a particular block unless every block that precedes this block isalready executed. Cell-based programming refers to the ability to program individualcells to recalculate the output based on changes in the contents of the cells. A typicalexample is seen in spreadsheets (such as those found in Microsoft Excel) where thechange of a cell’s value will automatically change the values of any/all cells that

7

Table 1.3: Comparison of dataflow programming and conventional programming [13]DataFlow Programming Conventional ProgrammingExecution not possible unless the pro-gram is designed start-to-end

Execution can occur without all inputs,resulting in a run-time error

No coupling-related problems when usingvariables that depend on other variables

Using dependent variables has to bechecked manually or programmaticallyand cannot happen automatically ordynamically

Continuous execution mode and run-timeediting of any inputs possible

Continuous execution and run-time edit-ing of inputs cannot be done once theexecution has started

Every input change can be dynamicallyobserved as a corresponding change inthe output

No input change possible once executionhas started

Inputs need not be known until run-time Programs must know the inputs and howto handle them before execution

Benefits a lot from graphical program-ming, since the flow of data can actuallybe visual

Involves a lot of programming code to beable to see dynamic flow of data

depend on it, even automatically redrawing any/all graphs that use the cell’s value.Reactive programming refers to the automatic recomputing of the output wheneverany of the input values change. [8]

1.5 Real-time Systems and Embedded ControllersA system is said to be real-time if the total correctness of an operation depends

not only upon its logical correctness but also upon the time in which it is performed.[9] Real-time systems are used for mission-critical applications; predictability of thesystem behaviour is the most important concern in most applications. Applicationsof real-time systems include but are not limited to defense systems, space systems,networked multimedia systems, embedded automative electronics such as airport videoterminals, and so on where the state of the system changes with time. (e.g.: Achemical reaction continues even after its controlling computer system is stopped.)[10] The most important aspect of a real-time system would be predictability and notperformance [9].

A schematic block diagram of a real-time system is shown in Figure 1.4.

Figure 1.4: Schematic of a real-time system [10]

8

1.5.1 Classification of Real-Time SystemsReal-time systems may be classified in multiple ways [10]:

1. By characteristic and application:

(a) Hard/Soft/Firm: A missed time-deadline in a hard real-time systemcauses total system failure. Thus, it is important that the response of thesystem is definitely time-sensitive in the order of ms. Examples includecommand and control systems and various traffic control systems. Theusefulness of results of a soft real-time system degrade with time. Forinstance, airline information displayed on multiple terminals in an airportwould be important only at that particular time and is not generally usefulafter a flight’s arrival or departure. Travel reservation systems also serveas examples of soft real-time systems. Sometimes, when the usefulnessof results goes to zero after a certain deadline, such a real-time system issaid to be firm; missing some deadlines is tolerable in this case. [9] Thus,the result has utility even after the deadline has passed in case of a softreal-time system, zero utility in case of a firm real-time system, and zeroutility resulting in a catastrophic failure of the system in case of a hardreal-time system. [10]

(b) Fail-safe/Fail-operational: A system is said to be fail-safe if the systemcan ensure that a failure does zero or minimal harm to the system ofits functions. A fail-operational system continues to operate normallyeven upon encountering a failure. For instance, a launch-on-commandnuclear weapon system is fail-safe while a launch-on-loss-of-communicationsis fail-operational and is undesirable. [11] A simpler example of a fail-safesystem is an electronic/electrical device that is equipped with a fuse thatfails in case of a failure, thereby saving the actual device from failure whilerendering the system non-functional until it is safe to operate again. Inthe context of real-time systems, a fail-operational system may continueto operate in order to meet the real-time deadline even in case of a failurewhile a fail-safe system does not.

2. By design and implementation:

(a) Guaranteed-timelines/Best-effort: A real-time system that works on a best-effort basis does not provide any quality of service or guaranteed deliveryof response, while a guaranteed-timelines system ensures guaranteeddelivery. Thus, a guaranteed-timelines system is more reliable than a best-effort system. For example, the connection-oriented Transmission ControlProtocol (TCP) is a guaranteed-timelines service while the connectionlessInternet Protocol (IP) is a best-effort service. [12]

(b) Resource-adequate/Resource-inadequate: A real-time system with adequateresources would be called a resource-adequate system and thus be morereliable than a resource-inadequate system.

9

1.5.2 Real-Time Operating Systems and EnvironmentsNational Instruments, with LabVIEW version 6, introduced LabVIEW RT

version to design real-time systems using LabVIEW; LabVIEW RT is now an add-on module in LabVIEW. In a system that has a non-RTOS (Real-Time OperatingSystem), the latency is longer because of many other active tasks that run in orderto keep the OS running. The execution time is reduced from the order of ms tomicroseconds using LabVIEW RT. An RTOS is optimized to take full advantage ofthe hardware to get the most stable timing performance. Loop prioritization is doneby RTOS and critical operations override normal/other operations. System clock canbe synchronized to microseconds instead of ms in systems running RTOS. In order tokeep the latency to a minimum, a daughter computer/application processor hardwarethat runs the RTOS is connected to a non-RTOS host computer which shows theUser Interface (UI) through a wired or wireless link. This kind of set up also helpsimmunize the real-time system from failures of the host computer [13].

RTOS is used to provide specific services to applications, using real-timescheduling policies, inter-process communication, and run-time monitoring. Examplesof RTOS include RT-Mach, VxWORKS, Solaris, and Lynx [10].

1.5.3 Embedded ControllersEmbedded controllers are commonly microcontrollers that have real-time

computing capabilities and may be general-purpose or custom-made for specificapplications. Digital Signal Processors (DSP) are a common class of dedicated, real-time embedded controllers. Embedded controllers have the advantages of betterperformance, better reliability, smaller size, and lesser complexity, and enable batchproduction thereby reducing the manufacturing costs too. An embedded system mayhave a single microcontroller or multiple units, peripherals, or networks inside a largerchassis or enclosure [14].

1.6 Open Connectivity (OPC)Industrial automation systems require open standards which can be adopted by

any provider of control systems, instrumentation, and process control for multi-vendorinteroperability. Object Linking and Embedding (OLE) was a Microsoft technologythat allowed linking and embedding documents to other objects. The evolution ofOLE started, in 1990, on the top of Dynamic Data Exchange (DDE) concept ofMicrosoft, and was later reimplemented with Microsoft Component Object Model(COM) and then Distributed COM (DCOM) as its bases, and eventually led toActiveX controls. Interoperability of OLE objects requires the development and useof a software component that understands OLE objects.

The concept of OLE was extended to process control and eventually led tothe founding of OLE for Process Control (OPC) Foundation in 1996 with majorplayers in the automation industry coming together. The essential aim was to create acommunication standard that is widely acceptable such that it enables data exchangeamong devices/control applications manufactured/developed by different vendors. The

10

OPC Foundation officially renamed itself to “Open Platform Communications” andworks with the tagline “Open Productivity & Connectivity”. [15] OPC thus enablesthe communication of real-time plant data between control devices/applicationsfrom different manufacturers in the industrial automation industry, extending itsapplications to process control, discrete manufacturing, and building automation.

The latest version of OPC, version 1.02 which is available since August 16,2013, uses XML, .NET framework, and OPC’s own binary-coded TCP format alongwith OLE. Standards are specified for “the acquisition and control of process data,alarm and event records, historical data, and batch data to multi-vendor enterprisesystems and between production devices” (sensors, instruments, PLCs, RTUs, DCSs,HMIs, historians, trending subsystems, alarm subsystems and more as used in theprocess industry, manufacturing), “and in acquiring and transporting oil, gas andminerals” [15]. The OPC Foundation also provides certification program for vendorsto test their compliance to open standards.

OPC now is moving towards Unified Architecture (UA) to enable enterprise-wide data sharing and communication across embedded systems, controllers, mobilephones, workstations, servers, and other enterprise-standard hardware. The idea ofinteroperability is defined as between device to device, device to software, softwareto software, UA to UA, UA to OPC Classic, and OPC Classic to UA. The OPC-UAenables vendors to implement OPC on non-Microsoft systems and embedded devices.OPC Express Interface (Xi) or more recently known as OPC .NET, based on WindowsCommunication Foundation (WCF) of Microsoft .NET framework, is also supported.Figure 1.5 depicts the OPC Classic Architecture, Figure 1.6 shows the OPC .NET,and Figure 1.7 shows the newer OPC-UA at work. These block diagrams indicate howOPC can make seamless interoperability possible across various devices, applications,and systems.

Figure 1.5: OPC Classic Architecture [15]

11

Figure 1.6: OPC .NET Architecture [15]

Figure 1.7: OPC Unified Architecture [15]

1.7 Supervisory Control And Data Acquisition (SCADA)SCADA is used to monitor and control an industrial plant from a central

location. The main constituents of a SCADA system [16] include:• Remote Telemetry/Terminal Units (RTU),• Human-Machine Interfaces (HMI), and• Communications

Other constituents of a SCADA system include: a telemetry system to connectPLCs and RTUs to control centres, data warehouses, and the enterprise; a dataacquisition (DAQ) server to allow clients to access data from PLCs, RTUs, and otherfield devices using standard protocols; a Historian to accumulate time-stamped datato compute and display trends; a supervisory computer; and process and analyticalinstrumentation. [17]

RTUs collect on-site information, converts sensor signals to digital data, andsends the data to a central location using communication elements. RTUs can alsoreceive information from the central location through these communication elements.[16] The programmable capabilties of RTUs include implementation of ladder logicfor boolean operations.

12

Use of Programmable Logic Controllers (PLCs) instead of RTUs offers theadvantages of being economical, versatile, flexible, configurable, and also offer moresophisticated embedded control capabilities [17]; they allow multiple programmableformats such as standard statements, ladder logic, or the use of functional blockdiagrams. Thus, PLCs are more common today as “field devices” in a SCADA system.

HMIs display relevant and necessary information using GUI. The HMI usuallycomprises of a high-end computer system that is capable of displaying high-qualitygraphics and running advanced and complex software. [16]

Communication elements include wired interfaces such as leased telephonelines, local-area networks (LAN), data cables and buses between systems; optical fibrecable (OFC) to transmit data over longer distances; radios, cellular, or microwave forwireless communication; and wide-area networks (WAN), or VSAT (satellite) for verylong-distance communication. Signal conditioners as well as data converters such asanalog to digital converters (ADC) or digital to analog converters (DAC) or mediaconverters (MC) to convert electrical signals to optical signals and vice versa are alsoa part of the communication elements in a SCADA system.

SCADA systems offer the advantages of:• coordinating processes in real-time,• reduced labour cost,• improvement in plant performance,• time-saving due to central availability and accessibility of all data,• user-friendliness and ease of use,• displaying trends of variables over time dynamically or from the past data,

SCADA systems have been evolving since the days of mainframe computingwhere a bus connected a SCADA system to the mainframe (“Monolithic”), to the dayswhere the SCADA system was connected to multiple computers and devices whichcommunicated through LAN but still worked in their own proprietary environment(“Distributed”), to the current times where SCADA systems could benefit fromplatform-independent communication and open standards (OPC) could enable betternetworking and control (“Networking”). Figure 1.8 shows a simple SCADA system[18] along with the three generations of SCADA systems [19]. With new networkingprotocols and standards and with the advent of cloud computing, SCADA systemsmarch into the fourth generation (“Internet of Things”). [17]

13

Figure 1.8: (a) Conceptual block diagram of a SCADA system [18] (b) MonolithicSCADA system (c) Distributed SCADA system (d) Networked SCADA system [19]

1.7.1 Human-Machine InterfaceA Human-Machine Interface (HMI), earlier called the Man-Machine Interface

(MMI), is the interface that separates the machine from the operator. A properlydesigned HMI must provide ease of use to the end-user while offering efficientfunctionality to the developer. Typical operator interfaces must be designed inso that the data is categorically presented in a way that does not overwhelm orconfuse the operator. Such design considerations are of prime importance since mostHMI show process-critical data, an error in which requires the operator to act withminimal delay. While HMI is usually local to one machine, a SCADA system maybring forth and present various individual HMIs to a single operator. A schematic ofa SCADA-enabled HMI system is shown in Figure 1.9.

14

Figure 1.9: HMI showing multiple monitors communicating through a SCADA system[18]

1.8 ActiveX ProgrammingMicrosoft’s ActiveX is built on the top of Component Object Model (COM)

and Object Linking and Embedding (OLE). An ActiveX Control provides specificfunctionality to an application and can be designed for use by multiple applicationson the host system. ActiveX controls can be programmed using C, C++, VisualStudio .NET, or C# to implement various interfaces. ActiveX controls require nativeor emulated Windows environment for execution, and are commonly used in mostMicrosoft Windows native applications such as the Windows Media Player, as well asMicrosoft Office, Microsoft Visual Studio, and Windows Internet Explorer.

ActiveX may be defined as a set of rules for how applications should shareinformation. ActiveX controls are more powerful than Java applets because ActiveXcontrols have access to the OS environment and thus have wider functionality. EachActiveX object is identified with a unique Class Identifier (CLSID).

APPENDIX A

GLOSSARY OF TERMS

15

16

A.1 Unit 1

1. Virtual Instrument: “A software that is used by the user to develop acomputerized test and measurement system.” [1]

(OR)“Industry-standard computers equipped with user-friendly application software,cost-effective hardware, and driver software that together perform the functionsof traditional instruments.” [4]

(OR)“A general-purpose computer software to mimic real instruments with theirdedicated controls and displays but with added versatility that comes with thesoftware.” [5]

(OR)“Computer software and modular hardware, all combined and configured toemulate the function of traditional hardware instrumentation.” [6]

2. DataFlow Programming: DataFlow programming is a programming paradigmthat models a program as a directed graph of the data flowing between operations,which run as soon as all of their inputs become valid. [8]

3. LabVIEW: Laboratory Virtual Instrument Engineering Workbench. [4]

4. Graphical Programming: Programming using a Graphical User Interface(GUI) instead of typing/writing plain-text programming code to carry out therequired programmatic operations.

5. Real-time Systems: “A system is said to be real-time if the total correctnessof an operation depends not only upon its logical correctness but also upon thetime in which it is performed.” [9]

6. Latency: The time lag taken by an application to actually execute. Latencydepends on all the active tasks running at the time of execution. [13]

7. Embedded Controller: “An embedded system or controller is a computersystem with a dedicated function within a larger mechanical or electrical system,often with real-time computing constraints.” [14]

BIBLIOGRAPHY

[1] Sumathi, S.; Surekha, P., “LabVIEW based Advanced Instrumentation Systems”,

Springer-Verlag, Berlin Heidelberg (2007). (ISBN: 9783540485001)

[2] http://www.hp9825.com/, Last accessed on: January 31, 2014.

[3] J. Jerome, “Virtual Instrumentation Using LabVIEW”, Prentice-Hall India

Learning (2010). (ISBN: 9788120340305)

[4] National Instruments, http://www.ni.com/, Last accessed on: February 01,

2014.

[5] Johnson, G.W.; Jennings, R., “LabVIEW Graphical Programming”, 4th edition,

McGraw-Hill Education (India) Pvt. Ltd. (2006). (ISBN: 9781259005336)

[6] Travis, J.; King, J., “LabVIEW for Everyone: Graphical Programming Made

Easy and Fun”, 3rd edition, Prentice-Hall (2007). (ISBN: 9780131856721)

[7] “Dataflow”, http://en.wikipedia.org/wiki/Dataflow, Last accessed on:

February 09, 2014.

[8] “Dataflow Programming”, http://en.wikipedia.org/wiki/Dataflow_

programming, Last accessed on: February 01, 2014.

[9] “Real-Time Systems”, http://en.wikipedia.org/wiki/Real-time_systems,

Last accessed on: February 01, 2014.

[10] Juvva, K., “Real-Time Systems: Dependable Embedded Systems” (1998),

http://www.ece.cmu.edu/~koopman/des_s99/real_time/index.html, Last

accessed on: February 07, 2014.

[11] “Fail-operational”, http://en.wikipedia.org/wiki/Fail-operational, Last

accessed on: February 09, 2014.

[12] “Best-effort Delivery”, http://en.wikipedia.org/wiki/Best-effort, Last

17

18

accessed on: February 09, 2014.

[13] Gupta, S.; John, J., “Virtual Instrumentation Using LabVIEW”, 2nd edition,Tata

McGraw-Hill Education Pvt. Ltd. (2010). (ISBN: 9780070700284)

[14] “Embedded System”, http://en.wikipedia.org/wiki/Embedded_system,

Last accessed on: February 01, 2014.

[15] http://www.opcfoundation.org/, Last accessed on: February 09, 2014.

[16] http://www.plcmanual.com/scada-systems, Last accessed on: February 09,

2014.

[17] “SCADA”, http://en.wikipedia.org/wiki/SCADA, Last accessed on: Febru-

ary 09, 2014.

[18] http://electrical-engineering-portal.com/

an-introduction-to-scada-for-electrical-engineers-beginners,

Last accessed on: February 09, 2014.

[19] http://electrical-engineering-portal.com/

three-generations-of-scada-system-architectures, Last accessed

on: February 09, 2014.