Data Integrity, Why Do You Need It?

Data Integrity, Why Do You Need It?

What is Data Integrity?

Many of us may remember playing a game as a child, commonly referred to as Telephone, where everyone would sit in a circle with the sole responsibility of passing along a message to the next player. The goal of this game was to successfully pass the original message back to the first player without any changes to the original message. If your experiences were anything like mine, you would agree that the final message rarely made it back to the first player in the same state that it left in.  In some cases, the final message was so far from the original that it would induce laughter throughout the whole group. Although this game was supposed to provide laughter and enjoyment during our childhood, it was also a good teaching moment to reinforce the importance of detail and attention. This exercise is a simple demonstration of the importance of data integrity and communication and their reliance on each other.

Data Integrity in the Process Industry

In the human body, blood transports oxygen absorbed through your lungs to your body’s cells with assistance from your heart, while the kidneys are continuously filtering the same blood for impurities. In this example, three systems (heart, kidneys, lungs) are working together to ensure adequate maintenance of the body. Much like the human body, the process industry is complex and requires multiple systems working together simultaneously to achieve their goal. If any system were to break, it would result in reduced performance and possibly, eventual failure. These data integrity challenges are very similar, regardless of whether tasked with designing a new site or maintaining existing facilities.

Chemical plants, refineries, and other process facilities maintain multiple documents that are required to operate the facility safely. Any challenges with maintaining these documents and work processes could result in process upsets, injuries, downtime, production loss, environmental releases, lost revenue, increased overhead, and many more negative outcomes. Below are just a small example of the critical documents that must be updated to reflect actual engineering design:

  • P&IDs
  • Electrical One-Lines
  • Cause & Effects
  • Instrument Index
  • Loop Diagrams
  • Control Narratives
  • Wiring Diagrams
  • Process Control Logic

There are many processes and workflows that may trigger required changes to the above documentation, such as PHAs, LOPAs, HAZOPs, MOCs, SRSs, Maintenance Events, and Action Items, to name a few. Each of these processes requires specific personnel from multiple groups to complete. As the example earlier in this blog pointed out, it can be a challenge to communicate efficiently and effectively in a small group, much less across multiple groups and organizations. Data integrity can easily be compromised by having multiple processes and multiple workgroups involved in decisions affecting multiple documents.

Considerations

When starting a new project or becoming involved in a new process, it is essential to consider how the requested changes will affect other workgroups and their respective documentation. Will your change impact others? Could understanding how your changes affect other data and workgroups minimize rework or prevent incidents? Could seeing the full picture help you to make better decisions for your work process? Below are some approaches to consider to improve data integrity and communication in your workspace:

  • Understand how changes you make may affect others
  • Identify duplicated data that exist across multiple databases or files
  • Look for ways to consolidate data and processes
  • Create Procedures to audit required changes
  • Designate Systems of Record (SOR) for all data
  • Implement roles to follow guidelines and maintain integrity and communication

  

Digital Transformation of Control and Safety Systems

Digital Transformation of Control and Safety Systems

The Digital Transformation of Control and Safety Systems has come a long way. They used to be simple yet were unreliable, not very robust, or died from neglect.  In the past, the term Safety System generally wasn’t used very much, rather you would see terms such as ESD and Interlock. The technologies used in the past were often process connected switches and relays that were difficult to monitor, troubleshoot, and maintain. Field instrumentation used 3-15 psig air or 4-20 ma signals. Things have changed since then. They have become more effective yet with that, a lot more complicated as well. 

As control systems, safety systems, and field instrumentation were digitized, the amount of data a user has to specify and manage grew by orders of magnitude. Things that were defined by hardware design, that were generally unchangeable after components were specified, became functions of software and user configuration data which could be changed with relatively little effort.  This caused the management of changes, software revisions, and configuration data to become a major part of ownership. 

The problem is that the market is dominated by proprietary systems that apply only to manufacturers line of products, so the user is required to have multiple software packages to support the wide variety of instrumentation, control systems, safety systems and maintenance management support systems that exist in any of today’s process plants. Here’s an overview of the evolution and landscape of these systems and the relative chaos that still exists. 

What are industry leaders like Shell doing to digitally transform their process safety lifecycle?

Field Instrumentation 

Back in the early 1980’s an operating company was involved in the first round of process control system upgrades to the first generation of DCS that were available. There were projects for field testing prototypes of a new digital transmitter major manufacturers. The transmitters that were being tested were similar to the 4-20 ma transmitters, but the digital circuity that replaced the old analog circuitry was programmed by a bulky handheld communicator. It took about 10 parameters to set up the transmitter. 

Now you can’t buy anything other than a digital transmitter, and instead of a few parameters available, there are dozens. Digital valve controllers have also become common and the number of parameters available number in the hundreds. Device types with digital operation have also exploded, including adoption of wireless and IOT devices. The functionality and reliability of these devices far exceed those of their prior analog circuit-based relatives. The only cost is that someone has to manage all of that data. A binder full of instrument data sheets just doesn’t work anymore. 

Field Instrumentation Management Systems 

When digital field instrumentation was first introduced the only means of managing configuration data for each device was through a handheld communications device, and the configuration data resided only on the device. This was simple enough when the parameters mirrored the settings on non-smart devices. However, these devices got more sophisticated and the variety of devices available grew. Management of their configuration data became more demanding and the need for tools for management of that data became fairly obvious.

The market responded with a variety of Asset Management applications and extended functionality from basic configuration date management to include calibration and testing records and device performance monitoring.  The systems were great, but there was major problem in that each manufacturer had packages that were proprietary to their lines of instrumentation.

There have been attempts to standardize instrument Asset Management, such as the efforts of the FTD group, but to date most users have gravitated towards specific manufacturer software based upon their Enterprise or Site standard suppliers. This leaves a lot of holes when devices from other suppliers are used, especially niche devices or exceptionally complex instruments, such as analyzers are involved. Most users end up with one package for the bulk of their instrumentation and then a mix of other packages to address the outliers, or no management system for some devices. Unfortunately, manufacturers aren’t really interested in one standard. 

Communications Systems 

As digital instrumentation developed, the data available was still constrained by a single process variable transmitted over the traditional 4-20 ma circuit. The led to development of digital communications methods that would transmit considerable device operation and health data over top of, or in replacement of, the 4-20 ma PV signal. The first of these was the HART protocol developed by one manufacturer but released to the industry as an open protocol. However, other manufacturers developed their own protocols that were incompatible with HART. As with Asset Management software, the market is divided up into competing proprietary offerings and a User has to make choices on what to use.

In the 1990’s, in an attempt to standardize something, the Fieldbus Foundation was established to define interoperable protocols. Maneuvering for competitive advantage led some companies to establish their own consortiums such as Profibus and World FIP that used their own protocols. The field instrument communications world has settled on a few competing and incompatible systems. Today a user basically has to make a choice between HART, Fieldbus, Profibus and DeviceNet, and then use the appropriate, often proprietary, support software and hardware. 

Distributed Control Systems and PLC’s 

1980 is back when programming devices required customized hardware. The PLC had its own suitcase sized computer that could only be used for the PLC. Again, data was reasonably manageable, but a crude by today’s standards. 

Over the years the power of the modules has evolved from the original designs that could handle 8 functions, period, to modules that can operate all or most of a process plant. The industry came up with a new term, ICSS for Integrated. Control and Safety System to describe DCS’s that had been expanded to include PLC functions as well as Safety Instrumented Systems. 

The data involved in these systems has likewise exploded as has the tools and procedures for managing that data.  The manufacturers of the DCS, PLC and SIS systems have entire sub-businesses devoted to the management of the data associated with their systems. 

As with other systems software the available applications are usually proprietary to specific manufacturers. Packages that started out as simpler (relatively speaking) configuration management software were extended to include additional functions such as alarm management, loop turning and optimization, and varying degrees of integration with field device Asset Management Systems. 

Safety Instrumented Systems 

Safety Instrumented System logic solvers were introduced in the earl 1980’s, first as rather expensive and difficult to own stand-alone systems. The SIS’s evolved and became more economic. While there still are stand along SIS available, some of the DCS manufacturers have moved to offering Integrated Control and Safety Systems (ICSS) in which SIS hardware and software for Basic Process Control (BPCS), SIS and higher-level functions such as Historians and Advanced Control applications are offered within integrated product lines.

As with all of the other aspects of support software, the packages available for configuration and data management for SIS hardware and software is proprietary to the SIS manufacturers. 

Operation and Maintenance Systems 

The generalized Operation and Maintenance Systems that most organizations use to manage their maintenance organizations exist and have been well developed for what they do. Typically, these packages are focused on management of work orders, labor and warehouse inventory management and aren’t at all suitable for management of control and safety systems.

Most of the currently available packages started out as offerings by smaller companies but have gotten sucked up into large corporations that have focused on extending of what were plant level applications into full Enterprise Management Systems that keep the accountants and bean counters happy, but make life miserable for the line operations, maintenance and engineering personnel. I recall attending an advanced control conference in which Tom Peters (In Search of Excellence) was the keynote speaker. He had a sub-text in his presentation that he hated EMS, especially SAP. His mantra was “SAP is for saps”, which was received by much head nodding in the audience of practicing engineers. 

Some of the Operations and Maintenance Systems have attempted to add bolt on functionality, but in my view, they are all failures. As described above, the management tools for control and safety systems are fragmented and proprietary and attempting to integrate them into generalized Operation and Maintenance Systems just doesn’t work. These systems are best left to the money guys who don’t really care about control and safety systems (except when they don’t work). 

Process Safety System Data and Documentation 

The support and management software for SIS’s address only the nuts and bolts about programming and maintaining SIS hardware. They have no, or highly limited functionality for managing the overall Safety Life Cycle from initial hazard identification through testing and maintaining of protective functions such as SIFs and other Independent Protection Layers (IPLs). Some of the Operation and Maintenance System suppliers have attempted to bolt on some version of Process Safety Management functionality, but I have yet to see one that was any good. In the last decade a few engineering organizations have released various versions of software that integrate the overall Safety Lifecycle phases. The approach and quality of these packages varies. I’m biased and think that Mangan Software Solutions’ SLM package is the best of the available selections. However, The ARC Advisory Group also agrees.

Digital Transformation of Control and Safety Systems

Click Here To Learn More

Conclusions  

The Digital Transformation of Control and Safety Systems has resulted in far more powerful and reliable systems than their analog and discrete component predecessors. However, the software required to support and manage these systems is balkanized mixed of separate, proprietary and incompatible software packages, each of which has a narrow scope of functionality. A typical plant user is forced to support multiple packages based upon the control and safety systems that are installed in their facilities. The selection of those systems needs to consider the support requirements for those systems, and once selected it is extremely difficult to consider alternatives as it usually requires a complete set of parallel support software which will carry its own set of plant support requirements. Typically, a facility will require a variety of applications which include: 

  • Field device support software and handheld communicators
  • Field device Asset Management Software, typically multiple packages if the User uses multiple suppliers
  • DCS/BPCS/PLC/ICSS support software for configuration, alarm management and optimization functions as used by the Site. If a Site has multiple suppliers, then multiple parallel packages are required
  • SIS support software for configuration and software management if not integrated with and ICSS software package. If a Site has multiple suppliers, then multiple parallel packages are required
  • Operations and Maintenance Management packages – selected by others and not within the control of personnel responsible for Process Control and Safety Systems.
  • Safety Lifecycle Management Software – preferably an integrated package that includes Hazard Analysis, Safety Function and System design and Safety Function testing, event data collection and performance analysis and management functions.

So choose wisely.  

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software and has performed numerous Functional Safety Assessments for both existing and new SISs. 

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee for Instrumentation and Control Systems. 

Moving Existing Data into the SLM® solution

Moving Existing Data into the SLM® solution

When considering whether to move Safety Lifecycle Management into the SLM® solution, the question “What do I do with my existing data?” arises. This was a significant concern when the SLM® software was being developed and has thus been addressed. SLM® software has an Adapter Module that provides the tools for importing data into the SLM® system and exporting data to external systems. Import Adapters use an intermediate .csv file, typically created in Excel, to organize data so that the SLM® software can read the data, create the correct object hierarchy, and then import the data into SLM® software data fields. The software import process is illustrated in the figure below

 

import_image
During planning for an SLM® software installation, the user and Mangan Software Solution staff will review the data that is available for import and identify what Adapters are needed to support data import. During this review, the linkages between Modules and data objects should be reviewed to ensure that after import objects such as HAZOP Scenarios, LOPA’s, IPL Assets, and Devices are properly linked. If large amounts of data from applications for which an Adapter has not yet been created, it usually is advisable to have the MSS team create a suitable Adapter instead of attempting to use a Generic Import Adapter.

Once the user’s data has been exported to the intermediate .csv file a data quality review and clean up step is advisable. Depending upon the data source, there are likely to be many internal inconsistencies that are much easier to correct prior to import. These may be things as simple as spelling errors, completely wrong data, or even inconsistent data stored in the source application. I recall a colleague noting after a mass import from a legacy database to a Smart Plant Instrument database – “I didn’t realize how many ways there were to incorrectly spell Fisher.”

Once the data has been imported, correcting such things can be very tedious unless you are able to get into the database itself. For most users, errors such as this get corrected one object at a time. However, editing these types of problems out of the .csv file is pretty quick and simple as compared to post import clean up.

To Import the data, the User goes to the Adapter Module and choses the desired Import Adapter and identifies the .csv file that contains the data. The SLM® solution does the rest.
It should also be noted that SLM® software is capable of exporting data too. The User selects data types to export along with the scope (e.g. a Site or Unit). The exported data is in the form of a .csv file. This can be used to import data into a 3rd party application, or to use a data template to import more data.

Rick Stanley has over 40 years’ experience in Process Control Systems and Process Safety Systems with 32 years spent at ARCO and BP in execution of major projects, corporate standards and plant operation and maintenance. Since retiring from BP in 2011, Rick has consulted with Mangan Software Solutions (MSS) on the development and use of MSS’s SLM Safety Lifecycle Management software and has performed numerous Functional Safety Assessments for both existing and new SISs.

Rick has a BS in Chemical Engineering from the University of California, Santa Barbara and is a registered Professional Control Systems Engineer in California and Colorado. Rick has served as a member and chairman of both the API Subcommittee for Pressure Relieving Systems and the API Subcommittee on Instrumentation and Control Systems

 

Mangan Software Solutions – SLM Overview

The # 1 selling Safety Lifecycle Managment solution. Our software is a cloud-based platform. Adopt our SLM® solution and enjoy benefits such as:

  • Eliminate the Silos.
  • Centralize your Data.
  • Take Control.
  • Intelligent Systems
  • Exceptional Outcomes
Brochure Blue

Please let us know where to send the document..

1 + 3 =

Mangan Software Solutions – Software Modules

Our SLM® software is a comprehensive set of interconnected application modules that cover the entire Process Safety and Functional Safety Lifecycle. From HAZOP and LOPA Studies to SIS Design, Operations and Maintenance. The SLM® Software Suite is comprised of 10 Software modules that encompass the entire IEC 61511/ISA4 Safety Lifecycle. The SLM® solution has all the tools you need to successfully manage the Safety Lifecycle.
Module Brochure

Please let us know where to send the document..

2 + 5 =

Mangan Software Solutions – Safety Lifecycle Manager (SLM®)

The Safety Lifecycle Manager software application, SLM, is a powerful application that allows an Enterprise, Manufacturing Site or Engineering Project to manage and fully document Process Safety information in one location. The application provides basic Safety Life Cycle functions as well as providing an extensive set of additional functionalities that a particular user may choose to use, or not.

Please let us know where to send the document..

15 + 15 =

Digitalizing Safety Information into Intelligence

Digitalizing Safety Information into Intelligence

What is Digital Transformation and how can the SLM® system help?
Digital Transformation is the process of converting non-digital or manual information into a digital (i.e. computer-readable) format. For an organization, a phase of digital transformation is a great opportunity for organizations to take a step back and evaluate everything they do, from the basic operations to complex workflows.

<p?
Digital transformation is a time to understand the potential opportunity involved in a technology investment. It’s an ideal time to ask questions, such as ‘Can we change our processes to allow for great efficiencies that potentially allow for better decision making and cost savings.’ A perfect example could be trending data to identify optimum test intervals based on degradation over time. This could provide cost savings in fewer required tests.

Advantages of Digital Transformation

The key tactical benefit of digital transformation is to improve the efficiency of core business processes. In the image below, you can see the efficiencies provided by digital data broken down into three key module areas:

SLM benefits

As you can clearly see, the opportunities provided by digitalization are vast and for this reason Digitalization Demands an Integrated Safety Lifecycle Management System A lot of tools in the market today are single purpose and do not share or exchange data in a way suited to a Safety Lifecycle Management system

Common problems

A lot of organizations we speak with are struggling with lagging indicators and poor reporting systems. This degradation has only gotten worse over time, and this points to a lack of clear and accurate data, overly complex workflows and restrictions brought about by company culture.

At any given point in time organizations are unable to identify the current health of their plant and assets. Bad actors are exceedingly difficult to identify and experience is diminishing with retirements and a reduction in the numbers of subject matter experts.

Digital Transformation Solution

Process Safety and Functional Safety is more than just hardware, software, testing and metrics. Taking a holistic approach and instilling a culture of safety requires a complete end-to-end system that can manage from Initial Hazard Analysis to the final Operations & Maintenance. The SLM® system is the only enterprise platform proven to bring together all aspects of the Safety Lifecycle through digital transformation.

Let SLM® be your digital twin

Let SLM® be your digital twin

Digital twins are powerful virtual representations to drive innovation and performance. Imagine it as a digital replica of your most talented product technicians with the most advanced monitoring, analytical, and predictive capabilities at their fingertips. It is estimated that companies who invest in digital twin technology will see a 30 percent improvement in cycle times of critical processes.

A digital twin captures a virtual model of an organization and helps accelerate strategy. This could be in products, operations, services, and can even help drive the innovation of new business. The model can identify elements that are hindering or enabling strategy execution and suggests specific recommendations based on embedded pattern recognition. Digital twin technology is used to collect more dots and connect them faster, so you can drive to better solutions with more confidence.

 

digital_twin_cloud

Today’s organizations are complex, evolving systems, built on the collective ambitions and talents of real people operating in a dynamic culture. The world is increasingly defined by data and machine learning, however, there is no simple way to measure human motivation or clear-cut formula for building an effective future.

In a nutshell a digital twin is a tool that can be used to analyze your business to identify potential concerns in any area, and show you how those issues link together. Armed with that information, you can build solutions immediately and overcome the most important obstacles – all before they happen. Get in touch and let our Safety LIfecycle Management tools manage your digital needs.

Digitalization Demands

Digitalization Demands

Part 2 – Hazard Identification and Allocation of Safety Functions

Digitalization Demands An Integrated Safety Lifecycle Management System (part 1) of this blog series, the general organization of the Safety Lifecycle, as described in IEC 61511, was discussed.  Part 1 highlights the difficulties the application of tools typically used in the day to day operations have with effectively administrating the Safety Lifecycle.

In Part 2 of this blog series, the discussion moves on to a more detailed view of Safety Lifecycle Management for the Requirements Identification phases of the Safety Lifecycle as illustrated in the modified IEC 6111 Figure 1 below.

Safety_Life_Framework

Hazard Identification and Allocation of Safety Functions

While IEC 61511 does not specify procedures, it does require that a hazard and risk assessment be performed and that protective functions that prevent the hazard be identified and allocated as appropriate to Safety Instrumented Functions.

In practice this is usually accomplished by performing a hazard assessment using HAZOP or similar techniques. Scenarios that have a high consequence are then further evaluated using LOPA or similar techniques.

The LOPA studies identify protective functions or design elements that prevent the consequences of the scenario from occurring. These functions and design elements are generally designated as Independent Protection Layers (IPLs) and may take the form of instrumented functions such as Alarms, BPCS and Interlock functions, Physical design elements or Safety Instrumented Functions.

The Traditional Way

The market has a number of Process Hazards Assessment (PHA) software available. However, these software tools are all focused on performing PHAs or associated studies such as LOPAs and are almost always stand-alone tools. The capabilities have generally met the needs of Process Safety Engineers yet have had their limitations. Some of the available packages have attempted to extend their functionality to other phases of the Safety Lifecycle, yet they still tend to fall short of being a complete Safety Lifecycle Management function due to their original PHA focus.

 

Problems

 

Stand Alone

The biggest issues with stand-alone PHA and LOPA software packages is the fact that they are “stand alone”. They are self-contained and some of them have such draconian licensing restrictions, that sharing of PHA and LOPA data is extremely limited and often limited to transfer of paper copies of reports. Licensing costs are extremely high which results in organizations restricting the number of licenses that are available. Usually, the PHA and LOPA data can only be accessed from a very limited number of computers (often only one or two within an organization), even in view mode.

Difficult to link PHA and LOPA

A second major issue is that it is difficult, if not impossible to link PHA and LOPA data for a series of PHA and LOPA studies done on the same process. The typical life cycle of PHA and LOPA studies is that initial studies are done during initial design of a process plant, and then a revalidation of those studies is done every 5 years. Within the 5-year cycle, multiple sub-studies may be done if there are any significant revisions done to the process.

HAZOP of Record

Larger projects may use the same HAZOP tools as used for the HAZOP of Record, but they are usually considered in complete isolation from the HAZOP of Record. Often new nodes are defined that are numbered quite differently than the HAZOP of Record and may not contain the same equipment. As many of these studies are done at an engineering contractor’s office, the same licenses may also not be used. Many smaller modifications may be made that do not use the formal PHA procedure but use perceived simpler methods such as checklists and what-if analysis. The simpler methods are usually resorted because of the extreme licensing limitations noted above.

hazop-lopa

The Independence Mess of Traditional HAZOP Tools

Over a typical 5-year HAZOP cycle, a large number of additional hazard assessments are done, each independent, and often inconsistent with the HAZOP of Record. Project based HAZOPs may be performed on sections of the process with completely different node identifications and node scopes. In effect, there is no current HAZOP of Record as it is partially superseded by these incremental HAZOPs and other hazard assessment. At the time of the 5-year revalidation, integration of all of these independent studies with the prior HAZOP of Record is a major undertaking.

As these applications are stand-alone applications, any associations of Safeguards and IPLs identified during Hazard Analysis with the real Plant Assets used to implement those items must be done externally, if it is done at all. This results in a layer of documentation that is often difficult to manage, of limited availability and not very useful to the operations and maintenance personnel that really need the data

Top 3 Issues with traditional Hazard Identification methods:

  • Licensing restrictions

Licensing restrictions often severely limit access to the data. Furthermore, personnel that need to understand the reasons for various IPLs do not have access to the necessary data.

  • No Clearly Defined Data

IPLs and other Safeguards are usually identified in general terms and often do no clearly define what Plant Assets such as Alarms, BPCS Functions, Interlock Functions and Safety Instrumented Functions correspond to the identified IPLs. This is even more of a gap when a User needs to link an existing Plant Asset back to a specific IPL and PHA scenario.

  • Separate HAZOP and LOPA files

There is no way to integrate HAZOP and LOPAs of Record with incremental HAZOPs, LOPAs, and MOC hazard assessments. This leads to multiple, inconsistent versions of HAZOP and LOPA which then need to be manually resolved, and often are not integrated with the HAZOPs and LOPAs of Record.

5 Major Benefits of Digitalization

An Integrated Safety Lifecycle System, provides functionality that addresses the shortcomings of a system that is based upon single purpose HAZOP and LOPA software. Among the functions that are not provided by traditional PHA and LOPA software are:

  • The HAZOP and LOPA modules in the software provide functionality to link HAZOPs and LOPAs that are performed as part of Management of Change activities back to the current HAZOP of Record. This assures that Management of Change PHA’s are consistent with the HAZOP of Record in that the same Nodes, Equipment and Scenarios are copied to the MOC PHA’s and become the basis for the hazard assessments.

  • MOC hazard assessment data may be easily integrated back into the HAZOP of Record when the changes are actually integrated. The original versions are kept as archive records, but the HAZOP of Record may be kept up to date and reflect the actual state of the process, and not what it was several years ago. As the incremental HAZOPs and LOPAs are integrated back into the HAZOP and LOPAs of Record as changes are implemented, there is no large task of sorting out all of the studies done since the last HAZOP of Record into a new HAZOP of Record.

  • Integrated Safety Lifecycle Management applications have global access. Licensing restrictions do not limit access to HAZOP and LOPA data to a few licensed computers. However the Integrated Safety Lifecycle Management applications do contain security functions that allow restriction of data access to authorized Users.

  • IPLs identified by LOPAs are linked directly to the HAZOP scenarios and may also be linked directly to the Plant Assets what implement the IPLs. This means that the Process Safety basis for all IPLs is immediately available to all authorized personnel.

  • Checklists may be associated with IPLs to provide validation of the IPLs ability to mitigate the hazard and its independence from causes and other IPLs. Checklists are available at both the IPL functional level (when an IPL is identified by a LOPA) and a design level (when the Plant Assets that perform the IPLs functions are designed).
Hazop-of-record
linking-ipls

Conclusion

The traditional tools used for Process Hazards Analysis severely limit access to Process Hazards data and do not support other activities required to manage the Safety Lifecycle. Process Hazards data is fragmented and requires major efforts to keep the data current.

In an integrated Safety Lifecycle Management application, HAZOP and LOPA data is readily available to any authorized User. This includes the current HAZOP and LOPAs of Record as well as a full history of prior risk assessment studies. The linking of LOPA identified IPLs to real Plant Assets allow for access of the risk assessment basis for all Plant Assets that perform IPL functions from the Plant Asset data. So an operations or maintenance user can clearly understand why various IPL functions exist and the risks that they are mitigating.