Low Code Development in Pega Case Study: Chemical Industry Process Hazard Analysis Application

Share on FacebookTweet about this on TwitterShare on LinkedIn
Share on FacebookTweet about this on TwitterShare on LinkedIn
Pega Hackathon

I am an intern with Segue Technologies, learning no/low code development with the Pega Platform and I recently had a great opportunity to combine my past and present through the Pega Global Hackathon. I was interested in developing a Pega app to submit to test my new software development skills, and to do so, I pulled from my past experience working in the Chemical industry.

Chemical companies like BASF, Dow, Honeywell, and DuPont make money by implementing chemical processes. Every time a company implements a new chemical process, they must prepare documentation called a Process Hazard Analysis, or PHA. This documentation identifies all the risks present in the chemical process and helps mitigate them to ensure that no one gets hurt. For example, if the process uses a pipeline with a valve and toxic chemicals are running through the pipeline, then there’s a chance for leakage at the valve.

By preparing a PHA, the engineers who implement the process can analyze how often the valve will leak, what harm may happen if the valve does leak and how to keep the valve from leaking in the first place. When the engineers analyze these things, they assign letters to represent how hazardous a certain risk is. “A” represents a risk that is likely to happen, will lead to danger and isn’t properly safeguarded. “C” represents a risk that is less likely to happen, will lead to dissatisfaction and is more properly safeguarded. “B” represents a risk that is moderate (between A & C), where the dangers are relatively acceptable. The purpose of preparing a PHA is to minimize the number of “A” risks and maximize the number of “C” risks.

But that’s really simplifying what a PHA is because a valve leaking is just one risk, and in a whole process, there will be hundreds. Not only can a valve leak, it can freeze, it can fail mechanically, it can open inadvertently, it can lock open or closed, it can become fouled or corroded, it can be impacted externally and internally, it can be subjected to abrasive or particulate matter, it can be subjected to backflow, etc. All these risks for the valve must be considered for frequency, severity, and safeguards before being assigned an A, B, or C. That’s just for one valve!

There will likely be more than 20 valves per process but that’s the least of the problems. Companies still must consider heat exchangers, compressors, pipes, reactors, tanks, vessels, electrical equipment, cooling towers, columns, pumps, controllers, mixers, separators, expanders, flares and even more! It’s easy to see how difficult preparing a PHA can be but it’s necessary to prepare to ensure the safety of the workers, customers, and residents surrounding the plant. If there were ever an accident, one of the first documents to be reviewed is the respective PHA for that process.

Since this documentation is very lengthy and important, chemical companies will often hire 10+ engineers to work for a full work week (40 hours) to prepare just one. Since a PHA is required for every chemical process at a plant – and many chemical plants have numerous processes – performing several PHAs a year.  That’s an enormous amount of Chemical Engineering manpower spent on PHAs!

I learned about the PHA process while working at BASF as an intern while pursuing my Chemical Engineering degree from the University of Cincinnati. Both in school and at work, I had to participate in many PHA meetings, so I know firsthand how tedious they can be. I was inspired to automate the process as much as possible to help simplify PHA creation. Most engineers don’t enjoy producing these, so minimizing labor hours involved in making a PHA would be beneficial for any chemical manufacturer. In college, I also took and taught classes in introductory programming languages such as Python, MATLAB, LabView and VBA. These languages seemed more difficult to build an entire application with (as most applications are comprised of several different languages). When I got the opportunity to learn and work with Pega by interning for Segue Technologies, I realized that it would be the perfect fullstack language for which to develop my idea for the application.

When developing in Pega, I enjoyed how creative it allowed me to be while still providing structure that would optimize my app more efficiently than if I were working with a language like C++. Although I had only started my Pega training on April 1st of 2020, I had access to the valuable resources at the Pega Academy and the Pega Community. These resources allowed me to search for what was relevant for me to learn to implement what was necessary for building my app. Not only that, but Segue Technologies provided me with access to Senior System Architects who were extremely helpful the whole way through!

The resulting app that I created with Pega expedites PHA creation by guiding the user through the most tedious parts of producing the documentation by automating some of the repetitive decision points and calculating the risk ratings. The PHA meetings are often extra-long because it’s hard to think of all the possible things that could go wrong with each chemical and apparatus. My Pega app delineates all the common risks for each apparatus by asking the user guiding questions which makes identifying the possible hazards easier. Once the user answers these questions, the app assigns a number for the severity and the frequency of each hazard. These numbers are then used in a calculation which the app runs in the background & assigns the risk to “A”, “B”, or “C” depending on the result of the calculation. The user can then see this rating and gets a chance to choose adequate safeguards which will be factored into the calculation in order to drive the rating down. Once complete, the user can print out the hazard, risk, frequency, severity and respective safeguard for each potential danger. After developing this application, it was easier for me to build other Pega projects, as this Pega Global Hackathon submission gave me a newfound respect for the platform. I truly believe that low-code/no-code languages (like Pega) are the way of the future as they allow a more seamless integration between the developer and the user. This movement allows a developer to obtain completed products very quickly, while handling other aspects of coding under the hood. Pega allows developers to work with actual tools as opposed to lines of code. I doubt I would have ever been able to develop this application if I had to work with any other software products. Now chemical companies can reap the benefits of this application and save their company money without ever sacrificing safety!

Learn More:

Partner with Segue

Contact Us