Construction of a Simulated Pipeline
The "Golden Gate" Project
Extreme Blue - Spring 2004
Toward the end of the "Golden Gate" Extreme Blue project, a simulated pipeline was constructed to showcase the features of our software. Specifically, we wanted to demonstrate our ability to perform well in the Industrial Automation field. During an exciting two weeks, a lot of effort was put forth to complete this task. This web page will take you through our experiences from start to finish!
At first, all we knew was that we wanted a demonstration that used real hardware. Our demonstration needed to include both "sensors" and "actuators" to best show our software in action. We had quite a few ideas, but the one that stood out the most and was finally chosen was a simulated pipeline. The basic idea was to simulate a "pipeline explosion" at which point our software would detect a problem and automatically shutdown the pipeline. Not only would such a demo include sensors and actuators, but it would also give us an excuse to have an explosion! (unfortunately, we never got around to including any type of REAL explosion -- but this did influence our decision in what demo to build!)
We didn't quite know what we were getting ourselves into, but we ran with the idea. A simple sketch was drawn on our whiteboard (reproduced digitally below) to detail what we might build.
The idea is simple. We have a fluid reservoir to hold a water ("oil") supply. A pump is located shortly after the reservoir to circulate the fluid. Two flow meters measure water flow at two different locations. Between the two flow meters is a manual hand-valve to allow us to simulate an explosion by breaking the flow. When this "explosion" occurs, the software detects a significant difference between the two flow meter readings and shuts off the pump. For bonus points, a valve is included in the circuit. Worth noting is that our final product matches this initial diagram almost exactly. The only difference is that the on/off valve was actually placed on the other side of the pump.
With that small bit of planning, it was time to go shopping! Obvious requirements were pipe, a pump, a valve, two flow meters, and some sort of reservoir. Electronic requirements would depend on what kind of hardware we bought. We had to be able to connect these things, by some means, to the Arcom Viper embedded gateway that would be running the demo. (more details on the Arcom box and electronics below, as the electronics were finished last) So, we headed to Lowe's.
We bought some plain PVC pipe, a ton of fittings, and a RainBird irrigation valve. We also bought an ugly plastic sink to use (thankfully temporarily) as a reservoir. Flow meters and a pump that met our needs were not found at Lowe's.
After more searching we found some relatively cheap ($150/ea) flow meters online at Gem's Sensors. Two were purchased. We also found a good, cheap (under $30) pump on the Harbor Freight website. There's a Harbor Freight store in Raleigh, so we stopped by and got a pump. Around this time we also bought some electronics, including wire, relays, and a transformer to power the valve. We soon decided that the white PVC was rather ugly and found some clear PVC pipe online. We ordered about 30 feet of it, but did not get clear fittings because they were somewhat expensive. We decided we could live with the plain white fittings.
Because we were waiting on the flow meters and clear PVC to be shipped to us, we decided it would be a good idea to build a prototype. (a good idea anyhow!) We scribbled down some rough dimensions and started sawing! After a couple hours we had a rough prototype, minus any electronics or wiring.
We were eager to test the prototype. We wanted to make sure the pump and valve actually worked! So we spent some time wiring these things up. The pump is powered with a regular 120VAC source. The valve requires 25VAC, so we used a step-down transformer to get that voltage. At this point nothing is software controlled, we just turn on the pump and valve by connecting two wires. (how safe!)
None of us really had any experience with a project like this (we're comp sci majors!), so of course our test run did not go quite as smoothly as we would have liked. It took us a while to get the pump running. Once we did, we had pretty bad leaks despite use of PVC cement and teflon tape. No problem! By the end of the project we would be plumbing experts. After some troubleshooting we got everything working and the water was flowing FAST! So now we know the pump and the valve work, but we're still waiting on the flow meters.
Up until this point, transporting the demo has been a real pain. All construction has taken place in Extreme Blue lab, but we've been testing in the break room since it has tile floor. Necessity breeds invention, so we decided to build a platform onto which everything could be mounted. We managed to get some plywood and 2x4's from a co-worker and it was off with the plumbing and on to the carpentry! The clear PVC and the flow meters have arrived, so it's the real thing this time!
A large piece of plywood serves as the base. Several small pieces of 2x4 are used to keep the PVC pipe raised a few inches off of the platform. Additionally, a smaller piece of plywood is mounted about 8 inches above the main platform. This is where the Arcom box and all other electronics will be mounted. Part of the reasoning behind this was to keep any leaked water away from the electronics!
We even took the time to mount a couple wheels on the bottom. Unfortunately we never got around to mounting a wagon-like handle so we could pull it around! Once all the drilling and hammering was complete, we attached the PVC pipe onto the wood with some plastic mounts. The pump was mounted onto the platform with bolts. Everything is coming along quite nicely! Sure looks better than that prototype!
This is an excellent stopping point for another test run. The wiring is redone so we can run the system to make sure the pump and valve still work, check for leaks, and make sure the flow meters function correctly! At this point we have yet to integrate anything with the Arcom box and we're still manually controlling the system.
The good news is we have virtually no leaks! There's a bit of dripping around the pump but otherwise our plumbing skills pulled through! But it doesn't take long to discover that one of our costly flow meters does not function correctly. The flow meters should output a 0 to 10 volt signal, depending on flow. The first flow meter works correctly... about 10 millivolts with no flow, and about 9 volts with flow. The second flow meter, however, always reports around 10 millivolts. So it's definitely getting power and sending out a signal, but it doesn't respond to flow.
This is bad news. We only have about a week left until expo, and it took 4-5 days for these to be shipped! An emergency call is placed the next morning and a new flow meter is sent on its way. However, we're uncomfortable with the situation and thus begin contemplating alternatives using a single flow meter. After all, we may not get the new one in time and it might not work either! For now we leave the non-functional flow meter in the circuit and hope that we can just replace it when the new one arrives.
Meanwhile, we have some time to make sure we can get all this stuff integrated with the Arcom box. All throughout the construction phase we had also been planning how this integration would work. Our entry to the Arcom box would be two I/O cards sent to us by Arcom Controls.
The first is a relay card containing 8 software-controllable relays. This card also has several discrete on/off inputs. We'll be using a couple relays to control power to both the pump and the valve. We'll also use this card to read the status of a push button. The other card is a "multi I/O" card. It has several analog and discrete inputs and outputs. We will be using this card as an analog to digital converter to read the flow meter output.
Above are the wiring schematics depicting how the electronic equipment was wired. Three schematics are shown, one for each power source. The system requires a 12 volt DC input, a 24 volt DC input, and a 120 volt AC input. The 12 volt DC source powers the push button and the two relays that switch the pump and valve on and off. The 24 volt DC source powers the two flow meters. The 120 volt AC source powers the pump and the valve. The system is wired such that the pump can only turn on if the valve has been provided power and thus opened. The flow meter output is scaled from a 0-10 VCD output to a 0-5 VDC output using a pair of resistors. This is done because the Arcom I/O card requires a -5 to 5 volt input. A transformer is used to power the valve since it requires a 25 volt AC power source. Note that the relays on the I/O card actually switch on and off two more external relays, since they cannot handle the 120 VAC that would have to flow through them to power the pump and valve.
After several hours of laborious wiring, the system is connected to the Arcom box. After figuring out how to set jumpers properly and load the I/O drivers, we were receiving flow meter data and able to flip the pump and valve relays on and off! Despite having a couple problems throughout the project, overall everything is really coming along quite smoothly.
Good news! We've received a new flow meter to replace the broken one, and it works! Now we just need to get the demo looking presentable. All the wires scattered everywhere are quite a mess! A medium-sized Sterilite container does a good job of hiding the clutter. We just drilled a few holes for the wires going to the various devices.
We also finally got rid of that ugly sink. We used a wider, shallower Sterilite container as a water reservoir. This came at a price, however. The sink was good because the water level was above the pump. This made it easy to get water flowing through the system when it is first set up. With the new container, gravity isn't helping and we have to open the manual valve to give the pump some help in sucking water up to its level. No show-stopper, but a little harder on the pump!
Yeah, it looks like a science fair project, but at least it looks way better than the first prototype! Transporting the demo is now very easy since everything is mounted and packaged very well. We found humor in the fact that the demo just *barely* fit through any doors we ever had to carry it through, almost as though we had planned for it. The clock is ticking but we're all set and not stressing it! However, we still run some final tests.
For the sake of completeness, here's a diagram with each major piece labeled. You can click on the image for a larger version.
|
|
|
As you know, our demo is controlled by an embedded computer manufactured by Arcom Controls. Specifically, we are using the Arcom Viper industrial gateway. Inside is a low-power Intel XScale 400MHz processor, 64MB SDRAM, and 32MB Flash storage. On the Viper board, there is a PC104 bus where the I/O cards are plugged in. From the Arcom website...
The VIPER is an ultra low power PC104 compatible single board computer based on the Intel® 400MHz PXA255 XScale™ RISC processor. The PXA255 is an implementation of the ARM compliant, Intel XScale microarchitecture combined with a comprehensive set of integrated peripherals including, a flat panel graphics controller, DMA controller, interrupt controller, real time clock and multiple serial ports.
The VIPER board offers a long list of features making it ideal for power sensitive embedded communications and multimedia applications. The board has been designed to take advantage of the power saving modes of the PXA255 processor and other onboard peripherals to achieve an incredible 1.9W typical power consumption. The VIPER also supports a very low power standby mode.
The VIPER board includes a TFT/STN flat panel graphics controller, onboard soldered SDRAM and resident Flash, 10/100baseTx Ethernet, 5 serial ports, dual USB host controller, USB client, AC97 audio/codec, CompactFlash interface (CF+), and a standard PC104 bus expansion connector. The PC104 format is an industrial form factor measuring 3.8” x 3.6” (96mm x 91mm).
Specifically, we are using the Arcom Viper Linux/Java Development Kit. Pre-installed is a Linux operating system based on the 2.4 kernel. During development we communicated with the Arcom box via COM port or ethernet connections. SSH was used for command-line access and FTP was used for most file transfers. Our software was able to communicate with the I/O cards by using a set of Java classes provided by Arcom. These classes simply read/write to a memory-mapped file that in turn accesses the I/O cards.
As you can see, we've been doing a lot of hardware work. Sawing, gluing, drilling, soldering, wiring, nailing! But like good little programmers, we've also been churning out code. Not only have we been finishing up our software framework, we've also created the software brains for the demo, the code that will actually control the pump and valve based on input from the flow meters and push button. We've also created two additional programs to make the demo even more flashy. One is a realtime graph that will display the flow meter readings and other data in real time as the demo runs. The other is a timer display that shows how long the pump has been circulating water. This extra software really adds a lot to the demo!
These applications receive data from the Arcom box over a socket connection. Both were written in Java and use SWT for graphics. From left to right, the three images above show a startup sequence, letting out a various amount of water from the manual valve, and a shutdown sequence. The green and red lines are flow meter readings (in gallons per minute) and the other lines are relay values (on or off). Note: These are old screenshots. The final application showed a legend on the right side instead of the bottom and also showed current values in text. Also, accumulated values were plotted to show how many gallons had actually passed through each flow meter (instead of just gallons per minute).
Let's talk about the demo scenarios in a little more depth. As you know, we're simulating a pipeline explosion! So here's how it works. First, a person presses the push button to let the software know we want to startup the pipeline. The software counts down for a few seconds before actually starting. This is to demonstrate that it's the software doing all the work, not a hard-wired startup. The software first opens the valve and then turns on the pump. Within half a second the system is running at full flow, around 11 gallons per minute. Two separate conditions will make the software shutdown the system. The first is a significant difference between the two flow meter values. This means that the manual valve between the two flow meters is open, representing an explosion that has caused a break in the pipe. The second condition is an appreciable drop in flow for both meters. This means that the manual valve directly after the pump has been opened, representing a problem at an earlier point in the pipeline circuit. When the software detects either of these conditions, it shuts off the pump and closes the valve.
This is a pretty simple scenario, but it shows all of our software and hardware in action. However, we wanted to take it a step further and throw in a second, totally different scenario. What we finally came up with has nothing to do with pipelines or explosions. In this second scenario, we begin in "training" mode and allow some amount of water to exit the system through the manual valve between the two flow meters. We then enter "repeat" mode, where the system will again let out that same amount of water that exited in training mode. Once the same amount has exited, the system shuts off automatically. Here's an example. We start the system, as before, by pressing the push button. We are now in "training" mode. We fill up a cup by opening the manual valve. We then press the push button again to enter "repeat" mode. The water is still circulating and waiting for that same amount of water to exit. We fill up another cup and wait for the software to automatically stop the pump. Assuming good calibration, the cups should contain roughly the same amount of water. The software is able to figure out how much water has left the system by computing the difference in accumulated gallons for the two flow meters.
Now we have two scenarios to demonstrate rather than just one. This is great because it allows us to further demonstrate the powers of our software framework. Switching between these two configurations is a simple matter of loading two different XML files on the Arcom box. The behavior of the system changes immediately and requires no restart of the machine or even the java VM!
Tuesday, April 13, 2004 is the big day. We come prepared with food coloring and our rubber ducky mascot.
We arrive at work super-early to set up in Bldg. 002, where we will be holding the morning expo. We've transported and set up the demo so many times that we can have it up and running in about ten minutes. Everything gets set up and it all appears to be working just fine. The Extreme Blue staff explain what Extreme Blue is all about to the audience, and then we give our pitch. We then head to the back of the room where the demo is and run it a few times and explain what we've done and why it's important.
Everything works like it should! The morning crowd was relatively light, but we expect many more for the afternoon expo. We pack up the demo and move it back to Bldg. 500 where that will take place. Somehow we even find time for a short break. Pictures are worth 1000 words, so I'll let them do most of the talking!
What a crowd! Again we give our pitches and have visiting speakers, and then it's on to the demos. A mass of people surround the pipeline as we show it off. Lots of people ask questions and generally seem very interested in what we've done. Again, everything works flawlessy and we can truly claim success.
Before packing up for the day, we record a short, unrehearsed video demonstrating the pipeline in action. (see the Links section to download it) This video was sent around via e-mail to those who could not attend, but should have been there! The Expo was the peak of our project, as the remainder of our time would be spent writing documentation! It was a long, enjoyable day, and we headed home "early" around 5:00.
The project is over, but the demo lives on! In the weeks following the end of the Extreme Blue project, we present our demo to several important people. First the demo is shown to Robert Mayberry, the new head of the IBM Sensor & Actuator Solutions EBO. Soon after we present our demo to Nick Donofrio, Senior Vice President of Technology and Manufacturing. Both of these visits go really well, and it's good to know that our project was successful enough to warrant these meetings!
About a month after the end of the Extreme Blue project, we had the opportunity to meet with Arlen Nipper, the president of Arcom Controls. Arlen was a huge help throughout the duration of our project. Not only did he supply us with the hardware we needed to put together an awesome demo, he gave us lots of technology-related feedback and other good advice. We showed him our demo and explained all the technical details regarding it and the software we wrote. Arlen was excited to see what we had done and even said "Wow!"
The demo has now found its final home as part of the WEL, along with several other Pervasive Computing demos. The folks in the Pervasive Demo team have learned all about our demo so they are able to use it and run it themselves. Our creation is no longer our responsibility, but is in good hands! The demo team has even presented our demo to some of IBM's customers. Success!
A special thanks to all those involved. We couldn't have done it without your help!
|
|
|
Here's a very informal (and probably incomplete) list of all the parts used in the construction of the pipeline demo. A more detailed and complete list may come later.
|
|
|
If you're asking yourself, "Why the heck did they do this?", you might want to check out some of these links...
Thanks for reading! =)