Feasible remedies to these induced complexities lie with integrated-development environments (IDEs). They help end-users meet their needs with their applications, which increasingly incorporate different types and speeds of analog and digital input/output, notes Kamran Shah, LabView marketing manager at automation vendor National Instruments (www.ni.com), Austin, Texas. IDEs offer that assistance by offering development tools and functionalities such as control-programming software/command libraries, HMI development tools, data-exchange software and debugging tools, adds Tom Edwards, senior technical advisor at automation-and-controls vendor Opto 22 (www.opto22.com), Temecula, Calif. True to form, though, there’s a “but.” “You must have global namespace service, central administration of software and universal application development to have a powerful integrated-development environment,” Mody emphasizes. Global namespace replaces traditional common directories for tracking computers on a system. A principal drawback of those common registries is having to rename tags and references when computer locations change, Mody explains. With global namespace, however, “you don’t know where anyone is—you don’t care where anyone is,” he says, noting that this fix eliminates reengineering configurations. And data can be created in one location and then retrieved anywhere else, adds John Strembiski, team leader for Proficy Process Systems at Charlottesville, Va.-headquartered GE Fanuc Intelligent Platforms (www.gefanuc.com). But he advises security constraints for information retrievers based on their role. The second item in Mody’s must-have component list for IDEs—universal application development—allows end-users to create complete applications from a single location. For example, in developing a machine HMI in the traditional manner, an end-user needs special tools for runtime, SCADA and visual aspects of the system, Mody explains. But using the virtual solution with, for example, a historian, “if I define it one time, I should be able to use it again,” he says. Thus, the simplest level of IDE, itself a set of software, becomes the operator’s workstation, even with a laptop computer. So how can an IDE be used? “It’s really a model to grab a pump, for example, to view at the HMI and say, ‘I’d like to represent this device or other object,’ ” states Keith McNab, technical lead with the GE Fanuc’s Proficy Process Systems. See what matters But those “pre-canned” objects need to be flexible and modular, he believes. “Once you have these objects with their properties, sometimes you get a control engineer locked into a section of function that doesn’t really serve him.” That’s particularly evident in alarm management, which control engineers consider the “primary problem,” observes McNab. With objects carrying lots of alarms, “you get operators who become desensitized, because so many go off in a minute.” The solution he sees is having rich functions in those objects that allow control staff to select only those alarms that matter to them. The third thing on Mody’s required-component list entails deploying software. “Do I install it on everyone’s machine, or do a drop from a single location?” is the question end-users face, he suggests. “IDE generally allows the latter. This is called central administration of software.” This tracks versions and allows the administrator to make changes and send notifications to operators by e-mail. All they need do then is hit “Install,” rather than having to fiddle with software installation “wizards,” Mody explains. “You can change on the fly.” Perhaps that’s the attractiveness of powerful IDEs: No fiddling required, just attention to the process, and virtual, global convenience to the end-user. C. Kenna Amos, [email protected], is an Automation World Contributing Editor.
Leaders relevant to this article: