PIPE-FLO Nuclear

Millstone Power Station. Image via www.nrc.gov

Now that PIPE-FLO Nuclear is nearing its release, one of our new employees asked me how someone in a nuclear power plant could use the new program. That got me thinking about my first job after getting out of the Navy. In 1975, I was hired by Northeast Utilities as a start-up and test engineer at Millstone Unit 2 in Waterford Connecticut. I was assigned to a group of five engineers involved in a pre-operation test in which we balanced the component cooling water system. The component cooling water system is a safety related system and must be operational after a postulated accident.  
This involved test went on 24 hours a day for about two weeks. It started when the engineers at Bechtel in Gaithersburg, Maryland (the EPC for the plant) sent us a datasheet with the prescribed valve position as the initial “guess” for balancing the system. 

During the second shift, the plant operators placed the component cooling water system in the proper configuration for the test. The team of test engineers would place the throttle valves to the prescribed valve position. Once this was done, we would then record the pressures and flow rates using the installed plant instrumentation. We would compile the information into a report; type in onto a report and by about 5:00 AM, would finally fax the results to Bechtel in Gaithersburg.
 
During the day, a group of engineers at Bechtel evaluated our test data from the night before, and after a day of calculations, compiled a new set of valve positions. They would then type a report with the new valve positions and fax it to us by 7:00 PM, so we could repeat the process. This was an iterative process and after each round of test data and new valve positions, the flow rates to each load in the cooling water system got closer to the design values. This process continued for about two week until the results were within the prescribed value outlined in our Final Safety Analysis Report (FSAR for short).

Image from the 1999 movie "Office Space", where
disgruntled workers obliterated their fax machine.

As you can see this was a team effort with about ten engineers in two location working around the clock to balance a critical system in a nuclear power plant. Even the FAX machine required two full time operators, using a Xerox Magnafax Telecopier, one at Millstone the other in Gaithersburg. Let me quickly describe this arduous process and this is such old technology I could not find a picture of one anywhere on the internet, but try to imagine with me. The fax machine was a hefty 46 pounds and was connected to a standard telephone buy inserting the phones handset into an acoustic coupler. The operator sending the fax would place a call on a POT (Plain Old Telephone) to the operator on the receiving end. The sending operator would then place the page on a drum, to start the process the drum would rotate, the machine would screech and once the two machines were talking to each other the receiving operator would flip a switch and the Fax would come through line by line. After six minutes, a single page was done and the operators would then manually reload the paper on each end and start the process for the next page in the report. With two good operators, we could transmit a six-page report in an hour! 

As you can see, technology has come a long way. About 10 year ago, I met up with one of the test engineers from Millstone. He was now in plant management and said that they used PIPE-FLO to calculate the valve positions needed to balance his plants cooling water system. I asked him how long it took with PIPE-FLO, and he said once the model was validated, the valve positions were calculated within seconds. The operators then set the valves to the prescribed position and then took the pressure and flow readings just like before. Now they would compare the calculated values with the observed values. If the results were within the prescribed values, the test is signed off. He said from start to finish they were able to balance their equipment cooling water system in less than a day. 

In 2005, the NRC granted Millstone 2 and 3 a 20-year extension on their operating license after an extensive 22-month review process. I find it remarkable that after 40 years, the plant that I helped start up is still running and has another 10 years of operation. 

One of the reasons that the US civilian nuclear power program has been so successful and safe is because of the quality requirements placed on the equipment, and the training requirements of the plant personnel.


Our soon to be released PIPE-FLO Nuclear program comes with an extensive Commercial Grade Dedication in which we document the engineering methods used, outline our development and testing programs, along with an extensive set of test procedures that we developed. To automate the testing process we use PIPE-FLO’s DataLink feature to export design data and calculated results from the PIPE-FLO model to any ODBC capable program like Microsoft ® Excel® or Access®. 

Using the Excel spreadsheets included in the PIPE-FLO Nuclear, one is able to compare PIPE-FLO’s calculated results with the results calculated using Excel. The Excel Verification Worksheets utilize conditional formatting to automatically highlight any values greater than those specified in the Acceptance Criteria. By using Excel, anyone can review the formulas use in the spreadsheets and validate our check calculations.

Nuclear power plants have used PIPE-FLO for over 20 years, but until the release of PIPE-FLO Nuclear, each of our utility customers had to develop their own Commercial Grade Dedication, which may take months to develop. Since a Commercial Grade Dedication needs to be performed for each new version of PIPE-FLO, and the cost is so high for them to perform the work, many use older versions of PIPE-FLO. 

By making PIPE-FLO Nuclear available to our nuclear customers, they will benefit from the latest versions of the software much more quickly. They will still need to run their own commercial grade dedication, but using our supplied templates, they will be able to do their own CGD in a fraction of the time.

Now that is progress. 

Continous Uptime

Engineered Software and PUMP-FLO Solutions are and have always been, committed to our customer’s satisfaction, as well as their user experience. Along with offering the best support in the industry, we also look to implement proactive measures so our customers never have to use their support service or wait to use their web products from us. We are monitoring Continuous Uptime more closely than ever before using even finer detailed reports, and this month's blog explains what that means for you.

Our latest improvements are completely behind the scenes but the results can be felt throughout our product lines and website users. The term, Continuous Uptime might seem out of place in the technology industry but I assure you, it is just as important to our customers as it would be to a production supervisor in an industrial manufacturing plant.

 

What we’ve done

In additional to significant investments in our infrastructure to enhance the availability and scalability of our delivery framework, we have created a monitoring system for all of our PUMP-FLO and Engineered Software web services on Amazon Web Services. This includes metrics and warnings for standard server attributes like CPU, memory and disk storage. In addition, we have created custom metrics to monitor performance and response times.

The monitoring system is the first step toward a fully distributed and scalable web services environment, which is currently in progress.

Why we’re doing it

We understand pump selection is:

1. an integral part of how pump manufacturers communicate with pump buyers
2. an integrated part of their sales and quotation process
3. a key advantage for system designers
4. a valuable lead generation tool

PUMP-FLO web services and our Insight configurator are key to our customers’ business goals and their strategic initiatives to grow revenue, penetrate new markets, and improve organizational efficiency.

We’re advancing scalable, web-based and secure technology for pump selection to meet those needs and ensure a stable, continuous platform.

PUMP-FLO is a worldwide web services platform and as such, we strive for 24x7 uptime. By implementing this uptime monitoring system, we are able to provide more flexibility, reliability, quicker response times and additional security all while our services remain uninterrupted for our customers.

The First PIPE-FLO 12 Training

Estimated Reading Time: 4 minutes 32 seconds. Read Later

I just got back from running two weeks of training in Bahrain. The client had two groups of 16 engineers that went through our two-day Piping System Fundamentals course followed by our two-day FLO-Master course on our PIPE-FLO software. This also happened to be the first FLO-Master training course we conducted for the newly released PIPE-FLO Professional 12. Since the Piping System Fundamentals course had not been recently change, that course went smoothly and lead perfectly into the FLO-Master course.

Before releasing any new program, the entire development team is on pins and needles worrying about a myriad of details; Will the customers like what we have done? Is the user interface as easy to use as we think? Will they like the new group edit feature? Will someone find a bug that somehow missed our testing?

What really made this exciting is that Bahrain is half way around the world from Lacey, Washington, with an 11-hour difference in time zones. I also learned that the workweek in Bahrain starts on a Sunday. As a result, when I started the class on Sunday morning in Bahrain, it was Saturday evening in Lacey where all our support staff is located.

Since we have a top notch customer support group that has set up hundreds of training centers for our PIPE-FLO class I wasn’t worried about the software installation. Once again, this is the brand new PIPE-FLO 12 program and the training material was still fresh from the printers. First runs will make anyone nervous, even a training and PIPE-FLO veteran like myself.

There were 14 attendees in each course, and 3-4 people in each group had experience with PIPE-FLO 2009, but the majority had no previous PIPE-FLO experience. We started out by exploring the PIPE-FLO interface starting with the existing FLO-Sheet then introducing the new Toolbox, Property Grid, List and Message windows.

In our FLO-Master 12 course, we tend to spend more time on how to make the most of our piping simulation software. Our users fall into three groups, people involved in designing piping systems, those involved in testing and commissioning system, and those who operate and maintain piping systems. Each one of these groups has special needs, and PIPE-FLO’s new flexible interface allows each group to customize the interface to best meet their needs. With the attendees familiarized to the way the program looks and basic functionality, I then moved into the usage and case study portion of the course.

In the first case study, we design a caustic dilution system with two centrifugal pumps, two control valves, static mixer and multiple tanks. In addition to the “how-to” steps dealing with equipment selection we also discuss ways for arriving at a reasonable design margin for pump and control valve selection.

Design options are quickly and easily modeled using new functionality that speeds up the drawing process, including the expanded group select and edit features. For example, by selecting all the pipelines in the project then using the property grid, you can change the pipe spec and fluid zone from the drop down list boxes and all selected pipelines are updated. This greatly reduces the time it takes to build a piping system model.

The second case study has two sections. The first section deals with building onto an existing piping system model and validating the changes to the model. The second section takes the recently created piping system and uses it to help troubleshoot a maintenance problem followed by a process modification.

Prior to building the piping system model, we discuss the various design documents that can be used to build an accurate piping system model. Once all design information it is entered into the PIPE-FLO model, it should provide an accurate representation of the initial system design. Conducting the walk down enables designers to determine if any non-documented changes were made to the system.

The final element in building the model is to validate the systems operation. Taking actual readings from the real piping system and comparing them to the piping system model. The FLO-Master course covers which elements and readings are best to collect and validate.

Once the mode is set to accurately represent current system operation, the simulation is run and the calculated results are compared to the plants operating data. We then move on to the second section of this case study and troubleshoot the system to determine where any problems may lie.

The second section of the case study deals with how the model is used in troubleshooting the operation of a system and how the model can be used to conduct plant studies. In the final example a new process load is added to the system and we discover why the system is unable to meet the new process demands. More importantly with the PIPE-FLO model, we are able to evaluate possible system modification that will meet the new process requirements quickly and without having to do any modifications to the actual running system.

The final example was opened to the attendees and I encouraged them to bring a real piping system they currently evaluating. One of the participants brought in a project that he recently inherited. He wanted to model the system under PIPE-FLO so he could compare the pump needs to the pump that was previously selected.

After building the model and sizing the pump, the engineer was able to determine the required total pump head. His calculated pump head requirement was 24 ft of head at the design flow rate. He then compared that to the pump selected and was surprised to see the selected pump produced 240 ft of head at the design flow rate. During his presentation to the attendees, he said he believed the pump was over sized, but he never imagined it would be to that extent. He was able to make the analysis of his system in less than 2 hours!

There were complements galore about PIPE-FLO 12 especially from the 6 people that had used PIPE-FLO 2009. The toughest critics we will likely have will be the users of earlier versions of PIPE-FLO since the program will look much different from before. Their encouraging responses were music to my ears since this was really the introduction of the new PIPE-FLO program as much as it was the new FLO-Master training material.

When I got back to the office, I shared the class’ PIPE-FLO 12 and FLO-Master feedback with the development team. Now that the program was officially released, and with a positive initial reception, they were all smiles. I was all smiles that I accomplished the first public presentation of the new training material! I expect great things from the coming year and I’m truly excited to share the next generation of PIPE-FLO with everyone.

Click to Learn More about PIPE-FLO Professional 12

PIPE-FLO Looking Forward

Estimated Reading Time: 6 minutes 19 seconds. Read Later

Looking at the Past & Preparing for the Future

At Engineered Software for the last 30 years we have continually upgrading our products to take advantage of improvements in computer hardware, programming language, and operating systems, but the major focus of our updates has always been to better meet our customer’s needs. Over the years PIPE-FLO has been upgraded ever 12 to 18 months. Every 7 to 10 years we have a Milestone upgrade in which major program changes take place to take advantage of new technology. We are currently in the final stages of developing our latest Milestone upgrade, which has been three years in the making.

In the early years of computer programming, maybe the mid to late-1980s, software businesses never released version 1 because they believed customers would be hesitant to be the first adopters. Quite often, version 1 was a beta, and this was way before the public would be willing to use beta software. So, in 1982 we released PIPE-FLO version 2.

The major objective of PIPE-FLO 2 was to develop quality, shrink-wrapped software for designing fluid piping system that could be used on computers using the CP/M operating system, along with the recently released IBM® PC. The program was written in C-Basic and used Access Manager so we could take advantage of all ASCII terminals (all text no graphics).

We developed a variety of companion programs (NET-FLO, ORI-FLO, PUMP-FLO, and CON-FLO) using this technology; each capable of reading PIPE-FLO’s pipeline database. Another major first for PIPE-FLO was our use of a graphical interface. Using our NET-FLO/CAD interface and AutoCAD® by Autodesk; our customers were able to insert piping system information into an AutoCAD drawing. PIPE-FLO then read the information from the drawing, set up the piping system model, calculate the results and updated the AutoCAD drawings showing the calculated results. It was well received, but the major drawback was our customer had to own AutoCAD.

 

Windows the First Milestone Upgrade 

 

In 1985 Microsoft released Windows as a graphical interface. After completing PUMP-FLO™ for Windows in 1986, we started thinking of incorporating the Windows graphical interface into PIPE-FLO. To accomplish this, PIPE-FLO had to be completely re-written using the C programing language. During this rewrite we incorporated the functionally from both our existing PIPE-FLO and NET-FLO programs, in to a single Windows application which we called PIPE-FLO version 4. 

PIPE-FLO 4 utilized a commercial database, allowing our customers to build piping systems of any size while employing automatic backup protection. Version 5 and 6 were based on this technology and during this time we integrated the drawing of the piping system directly into PIPE-FLO. We also released our utility programs for pump selection, control valve selection and flow meter sizing programs as Windows applications with the capability of reading the PIPE-FLO’s Pipeline Database. 

Our customers really liked the integrated flow sheet drawing along with the ease of use offered by Windows. In talking with our customers, they wanted us to make it easier for PIPE-FLO to select equipment such as pumps, control valves, and flow meters. In addition, they wanted to share their project with others in their company as well as customers and vendors they work with.

 

Security, Integration, and Ease of Operations 

 

In 1998 we decided to embark on next Milestone upgrade, PIPE-FLO version 7, with a final release in 2000. During this major rewrite we decided to stop using the commercial database employed in PIPE-FLO versions 4 through 6 and developed a proprietary data structure for the Piping Project. Thus introducing the .pipe file extension type into the lexicon. This allowed us to speed up disk operations, create smaller project files, and allow for easier sharing of the piping system model. We also tightly integrated the three stand-alone utilities for pumps, control valves, and flow meters into PIPE-FLO.

Another major goal was to achieve consistency of operation with other Windows applications. For example we modified PIPE-FLO’s drawing tools to reflect the operation of common CAD programs such as AutoCAD®, Visio®, and Pro/ENGINEER, this way our customers already knew how our drawing tools operated. In addition, we made our list view to look and feel more like a spreadsheet providing the opportunity to sort the list, choose items to work on, and even giving them the ability to edit on the list. The PIPE-FLO Viewer program was also introduced allowing customers to share interactive piping system models created by PIPE-FLO Professional without the other individual needing the full PIPE-FLO program. Finally the X-Link feature allowed for two-way communications between PIPE-FLO and Microsoft® Excel®. 

Our customers continually provide suggestions on ways to improve PIPE-FLO. Recently we have noticed that many of their suggestions deal with workflow within their organization. For example, engineering firms wanted to develop their own customized reports and share information with other departments (both engineering and purchasing). Our customers at industrial plants were looking for easier ways to build a PIPE-FLO model using data from other programs. 

 

Third Milestone Upgrade

 

In 2009 we started working on our third Milestone upgrade. Our product development team had grown to five engineers, six application developers, and two test developers. To accommodate this larger team we needed to streamline our internal development process so we employed the Agile development process and integrated our program testing into every stage of product development.

Regarding PIPE-FLO, we determined the upgraded program must have the same functionality as earlier versions of PIPE-FLO, but we wanted to make it easier for our customers to integrate the software in their workflow processes. 

To accomplish this, our engineers started categorizing every customer support ticket and feature request looking for ways to streamline and clarify program operations, improve consistency, and provide the added features that our customers had requested. Next they started evaluating other commercially available software including engineering, business, and software development applications.

After reviewing the programs they developed a list of guiding principles for the Milestone upgrade:
   •    Minimize the use of dialog boxes whenever possible
   •    Increase consistency of operation within the PIPE-FLO program as well as other software tools used by our customers. (CAD, Microsoft Office®, engineering analysis tools, etc.)
   •    Make it easy for PIPE-FLO to incorporate new program features in the future

With this list of goals, our engineering team started developing “stories” for all existing PIPE-FLO features. These stories document how the feature worked, how the customer used the feature, the required data input, formula used to calculate the results, along with how the results would be used.

Once each story was defined they were reviewed by the developers to help them determine how the final program would work. With the big picture provided by the various stories, the software developers created “objects” that compartmentalized the task that can be re-used for the various program elements. This is mostly behind the scenes but manifests in the ability to add new features much quicker later on. The PIPE-FLO calculation engine was also compartmentalized allowing the developers to supply the piping system data to the engine, and then utilize the calculated results.

This required major revisions to ever stage of program development. Approximately half of the development effort involved building the internal program infrastructure to provide flexibility of the engineering units, develop the various program objects, and passing of information to the various objects. Once the infrastructure was developed the various piping system elements (pumps, controls, components, tanks, pipelines, etc.) were incorporated into PIPE-FLO using the pre-defined objects.  Using this approach the engineering team was able to work with the actual PIPE-FLO program through the majority of the development cycle with new program elements being continually added.  Using this approach and the Agile development process we were able to fine tune the user interface as new components were added.

The final step in the development process was implementing the user interface items. This included multiple object selection, the addition of the printed reports and graphs, along with the ability to extract and work with input data and calculated results.

Multiple object selection is one of the major new program features. In the most previous version of PIPE-FLO, you could only select similar items in a rectangular selection window and once selected the objects could be copied, deleted, or moved. In this upcoming milestone update, you can select a group of object in a rectangle/s, select individual items from the flow sheet, select individual or multiple items from the list view, as well as de-select items. In other words, our group select tool is identical in operation to group selection tools in CAD programs and Microsoft’s Excel. Once a group of items are selected you can copy and move the objects, edit the design data, change the text font, or insert a note in a single step. This feature even applies across object types. For example, in the new PIPE-FLO, both tanks and pipelines have fluid zones, using the multiple select tool you are able to change the fluid zone in the selected pipelines and tanks in a single step. 

Multiple object selection is just one of the many new and time saving features in the next release of PIPE-FLO.  In the coming weeks we will be releasing more information about the next release of PIPE-FLO, but the biggest secret is the name for the next release, for that you must wait.

Here's a sneak peek at the upcoming version of PIPE-FLO. Make sure to send me your comments and thoughts on the new look and feel. CLICK the image to view larger.

PUMP-FLO Beginnings: ESCAPE

Estimated Reading Time: 6 minutes 25 seconds. Read Later

Since we started the countdown to the Engineered Software 30th Anniversary, I have gotten many requests to describe the development of some of our programs. The subject of this blog is a short review of the creation of PUMP-FLO.

It was after an upgrade of our PIPE-FLO / NET-FLO programs (footnote 1) (in DOS) that we started calling our customers, asking how they used the software. The main response was, it helps in calculating the design point needed for centrifugal pump selection. After the 5th or 6th such call we had a good idea that our next program should help in the selection and evaluation of centrifugal pumps.

In 1985, we started program development and in two months, PUMP-FLO was finished and became the fifth in our FLO-SERIES (footnote 2) of piping software. This first version was a DOS program where the user entered the pump performance data, and the program calculated the power requirement and the Net Positive Suction Head available. In addition the impeller diameter and speed could be adjusted and the program calculated the new pump performance data.

There were two problems with that first version preventing wide use of PUMP-FLO: first, it did not display a pump curve, and second the user had to manually enter the pump data. There were provisions in the program so manufacturers could supply their data in electronic pump catalogs for use by the program. We set out working with pump manufacturers to create their electronic pump catalogs; we offered to do it free if they would make the data available. I got a list of 80 centrifugal pump manufacturers sent out mailing to all and got zero takers.

In 1987, I was a panelist at the Society of Plumbing Engineers session discussing the availability of engineering software for piping calculations. Tim Smith, from TACO Pumps was also a panelist, and was demonstrating their new pump selection program. The user entered a design point and the program search through the TACO catalog and presented a list of pumps meeting their needs. It could display the pump curve on an IBM Color Graphics Adapter (CGA), or the Hercules Graphic Card (HGC).

In talking with Tim he said the majority of the development work was writing the device drivers for the two graphics cards, and the Epson MX-80 dot matrix printer. After seeing this I knew PUMP-FLO had to display a pump curve, but we didn't want to have to write device drivers for every new monitor and printer.

In 1988 we were developing an AutoCAD interface to our NET-FLO program and I needed a mouse pointing device. The mouse I purchased was bundled with Microsoft Windows Version 1. After using the mouse with AutoCAD and really enjoyed the ease of use a mouse pointing device for CAD applications.

During that time period Microsoft had a strong marketing push saying program’s written using their Windows environment did not have to write their own device drivers, Windows took care of that for you. I realized that if we made PUMP-FLO a Windows application we could display and print pump curve without the hassle of writing device drivers.

In 1988 we decided to make PUMP-FLO a Windows application, now all we needed was a launch customer. Once again I fired off letters to 80 manufacturers stating what we could do for them, and then waited. This time we got 1 response from Aurora Pumps in North Aurora Illinois. It seemed their sales people were getting asked by their customers when they were going to have a pump selection program like Taco.

We showed them an example of our DOS version of PUMP-FLO; they were interested but said their program needed to display and print the pump curve. I then showed them a mockup of what a Windows based pump selection program would look like (developed using MS Paint) and saying it could support all available graphical displays, printers, plotters, and pointing devices. I was giving them such a sales job I sounded like I was working for Microsoft.

The discussions continued, they sent one of their sales engineers to our office to discuss what the program needed, then asked us for a proposal. We gave them a rather optimistic schedule for delivering the program, and they said we had a deal if we could chop two months off the schedule so the program would be ready for their annual sales meeting in early February.

At the time, we thought the money was good, and in June 1988, we signed the deal. After signing the contract, Carolyn Popp (the other founding principal at Engineered Software), signed up for a two day C programming class, and a three day Windows developers course.

After attending the C class, she said it was just another language and should have no problem picking up the language. The next week she went to the three-day Windows programming class. The instructor was one of the original Windows developers, and many of attendees in the class were Microsoft employees learning how to support and write their application tools. She came back saying Windows was much harder than estimated, and was concerned about our 6 month schedule. Yet, in a couple of weeks, she was able to get her program to compile and display a crude menu, so she felt a little better.

Aurora had approximately 600 individual pump curves that needed to be entered into their electronic catalog. I was the lead on this effort. It took approximately 90 minutes to enter a pump curve into the catalog, and with 600 curves to enter I quickly realized additional help was needed. Enter the interns, we hired two drafting interns from a local technical school and started creating the catalog. While entering the pump curves we streamlined the process and cut the time to 60 minutes per pumps.

To meet our schedule both Carolyn and I were working 12 hour days, 6 days a week, on Sunday we cut our day down to just 8 hours.

By September, the catalog was being built, and the program’s menu structure was established. Carolyn was working on the pump selection engine and displaying the selection list on the screen. Aurora was having a sales manager meeting that month and they wanted us to show what we have accomplished to date and how the program would work.

Carolyn was getting the program together so I could practice my demonstration before heading off to Aurora. I heard a blood-curdling scream coming from her office saying, "The program doesn’t work anymore!" She tried to recreate what she was doing, but she couldn’t get the program working again. By this time, it was after midnight and I needed to get some sleep before my flight to Aurora at 6 later that morning. She stayed at the office and said to stop in the office prior to going to the airport. At 6:00 am the next day I saw a single disk on the desk, a mouse on top of the disk and a note saying “It works. YOU MUST USE THE MOUSE, whatever you do, don’t use the keyboard.”

When I arrived in Chicago, Aurora met me at the airport with a town car and took me to their offices for the demonstration. I had no idea why the program crashed the previous day, I use only the mouse and everything worked OK. Since we had not completed the graphing function of the program they were treated to an MS Paint generated sample graph window. They liked what they saw, then re-enforced the need to meet the schedule because the program was the highlight of their meeting. They then thanked me for coming and I was on my way.

By mid-January 1989 after spending hundreds of additional hours developing and testing the program, and entering and checking their pump performance data we had a working program. At their February 1989 sales meeting, we demonstrated their pump selection program called ESCAPE (Engineer’s Selection & Computer Aided Pump Evaluation).

After demonstrating the program at the keynote meeting, we got a standing ovation. There were plenty of handshakes and back pats to go around and everyone was all smiles.

That afternoon we had to train over 100 sales people on how to use ESCAPE. We had four, one hour familiarization classes with 25 attendees per class. We had everyone go through a pump selection and evaluation and it was amazing how easy they were all able to pick up the program.

When the last class was finished at 4:00 PM, we still had a crowd of 30 to 50 sales people waiting to use the program to select pumps for their customers. Finally, at 6:00 PM we were exhausted and had to lock up the computer room. At the happy hour with an open bar, (after all it was a sales meeting), we were introduced to the President of Aurora Pump. He congratulated us on ESCAPE and thanked us for saving him so much money. Since the program had not yet been released, I ask how we saved them so much money. He said normally the sales people continued their discussions at the open bar, and that year’s bar bill was $10,000 less than previous years because so many of the sales people were using the program.

Once the Aurora ESCAPE program was completed and launched, we started working on our PUMP-FLO program. We started working with other pump manufacturers to create electronic pump catalogs for their products. In the next blog I will be talking about the trials and tribulations of creating pump catalogs for use with PUMP-FLO.

Do you have any questions for me? 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 for reading!

---

Footnotes

1. Prior to the release of our windows version of PIPE-FLO 4, the functionally of our piping simulation software was broken into the PIPE-FLO and NET-FLO programs. The DOS version of PIPE-FLO was used to design single pipelines and save the designed pipelines into a pipeline database. Using NET-FLO our hydraulic network analysis program; people would build a network by connecting the individual pipelines from the pipeline database into a total system complete with pressure sources, pumps, components, controls and demands. The reason this was done was that in the early days of microcomputers (even prior to DOS) programs were limited to 64 kilobytes of both memory and program space.

With the release of Microsoft Windows version 1 with its improved memory management and larger addressable memory we were able to combine PIPE-FLO and NET-FLO into a single program called PIPE-FLO Professional. Back to top

2. Prior to the release of Microsoft Windows, we had separate programs to handle various functions needed for piping system design. We called our group of products The FLO-SERIES. PIPE-FLO was used to design or enter individual pipelines into a pipeline database. All the other programs in the FLO-SERIES could read design information from the pipeline database. Our SYS-FLO program calculated how a system of multiple pipes and pumps in series would operate. Our NET-FLO program was for multiple looped networks.

We also had utility programs that could run as a standalone program or read pipeline design data from the database. This program included ORI-FLO for flow meters, PUMP-FLO, CON-FLO for control valve selection, INS-FLO from calculating insulation thickness and FLO-MANAGER. We marketed these programs as The FLO-SERIES. Back to top

---

Testing 1, 2, 3...

Estimated Reading Time: 5 minutes 26 seconds. Read Later

The Importance of Product Testing

As mentioned in my September blog, Engineered Software will be celebrating 30 years in business in 2012. In that post I listed the core value we have followed to better meet our customer’s needs and expectations, specifically:

1. Create a sustainable company
2. Create product that can be used by a wide variety of people, not just engineers
3. Play well with others.

In this month’s blog I will be sharing with you how our software testing has evolved over the years.

When we started Engineered Software both Carolyn Popp and I (the two founding principles) saw the value of developing a testing program for our software. Our feeling was, if we released a program that had a calculation error, our customers might not trust our new company. In addition, if the customer had trouble entering the necessary data or lost data due to a problem with the program, we were not providing them with the value they expected. For the first version of PIPE-FLO, we developed a series of program features; the formulas the calculations were based on, along with a set of example calculations. These example calculations included a variety of edge cases designed to test the program source code.

I developed a series of test problems from text books, technical publications such as the Crane Technical Paper 410, along with developing a series of calculations performed using an electronic calculator (remember 1982 pre-dated Lotus 123 and Microsoft’s Multi-Plan). A set of calculations sheets were developed complete with the equations, references, all input values, along with intermediate and final calculated results. Prior to every program release, these examples were entered manually into PIPE-FLO and the results validated. Carolyn, a former IBM system engineer, was just as adamant on program testing and validating prior to program release.

Our third & fourth employees, Jaclyn and Kathleen Byron (we often called them J&K), both with mechanical and civil engineering degrees, were hired to improve our program testing, provide customer technical support, and assist in software development. Based on their customer interaction they were able to created test procedures to validate all engineering calculations along with the user interface. They also were responsible for automating the test procedures by developing test scripts for each program feature.

When one of the software developers finished a new PIPE-FLO feature, J&K created an automated test, and checked the results. Any problems with the new feature were brought to the attention of the programmer and resolved. Once we had a PIPE-FLO release candidate, we would perform all automated tests again to validate the software results prior to release. The release testing took approximately 2 – 4 weeks to complete, allowing the correction of last minute program bugs, along with a review of the test results.

As our company grew, we added more programmers and engineers to our development team. In 2006 we decided it was time to update our software development and testing practices by implementing the Agile Software development process.

The major impact was to document the proposed program features and so everyone knows how the feature works. The process starts by engineers creating “stories” for each feature describing how customers used the feature. The application developers would write the program code to meet the requirements listed in the “story”, and the developers in test would develop the testing needed to ensure PIPE-FLO meets the “story” requirements.

Testing is now broken down into unit stages:

• Unit Testing
• Integration Testing

To demonstrate I’ll use an example for calculating the fluid Reynolds number. First engineering first creates a “story” defining the Reynolds number calculation, the data that must be supplied, and a variety of examples with the calculated results.

The application developers create a function for calculating the Reynolds number. The new function is placed in the function library used by all developers that need to calculate the fluid Reynolds number. In addition the developer creates a “unit test” based on the example calculations supplied by engineering in the “story.” The unit test is then placed in the unit test library that is run every time the program is compiled by any developer.

Now let’s say the developer creating the orifice sizing feature needs to calculate the fluid Reynolds number of the orifice. The software developer will use the previously defined Reynolds number function. If the function needs to be modified for the orifice sizing calculations, (say using the orifice diameter instead of the pipe diameter) then the Reynolds number function in the library may be modified by the developer writing the orifice feature. Once a developer compiles the program on their local computer the Reynolds number unit test will be performed to insure nothing was changed that would give bad Reynolds number results for either the pipeline or orifice Reynolds number calculation. If the test fails the developer knows immediately there is a problem in the Reynolds number function and makes the necessary correction.

Once the developer has completed the orifice sizing feature on their computer they check in their code to a central build server. The build server is where all programs are compiled for release. Once the code is checked in on the build server all unit tests are performed on the code, if any problems occur the developer is notified immediately. The build server performs all unit tests each time any one of the application programmers check in their source code.

Integrated Tests are developed by a separate group of programmers that specialize in software testing. The developers in test create the integrated tests to ensure the program’s higher level features work as called out in the “story.” The majority of these tests are developed to test PIPE-FLO’s user interface.

For example in PIPE-FLO the pipeline graph window shows the fluid Reynolds number over a range of flow rates. The developers in test will create an integrated test to check that the graph window is acting as defined in the story. For example the integrated test may check to see that the Reynolds numbers are graphed and displayed and the user also has the ability to change the color.

In the past the integrated testing was conducted when the feature was initially added to the program, and at the completion of the program prior to program release. The time difference between initially adding the feature releasing the program could be measured in months. During that time span a developer may make a change in a new feature that has an effect on a previously tested feature.

With our new automated testing once an integrated test is written to test a feature it is added to the test suite on the testing server. Every night the test server performs all automated tests.

In the evening, the test server takes that day’s program from the build server and loads it to the test server. The test server loads the current program onto multiple computers on the test farm. The test server then assigns the various integrated test to each computer and keeps track of the results. Currently there are about 10 computers in our testing farm and it takes approximately 6 hours to perform the test and review the results.

The next morning each member of the development team can check to see if the code they wrote yesterday has an adverse effect of the program development. If any of the tests fail the developer will be notified and can make the necessary changes that day.

This testing has paid off for both Engineered Software and our customers. In the last two versions of PIPE-FLO we have only had to issue one maintenance release to correct problems associated with the program. A more reliable program means less stress for such important engineering choices, and our aim is to make our customer’s job easier.

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 for reading!