Posted by Marty Michael on Mon, Aug 30, 2010 @ 08:05 AM
I don't think we have seen anything yet when it comes to the total digital integration of our society. Ford is now releasing a new line of cars with a unique WIFI integration hotspot. And yes, you guessed it, there will be an App For That.
Please comment, where will integration invade next?
Check out this video.
Posted by Matt Ruth on Mon, Aug 09, 2010 @ 01:43 PM
In the past few decades we have certainly benefited from many of the new materials, products, and engineering developments spun off from the NASA Space program. One in particular comes to mind. In 1959 NASA adopted the HACCP program with the cooperation of Pillsbury who had pioneered this approach to ensure the integrity of their food manufacturing processes. NASA was searching for the most effective way to protect the purity and safety of the food supply our astronauts would live on throughout their space journeys. The HACCP program filled the bill.
HACCP, as all food providers now know, stands for Hazard Analysis-Critical Control Points. In a food preparation line, what and where are the entry points where something could go wrong affecting either the materials or the process itself? Once these CCPs are identified and noted, then each point can be controlled and monitored to ensure compliance to set standards
For example, for a bread or dough manufacturing process some of the CCPs would include the material storage silos, oven temperatures and timing cycles, along with CIP (clean in process) schedule compliance on the mixing, slicing, and packaging machinery lines. For every delivery of flour into its silo, the magnetic detectors monitoring metal content would have to be read and recorded. Each of the ingredient silos would be periodically monitored for foreign objects such as insects and mice droppings etc. Every batch would have its oven temperature and timing data recorded. Then as each batch left the packaging line, records would be available to show that data was collected on every CCP and complied with the set targets.
As the FDA became aware of the potential benefits of HACCP to ensure the integrity of the food supply chain, regulations were introduced requiring this approach. Fruit Juice was first (21C FR120) followed in 1997 with regulations for the fish and sea food industries (21CFR123). The USDA, responsible for the meat and poultry industries issued regulations in 1997 first mandating the HACCP program in slaughtering establishments (9CFR417). By 2000 all establishments involved with meat and poultry production were included in this regulation.
Briefly, these regulations require all producers to list the CCPs, their critical limits, the monitoring procedures and frequencies used, the corrective actions to be followed in response to deviation from a critical limit, and most importantly the maintenance of a recordkeeping system. These records must be signed and verified by a responsible establishment official and stored for a minimum of one to two years depending on the food category.
Records are a necessary tool in all manufacturing industries but for companies in the food supply chain they are both mandatory and invaluable. They provide the data to date product production, identify the source and arrival time of every ingredient, and a record of all control and process variables. The variety of SCADA computer systems available provides a data collection option for all user companies, large or small, depending on their individual preference and needs. The HACCP data can readily be incorporated into one’s existing system with a few modifications.
One problem that does arise is the HACCP data that must be collected and entered manually since sensors are not available for these specific measurements. The visual reading of the magnetic sensor located in the flour silo would be a good example of this. Another would be the visual check for animal droppings in the various storage bins. If the monitoring procedures and frequencies required these readings to be taken with each flour delivery or perhaps once during an operating shift for other storage bins, what assurance does one have with the validity of the written check list. Was the reading really taken at the time entered or could it have been entered after the fact, hours after the set schedule? When data is automatically collected and stored from sensors (pressure, temperature, volume, time etc.) the accuracy is highly reliable and usually unquestionable. Unfortunately we can’t guarantee the validity of manual entries. Or can we?
In recent years technology has been developed to vastly improve the validity and the confidence one has in manual entry data. Using hand held wireless transmitters the data technician can manually update the SCADA computer with his/her identity, the time of each reading and the status involved. Combined with all of the data automatically collected and recorded from process sensors, the HACCP record keeping system is now complete, and certainly more valid and reliable.
Avanceon* is one of the country’s largest and most experienced Control System Integrators, specializing in MES (Manufacturing Execution Systems) for the Food & Beverage and Pharmaceutical markets. They have furnished numerous systems to food processors of all sizes to help them comply with their HACCP record keeping requirements. One of the major benefits of these systems is the complete elimination or a vast reduction in the paper storage requirements for past records. All of the data is computer stored (with backup, or course) and the ease of searching for data on past shipments borders on being phenomenal.
To summarize, statistics show a remarkable percentage improvement in the reduction of Salmonella pathogens in the meat and poultry industries following HACCP guidelines. Similar improvements have been accomplished to prevent botulism in the processed food industries. Proper implementation of HACCP procedures combined with automated data collection will continue to protect the safety of our food supply in addition to providing opportunities for improved process efficiency.
*Avanceon is a CSIA Certified Member. www.avanceon.com
Posted by Marty Michael on Wed, Jun 16, 2010 @ 10:45 AM
One of the things we want to do with this blog is it to help our readers find relevant information that can help them to improve their business. One good source I have found is a site called Software Advice. MES, Supply Chain, OEE, or Quality management are all covered on this site.
Software Advice recently held a roundtable discussion on the state of the manufacturing software industry. Teaming up with four industry experts, they reported on the leading trends taking shape in 2010. In general, they find this year to be more active than 2009. Buyer interest and purchase activity is up across the industry, from large sophisticated companies to smaller companies implementing an enterprise system for the first time.
They attributed the increased activity to two main reasons. First, the 10-year anniversary of purchases made as a result of the Year 2000 (Y2K) date problem; and many companies are restarting buying processes that were deferred in 2009.
Interestingly, they find most purchase activity taking place among chemical, food and consumer packaged goods (CPGs) manufacturers, with aerospace, semiconductor and automotive manufacturers not far behind. Increased ERP software adoption among CPGs is fuelled by "the need to manage global supply chains, distribution networks and targets acquired through mergers and acquisitions activity," observes Jonathan Gross. While aerospace, semiconductor and automotive companies are "more active with upgrades, replacements and add-ons."
The report continues on with a discussion of activity in the software as a service (SaaS) market, how vendors are adjusting prices to compensate for the economy, how offshoring influences spending and whether manufacturers are implementing integrated enterprise resource planning (ERP) systems or best-of-breed applications.
To read the full report, visit 2010 Manufacturing Software State of the Industry Roundtable
Posted by Engineer X on Fri, May 07, 2010 @ 10:28 AM
It all started the day Bernie left. In clearing out his cube, he found an AB PicoLogix controller he had received from a training class at some point in his career and gave it to myself and my friend Rob who was interning with us at the time (I had just gotten a full time job maybe a year prior). We weren't sure what to do with it at the time, but it wasn't long before Rob had a stroke of brilliance. "Why not build an automated beer bong out of it?" he exclaimed one day. Being fresh out of college (or still in it in Rob's case), the concept of a beer bong was admittedly probably something that was taking up too much space in our collective brains.
For those not familiar with the concept, a beer bong is generally a funnel with a maybe two foot tube attached. The concept is that by bending the tube upwards, one can load the funnel and half of the tube with a full can of beer. The user then gets down low, puts the non-funnel end of the tube to their lips and by raising the funnel and bringing gravity to bear, can force large quantities of beer rapidly down ones throat. Is this concept and activity leading to the degradation of American society? Perhaps. But is it an engineer's duty in life to take an existing idea and make it better? Absolutely. And so we decided to take this immature idea to new heights, literally.
Our concept of the automated beer bong was one that grew rapidly as we started to get into it. Originally the idea was to automate some valves so that we could lengthen the tube and perform a larger drop. This began to manifest itself in a 3 story design that could be setup at the top of my townhouse (which is on the second floor) and the user could be on the ground outside of the basement.
As we moved into the programming phase, we decided to add more and more functionality. I should also point out how the lack of requirements here led to some major scope creep. First we decided that two people should be able to share in this joy simultaneously. I mean, what's the fun of taking a 3 story beer bong when you don't have someone next to you that you can race in such an endeavor. So we created 2 tracks tied to a single start button so they would start at the same time. We wanted the tracks to be selectable, so I could choose to race my friend or I could choose to go solo. If I picked the later, I didn't want beer to come pouring down the tube that had no one waiting for it at the other end and spill all over the ground. We then came up with the brilliant idea that we would want to control the amount of beer being delivered. Perhaps I'd only want a full beer or maybe I wanted to go crazy and try multiple beers. So we decided to control the amount of beer being delivered, making it selectable between one and six beers in half beer increments. Finally, we had to make sure that we keep the beer bong clean and functioning and to that end we needed a CIP (Clean in Place) mode that allowed the valves to stay full open so we could flush the lines with water and cleaning solution as needed.
Fabrication went quickly, although it was certainly not up to any NEC, UL or other code. In fact, in some ways it was fairly unsafe. Some of the different buttons and switches we mounted on a piece of plexiglass, but it was initially designed to be something that would be more of a wall-mount, such to say there was no back or enclosure around the terminal ends for those components. In addition, we used those style terminal blocks that are DIN-rail mounted and open on one side (where you are supposed to use an end cap) except we had no end piece and so one side was completely exposed. In the end we threw a blanket over the whole thing and told people not to go near it (kind of like an SOP). We did, fortunately realize one potential safety issue ahead of time and took action to improve the receiving end of the beer bong. We recognized that the downward rush of beer was going to push a fair amount of air initially into the receiver's mouth before the beer shows up. To mitigate this we put a T-connector at the end with a one foot length of tubing sticking up to allow the air to release and to not be forced into the person's throat.
With our crude implementation complete, we set off to run some tests. Needless to say, we were pretty excited about testing it out. We had to dial in the beer measurement (based off of timers and average time to get a fixed amount of beer out) and adjust the length of the air relief tube at the bottom, but overall it ran pretty well out of the gate. This was pretty fortunate since we were doing this initial testing about 30 minutes prior to the production startup which just happened to coincide with an unveiling party. In the end everyone had a good time and no one got electrocuted, although to be fair we didn't push the full design capability of delivering 5 or 6 beers at a single time.
I apologize for not having any actual pictures of the beer bong in action. For some reason, we were counseled by our lawyer-like conscious' at the time that it would be better if no photographic evidence existed, although now I wish we had it for posterity sake. It still makes for a fine story without any pictures though, so we'll make do.
So what kind of personal engineering adventures have you experienced? Do you have any experiences where you have used automation around the house, perhaps getting a bit too involved or overly complicated? We'd love to hear some of those stories.