Tech Tips September 2006
September 26, 2006
TECH TIP OF THE WEEK:
Vision triggers process steps
Using machine vision as to trigger process steps seems a bit like using a jack hammer to crack a walnut, but that ain't necessarily so. While most machine vision systems use multi-megapixel cameras and sophisticated image-analysis algorithms, there are smaller, low-resolution imagers available, and not all analyses are compute intensive.
There is a class of applications now being mainly served by relatively dumb sensors, such as photocells and proximity switches, that can be better served by slightly more sophisticated low-end vision equipment. Take, for example, the application shown in the accompanying photograph. A European beer bottler needed to check beer crates and boxes of cans leaving their plant to ensure they carry the correct number of containers.
As machine vision applications go, it's quite simple: identify tops of bottles or cans as they roll by, count them, and compare the number with a bill of lading. Multimegapixel resolution isn't needed because we're really just looking for the presence or absence of a few (order of ten) easy-to-spot objects. The identification does, however, have to be done in real time while the cartons move fairly rapidly (although not "high speed") past the station.
Bill Silver, Senior Fellow at Cognex Corp. calls this class of applications "Optoelectronic Sensing." He says these applications are characterized by the need to:
Detect that an object has reached or crossed some predefined reference point;
Determine when the object reaches some predefined synchronization point; and
Determine whether the object satisfies certain inspection criteria.
In our example, the "object" is a carton of beer containers. The reference point is the inspection station.
The synchronization point is some arbitrary point within the inspection station used to control timing of the system's response. In our example, a carton that fails might have to be shunted off out of the main stream of cartons headed off to wherever the cartons need to go next. Some mechanism would have to activate to move a reject carton—and only the reject carton—out of the flow.
The inspection criterion is the correct number of containers visible in the carton. The result is, of course, either a pass or a fail for each carton.
Arranging a set of sensors to perform this check, whether they are photocells, microswitches, pneumatic sensors or whatever, would be a complex and difficult task. An engineer would have to pick the correct sensor type, design a structure to hold the sensor array in the correct position and ensure that the carton-to-carton variability in placement would not be so much as to foil the sensors. If a carton is out of place by so much as a couple of centimeters (or fractions of an inch if it were done in the U.S.), contacts would be missed and the system would break down. Also, retooling for a different product arrangement would require repositioning all of the sensors as well as reprogramming the controller.
To do the same task with a simple vision system is straightforward, however, and not too expensive. One low resolution camera (on the order of 10,000 pixels) would provide images with more than enough sharpness to find and identify bottle caps or can lids, and to make sure they weren't really extraneous objects like discarded lottery tickets. Low resolution—especially in black and white—would make for very fast processing time even on a modest CPU. Canned algorithms, such as blob analysis and pattern matching, make programming the system fairly easy even for technicians unused to image processing. Reprogramming, of course, is just a matter of downloading a different instruction file. The resulting system is faster to set up, easier to program and maintain, and far more robust. Ultimately, it is likely to be less expensive as well.
For those who really want to take the easy way out, Cognex has pulled together all the required hardware and software components in a product they call Checker. With it, an industrial engineer can deploy an inexpensive, robust optoelectronic sensing system with a minimum of knowledge about optics, cameras and machine vision.
SOURCE: Silver, W., "The Synchronizing detector: A Machine that Watches," Cognex Corp., Natick, Mass.
September 19, 2006
TECH TIP OF THE WEEK:
Vision system design
Vision system design is all about three-dimensional geometry, and metrology is all about second order corrections to first order transfer functions, so even vision-based measurement applications that are simple in principle get very complex very fast. Most vision-based metrology problems, however, are solvable and have, in fact, been solved over and over again in the past.
The right way to approach any vision-system problem is to pick your favorite vision-equipment supplier and ask them for help. The number of supplier choices has dwindled in the past few years as the industry has consolidated. Those that are left have a lot of expertise and are willing to share it.
The company that has the most experience doing vision-based metrology is Cognex . They practically invented the art in the 1980s and have been perfecting it ever since. If you go to them with a problem, they'll most likely have an off-the-shelf solution already.
If you'd rather become your own expert, look to Edmund Optics . They've been involved with "roll your own" optical metrology since long before anyone thought of making measurements with a video camera. Their catalog has all the components you need and their tech library includes white papers that teach all the necessary concepts to become your own vision-metrology expert. Start by exploring the tech library on their website, then, if you don't find all the information you need, contact their technical-support engineers.
C.G. Masi, Senior Editor, firstname.lastname@example.org
September 12, 2006
Developing mathematical models.
A mathematical model is algorithm or set of equations that represents the interesting behavior of a system. Experts with thorough knowledge of the system and its interaction with the environment typically perform model creation tasks in development projects for complex dynamic systems. The development of a model for a complex, dynamic system is an iterative process that involves significant effort to verify the correctness and accuracy of the resulting implementation.
The process of model development begins with a specification of the requirements the model must meet. The following are issues that must be addressed in development a model of a complex system.
What effects should be included in the model? A system may exhibit many different kinds of behavior (for example, the motion of motors, vibration, wear of moving parts, etc.), but not all of these behaviors need to be modeled to produce an effective simulation. Limiting the effects model to only those that are truly necessary will make the model less complex and easier to build, test, and maintain-as well as requiring less computational resources to execute.
How detailed must the model be? In many cases a simple model is all that is needed, but if precise determination of system behavior is required, the model may need to be very elaborate.
What interactions between the system and the outside environment must be modeled? For example, a communications satellite's motion model must operate in conjunction with a model of the earth's gravitational field, as well as with models of other relevant phenomena, such as solar pressure.
What techniques will be used to develop the model? A fundamental choice is whether to use physics-based equations or measured data as the basis for the model. The answer to this question is often obvious to those with expert knowledge of the system.
What data must be gathered to perform the modeling? For example, an aerodynamic model of an aircraft may require extensive wind tunnel testing.
How much time and how many people are available to develop and text the model? As model complexity increases the development and test hours will increase as well.
What computing resources are available for the model? A large model may consume significant amounts of memory, disk space, and CPU time. However, given the capabilities of current computers, this may not be a critical issue.
Will the model eventually be used in a hardware-in-the-loop (HIL) simulation? This may place severe constraints on the execution time allow for the model. Alternatively, a complex model may require high-performance computing hardware for use in an HIL simulation, perhaps involving the use of multiple processors.
How can verification and validation be performed for the model implementation? There must be reasonable ways of conforming that the model has been implemented correctly, and that its behavior matches the system being modeled to an acceptable degree.
These issues should be addressed as part of planning for the simulation effort. The questions listed can be applied at the highest level of the entire system being simulated initially, and again as the system is broken down into subsystems and individual components to be modeled. These questions are also useful ion the development of additional models needed for a complete simulation, such as the gravitational field and solar pressure models in the communication satellite example above.
Source: Jim, Ledin, Control Valve Handbook, CMP Books, CMP Media LLC, Lawrence, KS, 2001, p. 28-29.
September 5, 2006
Industrial network security is increasingly focusing on networks as they continue to evolve beyond their historical isolation. Networks are making themselves and their data accessible via Ethernet TCP/IP, IT-related systems, and/or the Internet, and are facing the inherent vulnerabilities of these technologies. The question is how can users access their networks remotely without exposing themselves to unauthorized intrusions?
To begin improving security, managers, control engineers and system administrators must first think of their network as a whole, and become aware of their company-wide infrastructures. It's useful to literally sketch out the entire network; take an inventory of everything connected to the network; and then ask 'Is this network linked to a company intranet or to the Internet?' and 'Is the network completely hardwired or are there wireless components?' Next, managers should check what security measures are presently available, and make sure they're enabled and operating.
Undoubtedly the most important tool for increasing security is having a router/firewall between local networks and larger systems, especially those tied to the Internet. While switches operate at the data link layer (layer 2), routers generally operate at the network layer (layer 3) with most routers handling TCP/IP messages. A router/firewall matches private Internet addresses with data requests, allowing through only specified messages. Very few unauthorized messages get through routers.
Another security question is: 'Will the highly repeatable communications on the plant floor be able to handle corporate-level data transfer sizes and bandwidth? To manage these communications, many users employ switches with broadcast storm control capabilities, which block broadcasts from overly noisy ports.
Also, these switches assign slightly different bandwidths for accessing each port on a network. This ensures that each device gets only the messages it's supposed to receive.
Beyond basic routing, some users implement virtual local area networks (VLANs) between their plant-floor networks and office systems. Located in the switches' hardware, VLANs block unauthorized messages between network ports.
In fact, two VLANs overlapping to a specific degree can share data if, for example, a device on the factory floor also sits on the corporate VLAN. This exposes only one device to potential vulnerabilities, and leaves other devices protected.
Yet another option is to simply install an additional router between two locations, which can be dedicated solely to sending data between them. This security strategy doesn't mask addresses, but it too allows only specific traffic between plant-floor addresses and office addresses. This method is similar to a VLAN, but instead uses the added router to do its job.
Check connected PCs
Back on the infrastructure side, network managers must also be cautious about what devices might be using up available bandwidth on the plant-floor. Ethernet switches are designed to be very inviting, and someone plugging into an available RJ-45 port can potentially hinder or damage manufacturing processes with unauthorized or untested network traffic.
So, besides checking the security of one's own network, managers also must be careful about the protocols used on PCs and laptops that may connect to switches on their plant-floor network. Managers can test new software or devices by running a plant-floor network in safe mode or by setting up small test networks.
Bennet Levine, R&D manager Contemporary Controls, www.ccontrols.com
Source: Bennet Levine, “Securing network security,” Back to Basics, Control Engineering, Oct. ’04, p. 68.
Locking in security to-do list
Think of network as a whole, and sketch it out-literally
Inventory what network is connected to-Internet? Wireless?
Check for existing security features, and make sure they're enabled
Install router switch/firewall between plant-floor network and other networks
Enable router's broadcast storm control capability
Use virtual local area networks (VLANs) to block unauthorized messages between ports
Overlap two VLANs to allow specific data sharing
Use additional dedicated router to allow only authorized traffic between two networks
Test PCs and laptops plugging into plant-floor network