To See and Control

Anyone who’s seen a law-enforcement photo of their car rolling through a red light knows the power of video to monitor events, report exceptions, and initiate action—such as send notice of a moving violation and fine. If your town doesn’t have such video applications, it’s likely to soon. The use of video in industrial settings is similarly exploding, and for many of the same reasons. Prices are dropping, technical capabilities are increasing, and it’s finally cost-effective to augment the power of human sight. This tutorial will tell you why and where it’s happening, and what you need to know about cameras, networks, and resources to plan a video process control system.

Cameras as sensors can catch things instrumentation often cannot. Source: Longwatch

“Using cameras as sensors, we’re multiplying the number of eyeballs. They can see things that instrumentation might not be able to catch. In addition, our instrumentation tells us one thing, but our eyes can tell us more or different things,” says Steve Rubin, president and CEO, Longwatch Inc., a maker of systems that provide video over existing SCADA networks.

Societal trends are pushing the use of video in business and industry: In the U.S., the Homeland Security Act helped finance the installation of video surveillance systems that are now being upgraded, while worldwide everything from camera phones to YouTube is making video accessible and easy to use for consumers. In industry specifically, more cost-effective and intelligent digital technology, ubiquitous Ethernet and other networks, and plant engineers having to do more with less are all enabling the “automation” of human sight and visual analysis for process control. A number of technology developments make now the right time to consider video applications:

Control networks, particularly those supporting the IP protocol, increasingly are being used in industrial plants. Using an existing Ethernet network for video applications avoids additional capital investment, and ensures network-knowledgeable resources are available.

Costs are lower for cameras, analog-to-digital encoders, and network hardware and software. The popularity of digital video on the consumer side is helping to lower prices for industrially hardened hardware. Even analog closed-circuit television (CCTV) cameras formerly used for security can be adapted for much lower cost than before.

Cameras have better resolution and intelligence than previously, and can be more accurate than humans. “A camera has greater acuity than the human eye,” says Rubin. “It can operate very fast or see more detail. A camera also never looks away or gets bored.” There’s also more and more image analysis being done at the camera.

Image analysis, compression and storage technologies are all improving rapidly. Norman Fast, CEO of Industrial Video & Control (IVCCO), says “One camera can be looking at a view and software lets different parts of the picture be zoomed in on. An example is one camera looking at six flare stacks with a wide angle lens, and then showing each individual stack zoomed in on.”

Systems integrators and vendors specializing in process control video application software are improving their skills and learning from new installations. That means systems are being applied in new and better ways. Says Rubin, “One video stream can be used for surveillance and security, and that same stream can be used for quality control, operator training or batch step verification (an example is a video of an ingredient being added to a fermenter or tablet coater.)”

With the proper encoders and software, standard surveillance cameras can be used to deliver video images to HMI screens over Ethernet or other networks. Source: Longwatch

Applications beyond surveillance

Companies are realizing that with the cost of equipment coming down, they can put cameras in places they never considered. Vendors involved with video for process control applications say interest is high, and monitoring and control application examples are numerous. IVCOO is an eight-year-old company whose engineers specialize in using IP video for industrial applications, including security and remote monitoring. Fast says the most rapidly growing portion of his company targets use of video in process industries.

At a Weyerhauser sawmill, for example, IVCOO put in about 100 cameras to watch 100-ft to 300-ft production lines, each of which was run by one operator. Now, operators avoid running up and down the line to do their jobs, and there’s an instance where one operator can monitor two lines, he says.

A quality control application at a Mercedes Benz assembly plant uses video in the cell that puts body panels on the chassis. Two cameras start capturing images when the chassis comes into that cell and stop when it leaves. “Someone can review that video down the line for quality issues or defects,” says Fast. “It’s pulled over IP and stored on computer, available for either real time or archived viewing.”

Fast says there’s a lot of interest in video applications in oil and gas and chemical industries, where “they need to add cameras for protection, to monitor workers in hazardous areas. Once they put in cameras for security, they find additional uses: view operations, read gauges on equipment, check when certain levers are in proper position, etc.”

Rubin started Longwatch to handle video surveillance for water treatment plants and gas compressor stations that his company was building. The goal was to provide video over existing SCADA communication networks. “The only connection to that unit was a radio network connected through [a Rockwell Automation] Allen-Bradley protocol,” he says. “We solved the problem of sending video long distances over 9600 baud lines on a PLC network via radio dial-up connections to the HMI, so operators could see what’s going on in the field.” Longwatch still provides the remote capability, along with in-plant video capability, delivered over Ethernet and other networks. Version 4 of the software was recently released with more IP support, including an IP camera driver toolkit.

Rubin says, “We see many customers in electric power and distribution, oil and gas production, and water treatment use cameras on-site for surveillance and security. In electricity, they’re trying to ward off copper theft. Water plant operators have been instructed by the Department of Homeland Security and the Environmental Protection Agency to provide security of their systems.” Beyond these security applications, however, are process and quality control functions performed through video.

One Longwatch customer runs an aluminum furnace. “As the metal travels down a sluice to be poured into ingots, slag forms along the sluice, interrupting the flow,” Rubin explains. “Operators might hit the slag with a hammer, but if the slag re-enters the flow, the metal can be contaminated. Because Longwatch is event-based, it can switch on and off. So we have a vibration monitor on the channel that triggers the capture of a video clip.

“Operators can check and determine potential need for re-work before the ingot leaves the plant. The information also can be used to re-train operators,” he says. Another customer is using a camera to spot the “before, during and after” events surrounding jams on its bottling line, Rubin adds.

Cameras and encoders

A video over Ethernet system is comprised of image and network hardware and software. Analog cameras—those typically used in security and surveillance applications—usually connect via a coax cable to a monitor (using CCTV technology.) Digital cameras put out a digital stream, suitable for IP networks. A video encoder changes analog signals to IP messages so analog camera images can be transmitted, analyzed, and integrated with digital networks. Physically, it is needed to convert from coax cable (analog) to Ethernet cable (digital). Longwatch and IVCOO both can take existing CCTV cameras and incorporate them into video over IP systems.

Eddie Lee, product manager for Moxa USA Inc., a maker of device networking products for industrial automation, explains. “A video encoder, also commonly referred to as a video server, is not required if a video over IP camera (Webcam) is used. The problem is that most IP cameras today are built for light consumer use,” he says.

Rubin calls today’s IP camera market “reminiscent of the instrumentation market of the 1980s: There are literally hundreds of different IP cameras available, each with their own special features.”

Some have video analytics that can trigger the sending of video (or an event message) when, for example, something foreign enters the video frame. That allows the video stream to be automatically monitored. “There’s wide variety in the efficiency and accuracy of video analytics,” says Rubin. “Perhaps the most reliable of the analytics used today is license plate recognition for traffic and garage cameras.”

Engineers can start with PC-based video servers and build their own systems, but that can required a lot of expertise. Ann Liao, marketing manager for Ethernet Direct, says her company focuses on PC-based video over Ethernet solutions, rather than network control solutions. Video over Ethernet servers perform two functions, she says, which Ethernet Direct bundles together): The encoding function usually comes in a box with a digital signal processor and built-in firmware for converting analog camera signals to digital. The recording and management function, also known as the NVR (network video recorder) receives the digital video signals from the encoder or IP camera, manages the cameras, encoders and recording schedules, and plays back recorded videos.

Key consideration: bandwidth

Vendors like Longwatch and IVCOO have already integrated the image capture and playback functions, and they provide strategies for the complex issues of network usage and storage management. Even with video compression, smart choices for capturing so many frames per second, and software triggers that only capture video on an exception basis, video consumes a lot of bandwidth. Software can help smooth out network loads, reduce network traffic, and reduce traffic going back to camera. It can also manage bandwith for large networks of cameras over whatever network bandwidth is available: fiber, copper, wireless, or satellite.

“People generally think that adding an IP video camera is simply a matter of plugging in the camera and adding an ActiveX control to a display,” says Rubin. “If you are not using supplementary software designed for manufacturing and process control applications, then you’re likely to run out of network bandwidth (responsiveness) as you add four or five cameras to the overall network. This is especially true if you have multiple HMIs accessing video.

“Plus, without that software, the camera needs to be configured, optimized for performance, and then firewalled so that not just anybody can look through it or reposition a pan-tilt-zoom camera via the Internet.” (See how easy it is by Googling “IP camera hacks,” he says.)

Networks and servers

By definition, video over IP needs to be run over IP networks, as opposed to traditional fieldbuses that use proprietary fieldbus cables, such as DeviceNet, Foundation Fieldbus, ASi, etc. According to Moxa’s Lee, “Video over IP can be run on the same network as control networks, but often times it is handled on a separate VLAN (virtual local area network). In this scenario, they share the same media (cables), but software is used to isolate video traffic from control traffic.”

“In addition,” says Lee, “quality of service can be used to prioritize control traffic over video traffic. Depending upon the bandwidth requirements of the video over IP application (number of video streams, frame rate, video resolution, etc.), gigabit bandwidth may also be recommended. The main benefit of running your video over IP and control traffic on the same network is cost efficiency, both in terms of reduced cabling costs and reduced maintenance costs.”

It’s important to note that video process monitoring is not the same as machine vision. Surveillance camera vendors and automation system integrators are seeing costs dropping on their side, and that’s opening up new opportunities. A pattern-matching quality control application in a carpet mill, for example, doesn’t require the detailed image processing of machine vision; a less expensive video system can focus only on pattern alignment, automating that step cost effectively.

ONLINE EXTRA

Ladder DiagramLadder Diagram (LD or simply Ladder) is probably the most widely used controller programming language. Invented to replace hardwired relay-based control systems, Ladder programming is used in probably 95% of all applications. Visually, this language resembles a series of control circuits, with a series of inputs needing to be “made” or “true” in order to activate one or more outputs.

Ladder has experienced such widespread adoption that almost every programmer in any country or industry can read and write this language. Because it resembles the familiar electric circuit format, even a non-programmer with an electrical background can follow the program for purposes of troubleshooting a problem.

It’s also easy to start writing a program in Ladder. With just a basic outline of input and output signals, one can start churning out code. Most other IEC languages require more preparation, such as flowcharting of all potential process flows. Finally, most Ladder implementations allow a program to be organized into folders or subprograms that can be downloaded to the PLC, allowing easy program segmentation.

Ladder programming is ideal for simple material handling applications, for example, where a sensor detects the presence of a box, other sensors check for obstructions, and then an output fires an actuator to push the box to another conveyor. Digital inputs check for various conditions, and the program analyzes the inputs and fires digital outputs in response. There may be timers in the program, or some basic comparisons, or math, but there are no complex functions involved.

As the complexity of PLC functionality has grown, however, Ladder has been challenged to meet these advances and still maintain the paradigm of easy visualization and understanding. Functions, such as PID loops, trigonometry, and data analysis, now required in many control applications can be difficult to implement. Another challenge is that as program size grows, the ladder can become very difficult to read and interpret unless it’s extensively documented. Finally, implementing full processes in Ladder can be daunting– picture a ladder rung with an output used in several phases of a process with many input conditions attempting to control exactly when that output needs to turn on.

Function Block DiagramAlthough Ladder may be the most widespread language, a survey conducted by Control Engineering magazine several months ago highlighted growth in the use of programming languages other than Ladder. Function Block Diagram (FBD) programming is an example. Even though the adoption rate for this language has recently slowed relative to other languages such as Structured Text, FBD is probably the second most widely used language.

In many ways, this graphical language resembles a wiring diagram even more so than Ladder code. With FBD, the blocks are “wired” together into a sequence that’s easy to follow. It uses the same instructions as Ladder, but visually is more understandable to a viewer who is not versed in relay logic. The major advantage is that programs written in FBD tend to be easy to follow– just follow the path!

FBD is ideal for simpler programs consisting of digital inputs, such as photoelectric sensors, and outputs such as valve manifolds, and could be used in any application where Ladder works well.

However, FBD is not ideal for large programs using special I/O and functions. The large amount of screen space required can quickly make a program unwieldy if it reaches any substantial size. Also, writing a program in FBD requires more upfront preparation to understand the program and how it will flow before any code is written, since it can be difficult to make corrections later.

Sequential Function ChartSequential Function Chart (SFC) programming resembles the computer flowcharts that many engineers remember drawing up in their college days. An initial step “action box” (the starting point of a flowchart) is followed by a series of transitions and additional action steps. The SFC concept is simple: an action box, with code inside written in any language of the programmer’s choice, is active until the transition step below it activates. The current action box is turned off, and the next one in the sequence is active. The transition step also has code to check that the necessary conditions are met to allow the program to advance to the next step. The language is very friendly to maintenance engineers because its visual nature and natural code segmentation makes it easy to troubleshoot.

On the downside, this style of programming is not suitable for every application, as the structure it forces on a program could add unneeded complexity. A large amount of time must be spent up front preparing and planning before any programming is attempted, or the charts can become unwieldy and difficult to follow. The overhead required for this type of program causes it to execute slower than the other languages.

A final consideration is the inability to convert to other languages. IL, FBD, ST and Ladder programs can easily be interconverted, allowing a piece of code to be displayed in the way most comfortable to the user. SFC, however, cannot be converted.

Instruction ListInstruction List programming (IL) consists of many lines of code, with each line representing exactly one operation. Thus, it is very step-by-step in layout and format, which makes the entry of a series of simple mathematical functions easy.

IL is a low-level language and, as such, will execute much faster than a graphical language, such as Ladder. IL is also much more compact and will consume less space in PLC memory. The simple one-line text entry method supported by this language also allows for very fast program entry– no mouse required, no tabs to click! In legacy systems, programs written in IL are easier to display and edit on a handheld programming unit, with no software or laptop required.

Despite IL’s advantages, it seems that maintenance and service engineers do not prefer it. This may be because it is less visual than Ladder, which may make it more difficult to interpret what the program is doing and what errors it is experiencing.

IL can make entering complex functions, such as PID loops and complex mathematical computations, a struggle. IL does not lend itself well to any form of structured programming, such as state programming or step ladder, further limiting its usefulness for implementing large programs. It is also arguable that the advantages of speed and compactness are less relevant, given the processing speeds of modern PLCs and the large amounts of memory available.

Structured Text

With its IF…THEN loops, CASE selectors, and lines ending in semicolons, Structured Text (ST) closely resembles a high-level computer programming language such as Pascal and C. The aforementioned Control Engineering survey indicated that of all the IEC61131-defined programming languages, ST has seen the greatest increase in adoption.

Among IEC languages, ST perhaps best embraces the growing complexity of PLC programming, such as the process control functions involved in plastics or chemical manufacturing. Trigonometry, calculus, and data analysis can be implemented far more easily than in Ladder or IL. Decision loops and pointers (variables used to do indirect addressing) allow for a more compact program implementation than can be achieved in Ladder. The flexible ST editor that is common in most programming packages makes it easy to insert comments throughout a program, and to use indents and line spacing to emphasize related sections of code. This makes the task of structuring a complex program easier.

ST text-based, non-graphical nature, which is similar to IL, also runs much faster than Ladder. An additional ST benefit is that it comes closer than most of the other languages in achieving the transferability goals of the IEC61131 standard, emancipating a programmer from the hardware platform.

A final benefit is that many students currently graduating from engineering studies have a better background in computer languages than in the basics of electrical wiring, and therefore can more easily become proficient in ST than Ladder programming.

A disadvantage is that, for many previously experienced programmers or maintenance and service personnel, the ST environment is unfamiliar. Writing the code and structure to make it maintenance-friendly can reduce some of its compactness advantages.

As a result, control engineers tend to use ST “behind the scenes.” For example, IEC 61131 allows a programmer to build his or her own functions in one language, then insert them as sub-programs in another language. With this option, programmers often encapsulate an ST program inside an instruction, which is then embedded in a Ladder program.

Why Use Software Verification?

As control-system application programs become ever more complex, maintaining software quality during initial development and subsequent maintenance becomes more difficult. In a white paper available for download from Control Engineering ’s online Resource Center, Paul Humphreys, a software engineer with LDRA Ltd. makes the case for extensive testing of control software, and explains the procedures world-class embedded control software developers use to ensure error free applications. Download the white paper today at [[[URL TK]]].

For more information:

www.iec.ch

www.boschrexroth-us.com

Author Information

Renee Robbins is senior editor for Control Engineering magazine. She can be reached at renee.robbins@reedbusiness.com .

Do you have experience and expertise with the topics mentioned in this content? You should consider contributing to our CFE Media editorial team and getting the recognition you and your company deserve. Click here to start this process.