...Failure to Communicate

I am a big fan of Paul Newman, the actor and humanitarian that had a long and successful string of hit movies. One of my favorite is Cool Hand Luke, where he plays Luke, a prisoner in a southern chain gang that is continually bucking the system. 

During the movie the following dialog takes place between the Captain and Luke. Luke just finished time in “the box” after an unsuccessful escape attempt. In addition he was given a set of leg irons “to slow him down.” 

Captain: You gonna get used to wearing them chains after a while, Luke. Don't you never stop listening to them clinking, 'cause they gonna remind you what I been saying for your own good.

Luke: I wish you'd stop being so good to me, Cap'n.

Captain: Don't you ever talk that way to me. (pause, then hitting him) NEVER! NEVER! (Luke rolls down hill; to other prisoners) What we've got here is failure to communicate. Some men you just can't reach. So you get what we had here last week, which is the way he wants it. Well, he gets it. I don't like it any more than you men. 

(Carroll & Rosenberg, 1967)

As a result “What we’ve got here is failure to communicate” has become a common phrase in the American lexicon. 

Many of the problems we experience are caused by the failure to communicate. In piping systems, the failure to communicate causes pumps to be over-sized leading to increased operational, maintenance, and capitol cost and reductions in system reliability and overall output. One of the most common communication problems is the failure to accurately state the process requirements when selecting a pump. It works like this:

The owner of the system design provides a capacity requirement based on future system needs knowing full well that the system will be operating at a lower capacity for an extended period of time until the market need catches up with capacity. So instead of specifying the expected 500 gpm for process design flow, 1,000 gpm is given so as to plan for the future.

The engineer designing the system takes the capacity provided by the process group and adds a 20% design margins of flow (to allow for future capacity increases). In addition a design margin for head is added (to account for system uncertainties during the design process) when specifying the equipment. As a result the pump design point is 1,200 gpm and 200 ft of head.

The individual selecting the pump chooses a pump with the design point left of the pumps Best Efficiency Point (BEP) to allow the pump to better accommodate future system capacity increases. 

“What we've got here is failure to communicate.”

Each group in the process added their design margin, just to be on the safe side. Yet they fail to document or communicate their design margins to the entire group. This is the way things are done today because that’s the way things have always been done. We as engineers, have a tendency to add design margin just to make sure thing work. There is nothing wrong with that except that problems arise when we don’t consider the consequences of compounding design margins on the system operating costs, maintenance costs, capitol costs, and plant reliability. 

That is where PUMP-FLO comes in handy; it’s a great way to communicate. Anytime during the process the user can enter basic system operating information and the program calculates the static head and dynamic head. Combined with the pump curve you can see the interaction between the pump, process, and control. For example the following pump/system curve was generated with the PUMP-FLO program using a pump curve from the Crane Deming Pumps catalog. 

  
Notice the design point for the selected pump was 1,200 gpm with 200 ft of head based on the calculations performed by the engineer. The individual selecting the pump chose one with the design point left of the pump’s best efficiency point of 1,550 gpm. As we can see the pump is the most efficient at a flow rate that will never be achieved.

The blue lines represent the system curve. The upper blue line was used in calculating the system static head for the pump selection calculations; this represents the maximum static head expected even though the possibility of the system operating under this condition is less than 1% of the time.  The lower system curve shows the typical valve for static head. The pump was sized for the maximum static head that occurs infrequently and at a flow rate that is not expected to be needed for 10 years.

What is this costing us? Cost is a primary driver for most operating system, and one again PUMP-FLO is able to help you communicate how much the system costs to operate.  For example the projected pump operation during the first 5 years is 500 gpm resulting in a 72 psi pressure drop across the control valve.  When the system is running as described for a year it consumes 395,000 kWh and with a power cost of $0.10/kWh costs $39,500/yr to operate.

If the differential pressure across the control valve was reduced to a more reasonable pressure drop of 28 psid, by reducing the impeller diameter on the pump to the minimum allowed by the manufacturer, the pump will consume only 214600 kWh per year with an operating cost of $21,460/year.

The Captain was wrong, we don’t have to get used to the leg irons of system inefficiency if we just communicate our process and total cost to everyone involved. 

By the way if you haven’t seen Cool Hand Luke I would suggest renting in on Netflix® or Amazon.com® and watch an excellent story with an outstanding cast. And please let me know what you think about the article or about Cool Hand Luke.

---

References:
Carroll, G. (Producer), & Rosenberg, S. (Director). (1967). Cool Hand Luke [Motion picture]. United States: Warner Bros.-Seven Arts

Darcy's Fables

Estimated Reading Time: 3 minutes 33 seconds. Read Later

Here is a picture of me reading to my newest grandchild. All my grandchildren love to be read to, and one of their most favorite books is Piping System Fundamentals, which I co-wrote with Jeff Sines of Engineered Software. They like the ease at which the book explains difficult concepts of piping systems along with the compelling graphics. 

As you can see from the picture he has a question about NPSH. It seemed his older sisters told him that NPSH stands for “Not Pumping So Hot” so he wanted to have me set him straight. I told him to watch out because older sisters like to tease younger brothers.

All my grandchildren enjoy the stories in Piping System Fundamentals, but sometimes the topics are a little difficult to understand. As a result I often change the story by making it into a fable.*  Aesop was the master of fables in western cultures, and I still remember my mother reading them to me growing up. 

So I thought I would create some of my own fables to tell to my grandchildren. I decided to call them Darcy's Fables in honor of Henry Darcy, the Frenchman that help develop the equation for calculating head loss due to friction in a pipeline.   

So here is my first Darcy's fable called:

The Wise Cat in the Tree of Knowledge.

Long ago, there was a village built around a Tree of Knowledge. People would come from all over the land each bringing their unique customs and languages to this wonderful village. The people of this village would all sit under the Tree of Knowledge, work together and come up with ideas for wonderful things that everyone wanted. Each clan had their unique powers, there were the Sparks with their electric personality, the Newtonians, possessing an understanding of all things mechanical, and the Chemists, using their knowledge to make the most amazing things from the most basic of elements.

After many years, each group got so involved with what their clan was doing they developed their own "secret" language that could only be understood by their fellow clan members. Since each clan used their own "secret" language it became difficult to exchange ideas at the Tree of Knowledge. Each clan continued to work to develop the most amazing things, but since each group thought they knew the answer, they stopped listening to each other.

One day a young page boy was walking by the Tree of Knowledge and spied a wise cat sitting on a branch. Our young page climbed up into the tree and started petting the cat. The cat enjoyed the attention and started purring as all cats do.

After a good scratch, the cat said to the youngster, "Because you are so kind and took the time to pet me I, will grant you the power to explain."

The young page said, "I don't understand!"

The Wise Cat rose and started to walk away saying, "In time, you will understand. Come back tomorrow and I shall let you pet me again."

The young page came back to the Tree of Knowledge every day to pet the Wise Cat. Every day he would listen to each clan as they discuss their ideas and talked about their problems at the Tree of Knowledge. (In this magical land, yes, they continue to solve problems, and don't have issues!) While the young page pet the cat he would listen to each clan, and after many days, he started understanding each clans’ "secret" language. The young page discovered that each clan was interested in the same thing, but since they didn't understand each other’s "secret" languages, they were unable to explain themselves or work together. 

Then the young page had an idea, if I can cast everyone's problems into a language that everyone can understand, then all the different clans’ members can work together to solve common problems. The boy grew very excited.

“They just need to speak the same language!” he exclaimed.

Instead of creating a new language, our young page decided it would be best to use ideas that were common to all. He chose to explain the various items in terms they already understood, the local form of money, the “Want.” (Because everyone wants something.)  Everyone was paid for the work they did, the things they needed, and saved for a rainy day using the local currency of the Want. By explaining using money, all the members of each clan could understand the common solution using a customary unit that everyone understood. 

As a result of the young page’s gift, the “power to explain,” the clans could come to the Tree of Knowledge and have a place to present their ideas in a common language all could understand. The village continued to grow and all was prosperous and well.

The moral: If you want others to understand your ideas, use a common language that can be understood by all.

*A fable is a short story featuring animals, mythical creatures, plants, inanimate objects and forces of nature to illustrates a point, lesson, or moral which is often explicitly stated at the end.  (I specifically chose the fable here instead of a parable form of prose, because the parable excludes animals, and all kids love those funny little critters.)

Tell me about your favorite fables or stories from your childhood. Leave a comment below or send an email to blogger@eng-software dot com. Thanks for reading!

Instrument Flying and Collaboration

Estimated Reading Time: 8 minutes 40 seconds. Read Later

Long time readers know that I enjoy flying my own plane. This blog is about a flight I made in my aircraft from Boise, Idaho to Olympia, Washington. For trips I always file an IFR flight plan. IFR stands for Instrument Flight Rules. IFR are the rules established by the FAA (Federal Aviation Administration) and used by both general aviation and commercial flights. Since most of you fly on commercial airlines, I thought you may be interested in the planning and collaboration that goes into a typical flight.

Flying under Instrument Flight Rules involves many groups working together to safely get us from a departure airport, reroute, and to the destination. This is often referred to as “the system.” The groups working in the system are made up of the aircraft and pilots making the trip, the controllers controlling the flow of traffic throughout the flight, and supporting groups that provide weather and other flight services. Each group has their specific tasks and we all have to work together to make it work. I will be outlining my flight and the various groups that I had to collaborate with from start to finish. As a single pilot flying a general aviation aircraft (private) I have to do every step myself, but commercial airline pilots have large support staffs that helps make sure things work smoothly in the airline. Every step I am about to explain must be done in both instances.

Flight Planning

View Larger

My first step is to determine the route I will be taking from the Boise Air Terminal (KBOI) in Boise, ID to the Olympia Regional Airport (KOLM) in Olympia WA. The first thing you will notice is the four letter code for each airport. There are unique codes like this for every airport in the world. The first letter K indicates the airport is in the United States, the remaining three initials indicate the airport designator. The airlines usually drop the (country code) K and use only the three letter code. These are the codes you see on your itinerary, tickets, and baggage tags. For example United Flight 916 goes from Seattle WA (SEA) to Washington DC (IAD) Washington Dulles International.

Looking on my low altitude en route charts, I decided to go by way of the V-4 (pronounced Victor four) airway from Boise to the Yakima (YKM) intersection then fly V-204 into Olympia. There are various “intersections” along the route defining each leg of the flight, and each leg of the flight has a minimum altitude assigned to keep the airplanes from flying into the mountains. For example when flying on V-4 from the BOI intersection to the BKE (Baker City, Oregon) intersection I must fly above 10,000 feet to avoid the mountains and be seen on the Air Traffic Controller’s (ATC) radar.

During this planning stage I determined the distance of the trip, my alternate airport (in the event I can’t land at Olympia). With this trip distance, altitude, and alternate airport I can calculate how much fuel I will need for the trip. I then calculate the total weight of the plane including the weight of fuel, passengers and luggage, along with the location of the center of gravity of the aircraft. This is called determine the weight and balance to ensure the aircraft is operated within the limits established by the manufacturer.

Using the weight information, along with the elevation of the Boise and Olympia airports I then calculate my takeoff and landing distances. After all, if I need 2,000 feet of runway to take off and there is only 1,800 of runway available then it will be a short trip.

The next step is to ensure that I have all the charts needed for the trip (departure, en route, and arrival charts). Since my plane has electronic charts I also check to ensure the navigational databases are current and loaded into my GPS.

The final step in the preliminary planning is to look at the weather forecast for the day of the trip. The weather looked good, but it appeared that I will need to fly through a layer of clouds when taking off at Boise and again when landing in Olympia. I usually do this flight planning 1 – 2 days prior to the trip.

The Pre-flight

On the day of the flight I woke up to rain on the window and immediately checked the weather forecast. The weather had deteriorated during the night, but after checking the online weather I discovered the rain was only in the Boise area. We would be passing through a cold front on the trip so it could be a bumpy ride.

View Larger

When I got to the airport I called FAA flight services and talked to a flight briefer. I filed my flight IFR flight plan and got a standard weather briefing. All this can be done online but I like to file with an actual person. (See a Sample flight plan HERE.)

The next step is to load the fuel for the flight based on my fuel consumption calculations. I conducted a pre-flight inspection of the aircraft, then loaded my passenger and was ready to go.

The Take-Off

Using the engine start check list I started the engine, and once completed, my engine was running nice and smooth. I then checked in on the Automatic Terminal Information Service (ATIS) frequency to get a quick snapshot of the wind, temperature, and barometric pressure at the airport, the active runway (10R), along with the airport NOTAMS (Notice to Airmen). I set my altimeter to the local atmospheric pressure then contacted Boise Clearance to get my IFR clearance to Olympia.

The controller read my clearance per a prescribe format used on every IRF flight plan it was as follows:

Clearance as given by ATC	Description
Columbia N12345	This is the manufacturer and my tail number of my aircraft; this is how this aircraft is referred to for the remainder of the flight
Cleared to the Olympia Airport	I have been cleared all the way to the Olympia Regional Airport
via the Boise Two Departure,	This is a published departure procedure (DP) that provides take-off minimums, the direction of the initial turn to the first fix, and what to do in the event radio communication is lost after departure.
then as filed	After completing the DP I fly to Olympia using the route entered on my IRF flight plan
Climb and maintain 12,000 ft	I am initially to climb to 12,000 ft at the minimum vertical climb rate specified in the DP.
expect 14,000 ten minutes after departure	Approximately 10 minutes after departing the airport I should expect an altitude clearance to 14,000 ft, the altitude I filed in my flight plan.
Contact Departure on 126.9	This is the radio frequency for the Boise Departure controller.
Squawk 2314	This is the numeric code I am to enter into my transponder. Each aircraft has a transponder and the assigned code helps the aircraft show up on the ATC’s radar.

View Larger

I copied the clearance and repeated it to the controller word for word. We now have an agreement between ATC and me, I knew what to expect. I was now "in the system”. I entered the routing as specified in my clearance to the Olympia Regional airport.I then contacted the Boise ground controller on the radio, identified myself, and requested taxi instruction to the active runway for an IFR departure to Olympia.

I was given the following instructions:“Columbia N12345 taxi via Kilo, Juliet, and hold short of Runway 10R, contact tower when ready for departure.” (10R is the heading of the runway, rounded to two places. This runway had a heading of 100° and I was assigned the right runway). After repeating my taxi clearance I taxied to the assigned runway. On the way I saw four Air Force A-10’s taking off in formation, and a Navy F/A-18 Hornet landing. You don’t get to see these up close on a United flight.

After completing my engine run-up check list I contacted the Boise Tower on frequency 126.9. I was cleared to takeoff on runway 10R. I entered the runway, applied the power, then checked my speed and distance down the runway to make sure I took off close to my calculated distance. After becoming airborne, Boise Tower directed me to contact the departure controller. I then switched my radio to 126.9 and contacted the Boise Departure Controller.

The departure controller takes me from the departure end of the Boise runway to the en route portion of my flight. The controller instructed “Columbia N12345 turn right 330 and intercept V-4, resume own navigation” (turn right to a heading of 330 and intercept the Victor-4 airway and then proceed on my flight plan). I repeated the controller’s instruction and started my right turn. I then was instructed “climb and maintain one four thousand,” given my final altitude clearance of 14,000 ft.

En route

After intercepting the Victor-4 airway I was now in the en route portion of the flight. I was then handed off to Salt Lake Center. Each region of the country has a regional FAA control center controlling all flights within the region. The Salt Lake Center is located in Salt Lake City Utah and controls the traffic in southern Idaho. The controller mentioned there was an area of perception 20 miles ahead. I was already looking at the weather map on my GPS, but after looking out the window it appeared the clouds topped out at 16,000 ft. I requested permission from ATC to climb to 16,000 ft so I can fly on top of the weather. She cleared me to climb to 16,000 ft. After flying over the weather I contacted the FAA’s flight services and gave a PIREP (pilot’s weather report). Now other pilots flying the route know the elevation of the cloud tops, the ride smoothness, and other pertinent weather information.

Approximately one hour into the flight I was transferred to Seattle Center, and asked if I would like direct to Olympia. I accepted the clearance revision and updated the route in the GPS. Now instead of flying along a series of intersections specified in my flight plan I can fly directly to Olympia saving approximately 20 miles off the trip.

Arrival and Landing

View Larger

About 30 minutes from my destination, I got the ATIS information at the Olympia airport, and based on the information I knew I would be going through a cloud layer and would be landing on runway 17. I set up the approach in my autopilot, pulled out the correct instrument approach charts, and got the plane ready to land. The Seattle Center Controller then transferred me to the Seattle Approach Controller (they would direct me to the Olympia Airport). I gave Seattle Approach the current ATIS for Olympia and he asked what approach I would like. I responded with the Instrument Landing System (ILS) 17 approach; this is a precision approach and provides me with the lowest minimums for weather. The controller started stepping me down in altitude and giving me vectors (direction to turn) to intercept the ISL 17 localizer. At 4,000 ft I was in a cloud layer and flew the airplane using the instruments. About seven miles before the airport, the Seattle Arrival Controller handed me over to the controller in the Olympia Tower. After descending below 3,000 ft I was through the cloud layer and had the airport insight.

The Olympia Tower Controller then gave me permission to land, and within a few minutes, I was on the ground. The Olympia Controller then closed my flight plan (now I was no longer in the system). I received my taxi instruction and after a two hour and 20 minute trip and no less than 10 different controller contacts I was home!

As you can see, there was a lot of collaboration going on between me and ATC, but what is truly amazing is the collaboration between the various FAA controllers to safely move all aircraft through the system. For those of you that fly on United Airlines you can tune in to channel 9 on their entertainment system and listen to ATC. According to the National Air Traffic Controllers Association, at any given time on an average day of the week, around 5,000 planes are in the skies above the US. In a single year, controllers handle an average of 64 million takeoffs and landings so it's no wonder this job is considered high stress. All the more reason these individuals MUST work as a well-oiled machine, with complete collaboration and clear communication in order to keep everyone safe.

I would love it if you left a comment or even sent me an email to blogger @ eng-software.com. Also, we are currently welcoming guest bloggers. If you are interested, just send me a message about becoming a guest blogger, and what you would like to write about. Thanks!

A Glimpse into ESI’s... Product Development

Estimated Reading Time: 3 minutes 15 seconds. Read Later

This month, Engineered Notes has invited a guest Blogger to join the conversation. Christy Bermensolo is the Vice President of Engineering at Engineered Software, Inc. and has nearly 12 years experience as a Mechanical Engineer joining Engineered Software in 2006. Feel free to comment on this post or send your thoughts and suggestions to the blogger email, we will make sure she receives any and all of your feedback.

A Glimpse into ESI’s Product Development

Here at ESI, we’re always trying to make our products better. Whether through improving the user experience, keeping up to date on the latest industry specifications, exploring more efficient programming methodologies, or automating our testing techniques. In researching the latest ASME NQA-1 standard on Quality Assurance Requirements for Nuclear Facility Applications, it occurred to me what a transformation our product development process has taken within the past few years. We have always taken pride in a solid, dependable, and technically accurate product and as a result, have consistently released products on a solid design cycle (producing valuable product updates every 1-2 years with little to no maintenance versions required between product cycles). One thing we have been working on in the past few years (driven by our company growth) is creating more definition with respect to our development cycle, while more closely integrating both testing and marketing into that cycle.

During the company’s infancy, product design collaboration meant that the entire team was educated on the basics of designing a hydraulic system, and multiple roles were frequently fulfilled by a single individual. Engineers were involved in the big picture feature definition and intimately involved in testing, but feature implementation details were frequently left to the programmers. A small team of 3-4 filled the roles of calculation analysis, work-flow analysis, UI design, code architecture, coding, and test. This led to a best in class product for the simple reason that we recognized from the start that programmers should write the code, and engineers should provide input into how the program worked.

As our company has continued to grow, we’ve had the opportunity to further focus development roles, increasing our productivity in the process. Our testing is now fully automated and run by developers in test utilizing calculated test cases produced by engineers. This allows hundreds of test cases to be run continually throughout the development process, identifying issues with an implemented feature during development instead of just prior to going out the door, which allows additional flexibility in resolving the issue. Our product development requirements are now lead by product owners who work to define the requirements prior to programming development, talking with various customers, vendors, and students in our many training classes to ensure every feature developed sufficiently fulfills a customer need. This ensures the feature fulfills the work-flow requirement, reduces the number of times a feature may require “tweaking” after initial release, and more closely links development to our customers. The larger project teams also created a need for additional documentation, covering both feature development and coding methodologies.

It’s part of our employee culture to continually look for better ways of doing things, the above examples were pulled from various product design, agile management, and quality assurance methodologies and integrated into ESI’s product development life cycle by dedicated employee’s not afraid of a little change. It’s exciting to see as I review the NQA-1 specification sub-section for Computer Software that they share our view of how best in class analysis software tools should be designed and controlled in order to support even the most stringent industrial requirements.

Now it’s time to hear from you. What key steps in your product development do you think is the most important? What steps are necessary for success? Let us know. Please feel free to share your experiences, or opinions on this blog entry or any other subject that is of interest. I can be reached at blogger@eng-software.com.

Cultivating Innovative Game Changers

Estimated Reading Time: 4 minutes. Read Later

Sometimes, in our professional lives, we are lucky enough to be a part of something really great and amazing. An event or discovery so big that it could be considered a “Game Changer.” At Engineered Software, I have had the opportunity to share three game changing moments, and take great pride in being involved with a team that made these events happen. The key to having these moments is to be aware of the possibilities and to be open to innovation. Innovation is not just about the creativity your team possesses, you have to be able and willing to implement those ideas.

My first game changer occurred in 1987 while developing our PUMP-FLO program. PUMP-FLO was developed as a Microsoft version 1 application. This was long before Microsoft had perfected the development environment; and we often referred to Windows 1 as Bill Gates science project.

After working many long hours on the program, my partner gave a shout out and said to come and see what she had done. On her monitor was a pump curve showing the head, flow, and efficiency of the select pump with the impeller diameter meeting the specified design point. I stared at that pump curve for a long while and realized that we had a game changer. We had a program that could present a list of pumps meeting a customer’s design point, using a manufacturers supplied electronic pump catalog, and then dynamically draw each pump curve for the calculated impeller diameter. We realized at that time that the days pump manufacturers needed to supply paper pump curves for pump selection were numbered.

The second game changer was in 1994 when we were working on PIPE-FLO version 5. In previous versions of our hydraulic analysis software, the customer had to establish the piping system connections using lists of pipelines and nodes on the computer screen. It required them to mark up a paper drawing of the piping system, and then using the list interface, manually enter the connection information prior to performing the calculations.

The objective of PIPE-FLO version 5 was to eliminate the need to use the list interface to build the piping system model. The goal was to create built-in drawing tools in the same program that allowed you to enter design data for the pipelines, pumps, components, control valves, and tanks right on the computer screen. We were creating a program that used the drawing to automatically configure the piping connections and displayed the calculated results on the flow diagram. When I first saw the program in operation, I realized the program interface looked like industry standard flow diagrams and P&IDs that our customers were used to working with. Not only did it make it easier for them to create the system, it also made it easier for others involved to understand how the total piping system operated.

This past May I witnessed my third game changer. We were in the final stages of developing our newest web application. One of our major design goals for PUMP-FLO Premium was to allow the user to save their projects on secure servers, thus providing them with access from any computer with internet access and a browser. A second, more ambitious design goal was to allow collaboration between the various pump stakeholders.

One month prior to the scheduled release date all our design goals were met except the collaboration feature, and we didn’t know if it would make the release date. This time I got a call from our PUMP-FLO Project Manager, who asked me to check out the e-mail that she had just sent me. I opened the e-mail and clicked on the attached link, my browser immediately went to a pump list that she had shared with me. I was able to view the list of pumps and display the pump curves for each pump on the list. She then said to display the pump curve for a specific pump; she changed the pumps impeller diameter on her browser, and my browser update the pump curve with the new impeller diameter. Collaborative-interactivity.

This collaboration feature is truly a “game changer.” Using this technology, a pump supplier can make a pump selection and share their selection with the customer. The customer can then evaluate how the recommended pump will operate in their system while talking to the pump supplier. Once the pump has been purchased, the pump supplier can transfer the ownership of the pump project complete with all pump performance data and linked documentation to the owner / operator. They will be able to look at the supplied data, along with all the associated document list for the life of the pump. This ability to collaborate across the internet allows everyone involved in a pumps life cycle to share data, and gain a clear picture how the pump is operating in the customers system.

The nice thing about game changers is that come in all sizes. Some make major changes to the world, and others have less of an impact. The most important thing about game changers is they may come from an idea about how to do something easier, but it’s the hard work of a team that pulls it all together. So the next time you think of a clever idea, follow it through until you can change the game. When you do, please send me an e-mail and tell me about your successes.

Now it’s time to hear from you. What barriers do you have to the execution of your ideas? How have you overcome these challenges to create a “Game Changer?” Please feel free to share your experiences, or opinions on this blog entry or any other subject that is of interest. I can be reached at blogger@eng-software.com.

Working Together Up in the Clouds

Estimated Reading Time: 3 minutes and 33 seconds. Read Later

I got my engineering degree from the United States Merchant Marine Academy in Kings Point NY. One of the best parts of the program was the sea year in which every midshipman spent a year on a US merchant ship. I learned a lot during that year but one thing that impressed me was when we went under the Golden Gate bridge it was just us on the ship. If anything happened on the ship we had to fix it or we weren’t coming home.

After graduation I went into the US Navy where I qualified as a nuclear watch officer and in submarines. Once again after we submerged if anything happened to the ship, we had to fix it to come back home.

After coming onshore, and working in construction I was allowed to come home every night. While at work, if I had any problems that were difficult to solve, I picked up the phone and got in touch with the people who could help me out. I quickly discovered how powerful it is to collaborate with other when problem solving.

While working as a start-up engineer I had access to equipment vendors, the design engineers, as well as the operators. When we had a particularly difficult problem, it was amazing what happened when we all got in a room to formulate a solution. There was only drawback though, when you wanted to work effectively together on a project, everyone needed to be present or the lines of communication could easily break down. It would have been difficult to keep everyone on the same page otherwise.

When I started Engineered Software, I initially thought that our PIPE-FLO® program would be used by mainly design engineers. As time went on, I discovered that a large portion of our customers were actually at manufacturing and industrial plants that were already operating and working in operations or maintenance. They told me they valued the clear picture the software provided to everyone on their teams. I know how important it is to effectively communicate the scope of a project to all involved.

In 2002, Jim Vinson, one of our long time PIPE-FLO users asked if there was any way he could provide a working model to vendors and engineering firms that didn’t have a copy of PIPE-FLO. I saw an opportunity brewing here.

I had noticed when we would contract with a graphic artist to get something created, they would use a specialized graphics program and then submit us a draft as a PDF or Portable Document Format, offering a link to a free reader program like Acrobat® Reader®. Using a powerful design program, then saving it in a format that could be shared with others that did not have the full design program. Ingenious! That got me actively thinking, and figuring out how to apply that to our products.

Many of our customers would create piping system models and wanted the ability to share a read-only version of their design with their team or their customers who may not have the PIPE-FLO program. That idea resulted in the PIPE-FLO Viewer program and the PSV file format that can be opened and calculations viewed using the free viewer program. It is amazing how many PVS files are shared and how many copies of the free PIPE-FLO Viewer program that have been downloaded.

Now we are looking at better ways to offer collaborative tools that offer not just portability, but interactivity. We are gearing up to release our newest version of our PUMP-FLO.com program, a web based pump selection portal. This new version is a step towards the cloud computing of the future. A collaborative environment, where people can share information and never have to even be in the same location. It’s official, we’re a cloud provider.

In addition to offering a program available to users on the internet, the new online PUMP-FLO Premium software will store their data for them on a secured server, and will allow users to share, evaluate, collaborate their saved data searches. Not only can you save a pump selection project, but you can share it with others.

For example, a pump buyer can enter their pump requirements into PUMP-FLO Premium creating a saved search list. Once this information is entered by the pump buyer, they can share their system design requirements with specific pump suppliers. The pump suppliers are sent an e-mail notification about their customers pumping application and can then select the best pump from the products they carry, and modifying a search list. Once the selection process is completed by the pump supplier, the pump buyer can evaluate the selected pump and move forward on the purchase.

This collaboration of pump system data represents a major advancement in the process of selecting pumps. I am particularly excited about the new program we are about to release, including all the new features and what this means for the future of collaborative pump selection. This is cloud computing, or collaborative computing is how we plan to move in the future with all of our software products.

** The PUMP-FLO Premium is now in final beta where it is receiving rave reviews by our PUMP-FLO Premium beta users. The PUMP-FLO Premium service is scheduled to go live, Summer 2010. Sneak Peak

Now it’s time to hear from you. Please feel free to share your experiences, or opinions on this blog entry or any other subject that is of interest. I can be reached at blogger@eng-software.com.