Blog
Back to All Posts

Posted by Shawn Gwin

When a screwdriver just won’t do… Building custom software tools for the job

June 4, 2019

Custom software applications can provide great benefit to plant automation and engineering teams. Any task that includes the management of large amounts of data, repetitive entries or utilizes the same information in multiple places lends itself to developing software that can automate these activities.  The benefits from a well designed and implemented application can include greatly improved productivity and quality.  I will share with you a recent example of how a custom application saved time and money while improving quality.New call-to-action

In early 2012, I joined Hallam-ICS to build custom software applications to replace the tools they were using to manage the design, installation and validation of a Toxic Gas Monitoring System (TGMS). These original tools were ones that the company had utilized over the years for different customers but they were not meeting the needs of a new customer who was constructing one of the biggest computer chip manufacturing plants in the world with the biggest TGMS that Hallam-ICS had ever developed!

In the past, Hallam’s TGMS customers had systems that consisted of hundreds of input and output (I/O) points. In order to manage these I/O points, various Excel spreadsheets had been developed to map how one point would connect to another. It would also keep track of the equipment names, gases and other important information. Maintaining these spreadsheets became a labor intensive process that was also prone to errors due to manually entering the data.

sample spreadsheet

Figure 1: Sample of original spreadsheet

They initially tried to make use of the existing spreadsheets, but it became evident that the size and complexity of the work required something more robust. Early in the project, the primary concern for the customer was speed of development (to meet construction schedules). But, as parts of the plant became active with manufacturing, speed remained important, but the impact of an error became greater. Eventually, the client demanded a “zero defect” process so that manufacturing would not be impacted and safety was ensured. This required improving our approach to QA/QC and lent itself to automating the process of design as well as PLC and SCADA programming development.

First, Identify Requirements and Goals

Our first step was to define and document what we wanted to achieve with our custom application. Beyond utilizing new tools and creating something cool, there has to be a business case for creating a custom application. In our case, the primary goal was quality with a secondary goal of productivity improvements. The customer demanded 100% accuracy on all installations and the construction schedule was beyond aggressive.

Goal #1 - Quality

Since a TGMS is both a life safety system and a system that can disable production, accuracy became the most important feature to implement. The original spreadsheets only allowed for a user to manually enter in the data and then that data was manually copied to other spreadsheets. This copy and paste or duplication of entry created a potential for human error.

The purpose of the web application was to replace these spreadsheets. To increase the accuracy of the data that was being entered, the values that were already used or were not applicable to the chosen type were not shown to the user. In addition, data was automatically generated where applicable to avoid any mistyping. Lastly, complicated business rules were applied as error checks to the data so that it would be as valid as possible.

Gas Distribution Form

Figure 2: Form to enter gas equipment. Names and points are automatically generated.

Goal #2 - Productivity

In addition to the accuracy of the applications, productivity was also important, both from an ROI standpoint as well meeting project schedules. Before the web application was developed, the manual creation of the documents and the eleven-step QAQC process took roughly eight man hours to complete. The new web application decreased this time to under 10 minutes! This allowed the team to keep up with the increasing workload as the project ramped up while also gaining better accuracy in the data.

Efficiency was not only produced by automating some of the process. It was also accomplished by limiting the choices that an individual had to make by only populating the drop-down lists with the appropriate values based on what was previously chosen. This, in turn, reduced the amount of QA/QC that had to be performed as well.

PLC Desktop application

Figure 3: PLC Desktop application comparing new data to live PLC data.

Selecting the Right Platform

Once the goals were established, the next step was to determine the platform. Who are the users? How will they interface with the data? What are the requirements for the application? All of these questions needed to be answered to find the right platform for an application.

In our case, many prototypes were built and tested to see what would be the optimal platform to develop custom tools to solve the limitations of the spreadsheets. The first was to build an internal application that would run inside of the company’s SharePoint server. Although this would allow the application to be contained within the company’s network, the limitations of SharePoint as a platform soon ruled it out as a viable solution. The next platform tested was Microsoft’s Silverlight framework that allowed desktop level apps to run within a browser on any platform. This platform showed potential but when Microsoft decided to not continue with developing the platform we decided to look for a better solution. We finally decided to build custom web (ASP.NET MVC), desktop (WPF) and tablet (UWP) applications using the Microsoft .NET Framework.

Additional Benefits

When creating your own tools from scratch, the sky is the limit on what you can do with them. Once we committed to capturing the design data into a database, we were able to leverage that data in other areas.

For example, the logic in the Programmable Logic Controllers (PLC) was populated by downloading data in an Excel spreadsheet to the PLC. Originally, this data was manually entered into Excel and could create safety and/or production issues when a value was entered incorrectly. With a database solution, populating these worksheets automatically with error checking eliminated that risk and allowed updates to happen more efficiently. Taking it one step further, we created a Windows Desktop application that allowed the programmer to compare the new data to be loaded into the PLCs with the data that was currently written to the PLCs. This comparison enabled the programmer to have one more level of validation of exactly what would be changed on the PLC prior to uploading the new configuration.

Automatically generated visualization

Figure 4: Automatically generated visualization of how the equipment connects together

We were also able to take advantage of the centralized data by creating a tablet-based application for the testing and commissioning team. The tablet app runs on Windows 10 and provides a form associated with each new piece of equipment that needs to be verified. Originally, this verification was done by manually creating a document for each piece of equipment. With the tablet application, the forms are automatically generated from the centralized data. In addition, supporting information like wire colors for each point were added to help the tester easily identify the correct points. The completed test forms are then synchronized back to the central database were reports can be viewed and printed.

Conclusion

Although it can be a large investment to create custom software tools from scratch, the gains in productivity and accuracy are often well worth it. Moreover, the ability to reuse the same reliable data across multiple applications removes the simple human errors that can be generated by manually entering the data into multiple locations. Our experience on this project was that a custom application helped to ensure our ability to meet our goal of providing the best service to our customers. The cost and effort has been well worth it!

For more information please reach out to our

Help Desk

 About the author

Shawn has left Hallam-ICS to pursue other endeavors, but his contributions to the company continue to be valued.

Read   My Hallam Story  

About Hallam-ICS

Hallam-ICS is an engineering and automation company that designs MEP systems for facilities and plants, engineers control and automation solutions, and ensures safety and regulatory compliance through arc flash studies, commissioning, and validation. Our offices are located in Massachusetts, Connecticut, New York, Vermont and North Carolina and our projects take us world-wide. 

Topics: Process Control and Plant Automation, Toxic Gas Monitoring Systems, Manufacturing Intelligence

Shawn Gwin

By Shawn Gwin

Find me on:

June 4, 2019

Back to All Posts

Subscribe to Email Updates

READ THESE RELEVANT POSTS

How Do I Set Up Modbus Communication In My Modicon Unity PLC?

3 Easy Steps to Share Data Between Modicon Quantum PLCs Using Schneider Electric Unity Pro XL

Programming with Rockwell Automation's PlantPAx

7 Reasons why TGMS and FAS should communicate Webinar Recording Access