Course Notes

Virtual Instrumentation
(Subject Code: R09EIE58051/R11EIE1111)
Academic Year: 201314 (II semester)

by

Dr. C. Kiran
Associate Professor Dept. of Electronics & Instrumentation Engg.

VALLURUPALLI NAGESWARA RAO VIGNANA JYOTHI INSTITUTE OF ENGINEERING & TECHNOLOGY

TABLE OF CONTENTS
LIST OF TABLES.................................................................................................. iv LIST OF FIGURES................................................................................................ v ACKNOWLEDGEMENTS..................................................................................... vi SYLLABUS ............................................................................................................ vii UNIT 1 1.1 1.2 INTRODUCTION ......................................................................... 1 History of Instrumentation ....................................................................... 1 Architecture of a Virtual Instrument ........................................................ 3 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.3 1.4 Sensor Module ............................................................................... 3 Sensor Interface ............................................................................. 4 Database Interface......................................................................... 5 Information System Interface ........................................................ 5 User Interface ................................................................................ 5

Advantages of using Virtual Instrumentation ........................................... 6 DataFlow Programming............................................................................ 6 1.4.1 1.4.2 Comparison to Conventional Programming................................... 6 Features of DataFlow Programming.............................................. 6

1.5

Real-time Systems and Embedded Controllers ......................................... 7 1.5.1 1.5.2 Classication of Real-Time Systems.............................................. 8 Real-Time Operating Systems and Environments......................... 9 ii

iii 1.5.3 1.6 1.7 Embedded Controllers ................................................................... 9

Open Connectivity (OPC) ........................................................................ 9 Supervisory Control And Data Acquisition (SCADA).............................. 11 1.7.1 Human-Machine Interface.............................................................. 13

1.8 UNIT A

ActiveX Programming .............................................................................. 13 GLOSSARY OF TERMS .............................................................. 15

A.1 Unit 1........................................................................................................ 16 APPENDICES........................................................................................................ 15 BIBLIOGRAPHY................................................................................................... 17

LIST OF TABLES
Table 1.1: Table 1.2: Table 1.3: Evolutionary phases of virtual instrumentation.................................. 1 Signal conditioning requirements for various sensors .......................... 4 Comparison of dataow 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 Unied Architecture................................................................... 11 Figure 1.8: (a) Conceptual block diagram of a SCADA system (b) Monolithic SCADA system (c) Distributed SCADA system (d) Networked SCADA system ................................................................................... 13 Figure 1.9: HMI showing multiple monitors communicating through a SCADA system ................................................................................................. 14

ACKNOWLEDGEMENTS
A This course notes uses the L TEX template prepared by Dr. Ben Schr oder of

Louisiana Tech University, USA. I extend my thanks to him for taking the trouble to create this template for the benet 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 and architecture of a virtual instrument, data-ow techniques, graphical programming in data ow, comparison with conventional programming. Development of Virtual Instrument using GUI, Real-time systems, Embedded Controller, OPC, HMI/SCADA software, ActiveX programming. UNIT II: VI Programming Techniques: VIs and sub-VIs, loops and charts, arrays, clusters and graphs, case and sequence structures, formula nodes, local and global variables, string and le I/O, Instrument Drivers, Publishing measurement data in the web. UNIT III: Data Acquisition Basics: Introduction to data acquisition on PC, Sampling fundamentals, Input/Output techniques and buses. ADC, DAC, Digital I/O, counters and timers, DMA, Software and hardware installation, Calibration, Resolution, Data acquisition 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 system controllers, Ethernet control of PXI. UNIT VI: Networking basics for oce & 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 Communication, Image acquisition and processing, Motion control.

vii

CHAPTER 1 INTRODUCTION
This Unit provides an introduction to the undergraduate course on Virtual Instrumentation. The Learning Objectives (LO) for this Unit include: Realizing the motivation to choose virtual instrumentation Learning the basics of a virtual instrumentation system, its conguration, programming, and the processing of data within a virtual instrumentation system 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 Instrumentation The idea of Virtual Instrumentation is the culmination of various technological breakthroughs from the Industrial Revolution in the early 1930s to the current day; the eld continues to evolve as technological advancements in instrumentation and computing become available to the industry. Table 1.1 indicates the major phases of instrumentation [1].

Phase I involved measurements like the EEG which were recorded on paper and was dominated by instruments such as oscilloscopes, sensors, power supplies, CRT displays. 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 limited to on-board processing in vendor-dened analog systems. Phase III laid inroads to the idea of a general-purpose computing platform and created standards for use in the industry. Ken Olsens Digital Equipment Corporation

Phase I II III IV

Table 1.1: Evolutionary phases of virtual instrumentation [1] Period Key Technology 1930s1940s Analog measurement devices 1950s Data acquisition & processing devices 1960s1980s Digital processing on general purpose computing platform 1990sPresent Distributed virtual instrumentation

2 (DEC) and Hewlett-Packard was a key player in this phase, as it developed the Instrumentation Computer HP 2116A (1966), Instrumentation Coupler/Controller HP 2570, HP 9100A Calculator, and the HP Interface Bus (HPIB). It was the HP 9100A, which was controlled/coupled using HP 2570, that introduced computers to many people including the founder-CEO of Apple Inc., Steve Jobs! HP9100A, which beneted from other interfacing/peripheral HP equipment such as HP2570 and HP9125 plotter, eventually led to the development of more powerful desktop machines until the advent of the IBM PC in 1981. HP2116A was a 16-bit minicomputer developed with such a forward-looking process architecture that was used by HP for 20 years since then! This Instrumentation Computer, equipped with 16 empty card-slots which can be increased to 48 using add-on modules, can interface up to 20 HP instruments including counters, nuclear scalers, electronic thermometers, digital voltmeters, data ampliers, ac/ohm converters, and input scanners. Further, interface cards were also developed to peripheral devices such as teletypewriters, magnetic tape recorders, paper tape readers and punches, and modems (called dataphones then) to the HP2116A. HP2116A is also the rst HP system to use digital ICs in its design. HP2116A was the brainchild of the Concept Developers Kay Magleby and Paul Stoft (in 1964), while Roy Clay acted as the Software 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 Direct Memory Access (DMA) for i/o transfers at the rate of 1.2 MBps. [2] HP2570, developed based on the work by Geo Chance and Bob Tinnen at HP Loveland Division in the late 1960s, supported interfacing a variety of HP equipment. The Project Leader of HP2570A, Gibson Anderson, at the Automatic Measurement Division at HP, wrote in the 1970 HP Journal: If computers, instruments, and peripherals could speak, and if they all spoke the same language, there would be few interface problems. Computers tell instruments what to do, and the instruments would respond with data. Eventually, Gerry Nelson and Dave Ricci developed the HPIB in October, 1972, while the HPs Corporate Interface Engineer Don Loughry wrote how to interface various instruments using the bus. This bus later became the GPIB and then dened the IEEE 488 standard. As IBM PC became available in the early 1980s, this phase took advantage of the arrival of desktop computing. Virtual Instrumentation reached yet another milestone with the introduction of LabVIEW 1.0 for the PC by National Instruments in 1986. Programming of instrument control was until then predominantly done using the BASIC programming language; LabVIEW introduced graphical user interface (GUI) and visual programming concepts for easier development of virtual instruments. Phase IV saw an increase in exibility and scalability with the rise of the Internet and many private networks and mobile networks. With the assimilation of technological advancements in automation and control, instrumentation, programming and information technology, networking, and so on, virtual instrumentation grew robust enough to eventually benet from more advanced concepts such as distributed computing and steered itself towards Distributed Virtual Instrumentation systems that can communicate across continents!

3 1.2 Architecture of a Virtual Instrument A 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 instruments components are represented by functionally identical software components. The architecture of a generalized virtual instrument is shown in Figure 1.1.

Figure 1.1: Architecture of a Virtual Instrument [1]

1.2.1 Sensor Module Figure 1.2 shows the various components of the Sensor Module in general. Please note that the actual signal conditioning requirements depend on the particular signal and thus on the particular sensor. Some such requirements are listed in Table 1.2.

Figure 1.2: Components of the sensor module [1]

Table 1.2: Signal conditioning requirements for various sensors [?] Process Parameter Transducer Signal Conditioning Methods Employed RTD Amplication, Filtering/Current or VoltTemperature age excitation Thermistor Amplication, Filtering/Linearization, Voltage excitation Thermocouple High Amplication, Filtering, Cold junction compensation Strain Strain Gauge Current or Voltage Excitation, Amplication, Linearization, Bridge Compensation Displacement LVDT AC Excitation, Linearization, Demodulation 1.2.2 Sensor Interface Figure 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 bitby-bit transmission of data between two devices. Examples of serial interfaces include the Universal Serial Bus (USB), FireWire/IEEE 1394, RS 232C or RS 485 may be used to interface the Sensor Module to the Process Module. The particular application need may help choose the best interface that oers the required data transfer speed within the stipulated costs. The data transfer rates vary from about 20 kbps for RS 232C standard to 10 Gbps for USB 3.1 specication or 20 Gbps for Intel Thunderbolt 2 specication. Parallel Communication Interfaces: Parallel communication enables simultaneous transfer of multiple bits of information through individual wires bundled together. However, due to the overhead of parallel communication and the signal interference issues, 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 specic devices. Small Computer System Interface (SCSI) allows communication between hosts and hosts or peripheral devices to transfer data. Peripheral Component Interconnect (PCI) eXtensions for Instrumentation (PXI) is a modular instrumentation platform to interface various test, control, measurement, and automation equipment to the Process Module. Versa Module Europa (VME) eXtensions for Instrumentation (VXI) is a computer bus architecture that oers an open standard platform for automated testing. Wireless Interfaces IEEE 802.11a/b/g/n dene the specications for wireless local area network (WLAN). The latest version, 802.11ad is expected to reach a data transfer rate of up to 6912 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 standard version 4.0 can oer data rates up to 24 Mbps. The advantage of wireless interfacing is that multiple devices can be connected without requiring any communication channels. 1.2.3 Database Interface The Database Interface provides connectivity between the Database and the Process Module. Thus, it is dened by software components such as the following: Markup Language: The de facto choice is the eXtensible Markup Language (XML), which denes a set of rules for encoding documents in a format that is both human-readable and machine-readable. Database Server: A database management system (DBMS) such as SQL Server or Oracle are used to store the database(s) and allow data access to its clients through the server. Database Connectivity: Typcially, middleware such as Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC), and ActiveX Data Objects (ADO) and Data Access Objects (DAO) provide the necessary connectivity to the database servers.

1.2.4 Information System Interface The Information System Interface uses User Interface (UI) components such as ActiveX objects along with more commonplace aspects such as the Uniform Resource Locator (URL); each virtual instrument is identied uniquely by its URL. This interface also provides connectivity between various objects present in the data, so as to enable interoperability. 1.2.5 User Interface The User Interface (UI) display and control is achieved through text-based terminals such as using the SMS service for mobile alerts, graphical systems that display the relevant and necessary data graphically, multi-modal systems that enable

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

1.3 Advantages of using Virtual Instrumentation The use of virtual instrumentation in the industry provides considerable advantages: [3] Combining mainstream commercial technologies, such as PC, with exible hardware and a wide variety of measurement and control hardware, Testing, controlling, and designing applications, thereby enabling accurate analog and digital measurements, Creating user-dened systems that meet particular application needs, Improving system productivity, reliability, safety, optimization, and stability in automated process industries, Improving eciency, capability, features of instrumentation, system identication and control, and Allowing rapid adaptability.

1.4 DataFlow Programming DataFlow is the software architecture based on the idea that changing the value of a variable should automatically force recalculating the values of all dependent variables. The same analogy can also be extended to redrawing images in a graphical program or dynamically change any form of output based on changes in the input [7]. 1.4.1 Comparison to Conventional Programming The Table 1.3 outlines the various advantages of using dataow programming over conventional programming.

1.4.2 Features of DataFlow Programming DataFlow programming can be: Flow-based, Cell-based, or Reactive Flow-based programming refers to following a owchart, where the programming executing cannot reach a particular block unless every block that precedes this block is already executed. Cell-based programming refers to the ability to program individual cells to recalculate the output based on changes in the contents of the cells. A typical example is seen in spreadsheets (such as those found in Microsoft Excel) where the change of a cells value will automatically change the values of any/all cells that

Table 1.3: Comparison of dataow programming and conventional programming [13] DataFlow Programming Conventional Programming Execution not possible unless the pro- Execution can occur without all inputs, gram is designed start-to-end resulting in a run-time error No coupling-related problems when using Using dependent variables has to be variables that depend on other variables checked manually or programmatically and cannot happen automatically or dynamically Continuous execution mode and run-time Continuous execution and run-time editediting of any inputs possible ing of inputs cannot be done once the execution has started Every input change can be dynamically No input change possible once execution observed as a corresponding change in has started the output Inputs need not be known until run-time Programs must know the inputs and how to handle them before execution Benets a lot from graphical program- Involves a lot of programming code to be ming, since the ow of data can actually able to see dynamic ow of data be visual depend on it, even automatically redrawing any/all graphs that use the cells value. Reactive programming refers to the automatic recomputing of the output whenever any of the input values change. [8]

1.5 Real-time Systems and Embedded Controllers A 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 the system behaviour is the most important concern in most applications. Applications of real-time systems include but are not limited to defense systems, space systems, networked multimedia systems, embedded automative electronics such as airport video terminals, and so on where the state of the system changes with time. (e.g.: A chemical reaction continues even after its controlling computer system is stopped.) [10] The most important aspect of a real-time system would be predictability and not performance [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 Classication of Real-Time Systems Real-time systems may be classied in multiple ways [10]: 1. By characteristic and application: (a) Hard/Soft/Firm: A missed time-deadline in a hard real-time system causes total system failure. Thus, it is important that the response of the system is denitely time-sensitive in the order of ms. Examples include command and control systems and various trac control systems. The usefulness of results of a soft real-time system degrade with time. For instance, airline information displayed on multiple terminals in an airport would be important only at that particular time and is not generally useful after a ights arrival or departure. Travel reservation systems also serve as examples of soft real-time systems. Sometimes, when the usefulness of results goes to zero after a certain deadline, such a real-time system is said to be rm; missing some deadlines is tolerable in this case. [9] Thus, the result has utility even after the deadline has passed in case of a soft real-time system, zero utility in case of a rm real-time system, and zero utility resulting in a catastrophic failure of the system in case of a hard real-time system. [10] (b) Fail-safe/Fail-operational: A system is said to be fail-safe if the system can ensure that a failure does zero or minimal harm to the system of its functions. A fail-operational system continues to operate normally even upon encountering a failure. For instance, a launch-on-command nuclear weapon system is fail-safe while a launch-on-loss-of-communications is fail-operational and is undesirable. [11] A simpler example of a fail-safe system is an electronic/electrical device that is equipped with a fuse that fails in case of a failure, thereby saving the actual device from failure while rendering the system non-functional until it is safe to operate again. In the context of real-time systems, a fail-operational system may continue to operate in order to meet the real-time deadline even in case of a failure while a fail-safe system does not. 2. By design and implementation: (a) Guaranteed-timelines/Best-eort: A real-time system that works on a besteort basis does not provide any quality of service or guaranteed delivery of response, while a guaranteed-timelines system ensures guaranteed delivery. Thus, a guaranteed-timelines system is more reliable than a besteort system. For example, the connection-oriented Transmission Control Protocol (TCP) is a guaranteed-timelines service while the connectionless Internet Protocol (IP) is a best-eort service. [12] (b) Resource-adequate/Resource-inadequate: A real-time system with adequate resources would be called a resource-adequate system and thus be more reliable than a resource-inadequate system.

9 1.5.2 Real-Time Operating Systems and Environments National Instruments, with LabVIEW version 6, introduced LabVIEW RT version to design real-time systems using LabVIEW; LabVIEW RT is now an addon module in LabVIEW. In a system that has a non-RTOS (Real-Time Operating System), the latency is longer because of many other active tasks that run in order to keep the OS running. The execution time is reduced from the order of ms to microseconds using LabVIEW RT. An RTOS is optimized to take full advantage of the hardware to get the most stable timing performance. Loop prioritization is done by RTOS and critical operations override normal/other operations. System clock can be synchronized to microseconds instead of ms in systems running RTOS. In order to keep the latency to a minimum, a daughter computer/application processor hardware that runs the RTOS is connected to a non-RTOS host computer which shows the User Interface (UI) through a wired or wireless link. This kind of set up also helps immunize the real-time system from failures of the host computer [13]. RTOS is used to provide specic services to applications, using real-time scheduling policies, inter-process communication, and run-time monitoring. Examples of RTOS include RT-Mach, VxWORKS, Solaris, and Lynx [10]. 1.5.3 Embedded Controllers Embedded controllers are commonly microcontrollers that have real-time computing capabilities and may be general-purpose or custom-made for specic applications. Digital Signal Processors (DSP) are a common class of dedicated, realtime embedded controllers. Embedded controllers have the advantages of better performance, better reliability, smaller size, and lesser complexity, and enable batch production thereby reducing the manufacturing costs too. An embedded system may have a single microcontroller or multiple units, peripherals, or networks inside a larger chassis 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-vendor interoperability. Object Linking and Embedding (OLE) was a Microsoft technology that allowed linking and embedding documents to other objects. The evolution of OLE started, in 1990, on the top of Dynamic Data Exchange (DDE) concept of Microsoft, and was later reimplemented with Microsoft Component Object Model (COM) and then Distributed COM (DCOM) as its bases, and eventually led to ActiveX controls. Interoperability of OLE objects requires the development and use of a software component that understands OLE objects. The concept of OLE was extended to process control and eventually led to the founding of OLE for Process Control (OPC) Foundation in 1996 with major players in the automation industry coming together. The essential aim was to create a communication standard that is widely acceptable such that it enables data exchange among devices/control applications manufactured/developed by dierent vendors. The

10 OPC Foundation ocially renamed itself to Open Platform Communications and works with the tagline Open Productivity & Connectivity. [15] OPC thus enables the communication of real-time plant data between control devices/applications from dierent manufacturers in the industrial automation industry, extending its applications 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 OPCs own binary-coded TCP format along with OLE. Standards are specied for the acquisition and control of process data, alarm and event records, historical data, and batch data to multi-vendor enterprise systems and between production devices (sensors, instruments, PLCs, RTUs, DCSs, HMIs, historians, trending subsystems, alarm subsystems and more as used in the process industry, manufacturing), and in acquiring and transporting oil, gas and minerals [15]. The OPC Foundation also provides certication program for vendors to test their compliance to open standards. OPC now is moving towards Unied Architecture (UA) to enable enterprisewide data sharing and communication across embedded systems, controllers, mobile phones, workstations, servers, and other enterprise-standard hardware. The idea of interoperability is dened as between device to device, device to software, software to software, UA to UA, UA to OPC Classic, and OPC Classic to UA. The OPC-UA enables vendors to implement OPC on non-Microsoft systems and embedded devices. OPC Express Interface (Xi) or more recently known as OPC .NET, based on Windows Communication 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 how OPC 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 Unied 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 connect PLCs and RTUs to control centres, data warehouses, and the enterprise; a data acquisition (DAQ) server to allow clients to access data from PLCs, RTUs, and other eld devices using standard protocols; a Historian to accumulate time-stamped data to compute and display trends; a supervisory computer; and process and analytical instrumentation. [17] RTUs collect on-site information, converts sensor signals to digital data, and sends the data to a central location using communication elements. RTUs can also receive information from the central location through these communication elements. [16] The programmable capabilties of RTUs include implementation of ladder logic for boolean operations.

12 Use of Programmable Logic Controllers (PLCs) instead of RTUs oers the advantages of being economical, versatile, exible, congurable, and also oer more sophisticated embedded control capabilities [17]; they allow multiple programmable formats such as standard statements, ladder logic, or the use of functional block diagrams. Thus, PLCs are more common today as eld devices in a SCADA system. HMIs display relevant and necessary information using GUI. The HMI usually comprises of a high-end computer system that is capable of displaying high-quality graphics and running advanced and complex software. [16] Communication elements include wired interfaces such as leased telephone lines, local-area networks (LAN), data cables and buses between systems; optical bre cable (OFC) to transmit data over longer distances; radios, cellular, or microwave for wireless communication; and wide-area networks (WAN), or VSAT (satellite) for very long-distance communication. Signal conditioners as well as data converters such as analog to digital converters (ADC) or digital to analog converters (DAC) or media converters (MC) to convert electrical signals to optical signals and vice versa are also a part of the communication elements in a SCADA system. SCADA systems oer 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 computing where a bus connected a SCADA system to the mainframe (Monolithic), to the days where the SCADA system was connected to multiple computers and devices which communicated through LAN but still worked in their own proprietary environment (Distributed), to the current times where SCADA systems could benet from platform-independent communication and open standards (OPC) could enable better networking and control (Networking). Figure 1.8 shows a simple SCADA system [18] along with the three generations of SCADA systems [19]. With new networking protocols and standards and with the advent of cloud computing, SCADA systems march into the fourth generation (Internet of Things). [17]

13

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

1.7.1 Human-Machine Interface A Human-Machine Interface (HMI), earlier called the Man-Machine Interface (MMI), is the interface that separates the machine from the operator. A properly designed HMI must provide ease of use to the end-user while oering ecient functionality to the developer. Typical operator interfaces must be designed in so that the data is categorically presented in a way that does not overwhelm or confuse the operator. Such design considerations are of prime importance since most HMI show process-critical data, an error in which requires the operator to act with minimal delay. While HMI is usually local to one machine, a SCADA system may bring forth and present various individual HMIs to a single operator. A schematic of a 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 Programming Microsofts ActiveX is built on the top of Component Object Model (COM) and Object Linking and Embedding (OLE). An ActiveX Control provides specic functionality to an application and can be designed for use by multiple applications on the host system. ActiveX controls can be programmed using C, C++, Visual Studio .NET, or C# to implement various interfaces. ActiveX controls require native or emulated Windows environment for execution, and are commonly used in most Microsoft Windows native applications such as the Windows Media Player, as well as Microsoft Oce, Microsoft Visual Studio, and Windows Internet Explorer. ActiveX may be dened as a set of rules for how applications should share information. ActiveX controls are more powerful than Java applets because ActiveX controls have access to the OS environment and thus have wider functionality. Each ActiveX object is identied with a unique Class Identier (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 a computerized test and measurement system. [1] (OR) Industry-standard computers equipped with user-friendly application software, cost-eective hardware, and driver software that together perform the functions of traditional instruments. [4] (OR) A general-purpose computer software to mimic real instruments with their dedicated controls and displays but with added versatility that comes with the software. [5] (OR) Computer software and modular hardware, all combined and congured to emulate the function of traditional hardware instrumentation. [6] 2. DataFlow Programming: DataFlow programming is a programming paradigm that models a program as a directed graph of the data owing 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 the required programmatic operations. 5. Real-time Systems: A 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] 6. Latency: The time lag taken by an application to actually execute. Latency depends on all the active tasks running at the time of execution. [13] 7. Embedded Controller: An embedded system or controller is a computer system 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] Dataow, http://en.wikipedia.org/wiki/Dataflow, Last accessed on: February 09, 2014. [8] Dataow 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-eort 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: February 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, on: February 09, 2014. Last accessed