Elements of agile project management can help certain automation projects; see how in this upgrade of human-machine interface (HMI) software, programmable logic controller (PLC) programming and more.
Agile project management insights for automation
- A complex automation upgrade to bring a line up to date with the rest of the plant had risks identified during planning.
- A walk-through and automation review helped with planning.
- Before and after images show HMI differences resulting from the upgrade.
Depending on the automation project, agile project management may help. In software development, agile project management has become the way to deliver applications that meet customer requirements at the lowest cost and fastest schedule. Agile works well in this type of project because when only a compiler and a computer are needed, design effort is less and customer feedback is available soon and often.
In industrial manufacturing, systems require much more than a compiler and a computer. Automation projects can include motors, valves, instrumentation, electrical power, wiring, concrete, metal and a lot of other equipment. Commissioning doesn’t happen until all of this is in place and ready for operation. Inherent dependencies require a traditional waterfall approach, so GANNT charts are still the way most industrial projects are managed.
When schedules are compressed, creative ways to manage projects need to be employed. It is possible to blend inherent industrial dependencies with agile techniques to meet schedule. This hybrid approach has proven successful.
Sander line: Hundreds of I/O, thousands of rungs of logic
Plummer Forest Products in Post Falls, Idaho, produces wood boards from sawdust and scraps from lumber mills. The boards are used for flooring material and require surface finishing to meet quality specifications. Finishing is done in the final stage of board processing using an automated sander line.
As for inputs and outputs (I/O), the sander line has 592 discrete inputs, 288 discrete outputs, 16 analog inputs and 8 analog outputs. The original ladder logic for the programmable logic controller (PLC) had 7,398 rungs. The system is complex and requires careful synchronization to ensure boards are properly processed without damage or unsafe operation. In March 2024, the sander had an older generation PLC and human-machine interface (HMI) while the rest of the facility had upgraded to a more modern platform. The objective was to migrate the HMI and PLC-supervisory control and data acquisition (SCADA) system and commission to the same SCADA platform as the rest of the facility by an early June annual outage that would last one week. Failure to meet the schedule would have an unacceptable impact on production.
Automation project management options considered
Approaching such a project with a traditional waterfall project management methodology would have been risky. With waterfall, there would be a design phase that would require approval before development, compressing the development timeline. This would leave very little time to review the completed software until installation, when the team needs to be focused on coordinating installation, loop testing and functional testing.
Hybrid agile project management provided an alternate approach. It was used to rapidly execute the Plummer Sander controls upgrade, with reduced risk and customer visibility in every step of the process.
Design started with walk-through, automation review
The project began with a site visit March 13-15, 2024. This was a two-day walkthrough and review of the current implementation. For a migration project, it is important to trace every I/O output from the logic that drives it to the I/O and to HMI inputs that feed it. While code inspection can provide a lot of that information, being at the facility to see the machine and understand how it works is very important. For industrial projects, spending time with the end user at their facility is the best way to understand their needs and make the connections that serve as the foundation for good communication throughout the project.
Seven automation project risks identified
During the initial site visit we performed a Potential Problem Analysis. This is often referred to as the Kepner-Tregoe method. All project risks are listed, and then the team assigns the probability of occurrence and the severity of occurrence for each risk. Risks with low probability and severity can be ignored, high probability and severity must have a mitigating action, and those in between are evaluated for consideration. For our project, the risks included:
- Tight schedule had a lot of scope; delay could result in serious production impact
- There was some uncertainty on the PLC processor sizing for the application
- A new camera system would require OPC UA communication for I/O that drives operational logic, which could present challenging performance requirements
- Developing the HMI remotely means any changes to the HMI onsite would not be reflected in the version being changed remotely.
- Problems getting new I/O to communicate with the processor could cause delays
- Some HMI tags references wouldn’t be resolved until getting to the facility, which could take time and delay startup
- Some HMI behavior was not confirmed initially, such as button actions and status indication. Resolving problems takes time and could delay startup.
Identifying risks with the end user at the beginning of a project is far better than getting surprised at the end.
Development of HMI, PLC application
Following the site visit, the development was performed remotely by two engineers. One engineer worked on the HMI. The other worked on the PLC application.
For the PLC work, a processor was available to download and run the logic for testing. To take advantage of the new PLC platform, some ladder logic was translated into function block or standard library blocks for motors and other complex data types. This design was used to match the implementation used in other PLCs in the new SCADA platform at the facility. While work was done remotely, remote access software (in this case TeamViewer) could be used to remotely connect to the running system to view the code in the existing PLC. Significant effort was made by the end user on the I/O mapping and tagname configuration so that the PLC code mapped to the correct I/O. Working together, the developer and end user identified the functionality of the logic and captured it in an I/O list.
Digital twin, remote testing, improved HMI
For the HMI work, a software PLC emulation was used to download the logic developed for the PLC to map the HMI to the PLC tag database. This allowed the HMI to be fully tested remotely as a digital twin. The new HMI platform allowed the displays to be designed more efficiently and with simpler techniques. While the HMI closely resembled the existing HMI, the interface was significantly improved. The new platform made it possible to configure tags from the sander into the existing process historian on the new platform. A simplified grade code implementation provided a much simpler way for the HMI to send data to other PLCs in the facility.
During development, weekly online meetings allowed for screen sharing to show the results of the work as development proceeded. This is a fundamental principle of agile project management. Having routine reviews with the end user ensures any mismatch in expectations get corrected quickly so that a departure does not accumulate into large mismatch as the schedule tightens. Also, HMI code and PLC code were on a shared drive for the end user to download and test at their facility through the development process. The HMI could be imported into the new platform so that the facility had a complete HMI for the facility in one platform throughout the development process.
The agile approach to development ensured that the project remained on track for schedule and functionality. Prior to the outage, a final planning meeting covered any outstanding risks and details for loop tests, functional tests and commissioning. The software was installed prior to the outage so that it was ready upon arrival.
On-site I/O work, loop testing
Upon arrival at the facility June 10, 2024, the I/O terminations were not yet complete. The first day was spent making small software edits and addressing any software punchlist items. Later in the day when I/O was available loop tests began. Loop testing and functional testing continued for the next two days, and alarm configuration was completed for the new tags that were added into the platform. By the fourth day the sander could be operated from the HMI, and on the fifth and final day, the sander was running without significant issues.
Results: Integration, support, enhancements
Since June 14, 2024, the sander has been running on the new platform and has been integrated with the rest of the facility. Having a common platform makes it far better for the facility to support the system and make enhancements.
Meeting the automation upgrade project schedule would have been very unlikely with a traditional waterfall approach. The agile approach was critical to completing the migration with minimal issues within the schedule.
Patrick J Dixon is president and Joe Burns is SCADA engineer of DPAS Inc. Shay Simpson is production manager, Plummer Forest Products. Edited by Mark T. Hoske, editor-in-chief, Control Engineering, WTWH Media, [email protected].
Keywords
Agile project management for automation, HMI upgrade, automation migration
Consider this
Are your project management workflows effective for your automation and controls projects?
You also might like
More on HMI, OI is available here:
https://www.controleng.com/control-systems/hmi-oi
Another Control Engineering article from Patrick Dixon, see:
The velocity of PID
