All Search Results matching “chuck miller”

I received a great question today about the safety integrity level (SIL) of a distributed control system (DCS). In this case, the question was specific to the DeltaV system:

Can you please advise if the Emerson DeltaV DCS has a SIL rating i.e. '0' or '1'? I understand that the DeltaV SIS has a SIL rating of '3'.

I turned to safety expert, Chuck Miller, whom you may recall from earlier process safety-related posts. I thought Chuck's response was great and asked if I could share it in a blog post for others who may have similar questions. Chuck agreed and here was his response:

Any basic process control system or BPCS (DeltaV DCS included) is a SIL 0 technology.

Applying an uncertified technology to a safety application with a Risk Reduction Factor, as defined in IEC 61508, of 10 or above is not supported by the safety standards or mainstream philosophies. The lack of diagnostic coverage is the main factor that precludes most users from considering BPCS technology even to most low-level safety applications.

Companies who do choose to take this approach employ redundancy and software configuration to create "comparative diagnostic capabilities." This often drives the cost well beyond purpose-designed safety technology. Even then, the Safe Failure Fraction may not be great enough to provide adequate risk mitigation without very frequent manual testing.

This in turn drives the lifecycle cost of the system up, up, and up. While the front-end costs (CapEx) may look good, the operations and maintenance (OpEx) cost cannot be supported in most cases.

This also creates implications on the Layers of Protection Analysis (LOPA) in more ways than can be described in this e-mail.

I hope this helps others with their IEC 61511 / ISA-84 safety lifecycle planning efforts.

MP3 | iTunes

We discussed the energy efficiency and other opportunities with fired heaters in past posts. I caught wind of a presentation that Emerson's safety specialist, Chuck Miller will be giving at the upcoming March 21-25 AIChE Spring National Meeting and Global Congress on Process Safety in San Antonio, Texas. You may recall Chuck from numerous process safety-related posts.

He'll be presenting, ICSS Systems Offer Advances in Fired Heater Operations, Safety, and Regulatory Compliance on Tuesday, March 23 at 9am. In his abstract, Chuck raises the questions:

Can the instrumentation, control, and protective systems for fired heaters as defined by the prescriptive API Recommended Practice 556 be reconciled with ANSI/ISA 84 (IEC 61511) by implementing an Integrated Control and Safety System? What cost savings can be identified and measured from both the CAPEX and OPEX viewpoint when applying advanced technology to adhere to these divergent standards?

If traditional approaches to compliance with process safety standards are driving costs up and yielding diminishing returns, which control architecture can provide cost savings while enabling the unit to be started-up, operated, and shut down safely?

Knowing that this conference is still a ways away, I asked Chuck if he had a "beta" version of his paper that he could share with me. Being the true professional and nice guy that he is, he forwarded me a copy of his work-in-process.

Process manufacturers have a common need to improve both safe operations and uptime through the avoidance of spurious trips in fired heaters and other fired units. Chuck notes that the professional associations have collaborated and developed a number of good engineering practices related to industrial flame management systems, such as NFPA 85, NFPA 86, API RP 556, ASME CSD-1, FM 7605, and API RP 14C. Each was developed from different perspectives from prescriptive design, to expected performance, to a practical experience viewpoint.

A prescriptive approach describes what process manufacturers should and should not do. A performance-based approach like the IEC 61511 global safety standard provides descriptions of methods without prescribing specific methods or suggestions to enact.

Chuck highlights the similarities and differences with respect to API Recommended Practice 556 (API RP 556), ANSI/ISA 84, and ISA-TR84.00.05 (ISA TR-5, Guidance on the Identification of Safety Instrumented Functions in Burner Management Systems). API RP 556 can be seen as prescriptive because it offers practical suggestions where S84/IEC 61511 does not offer specific recommendations.

He believes that API 556 will provide an excellent design specification for the process heater, primary measuring and actuating instruments, controls, alarms, and the associated protective systems. It is also sufficient to provide a starting point for an industrial flame management risk evaluation process and the basis for a Safety Requirements Specification (SRS).

API RP 556 also contains many references to requirements of ANSI/ISA 84 such as HAZOP requirements, nuisance trip avoidance, diagnostics & on-line testing, separation of control and safety functions, etc.

ISA TR-5 is currently in the process of development to provide guidance on how to Identify and classify safety instrumented functions (SIFs) within typical Burner Management System (BMS) for all operating modes of fired equipment including pre-firing, light-off, shutdown, and normal operation. Like API RP 556, the technical report states that due to the unique design criteria of every furnace, each heater/boiler will require that a HAZOP and layer of protection analysis (LOPA) be performed.

Chuck offers other similarities and differences as process safety professionals pick their way through the standards to manage the safety lifecycle of their operations. If you are involved in process safety and plan to attend the AIChE Spring meeting, you may want to include Chuck's presentation on your agenda.

MP3 | iTunes

Process automation systems and safety instrumented systems (SIS) have been changing with the rapid pace of technology change. An ARC Advisory Group whitepaper, Business Issues Driving Safety System Integration, outlined some of the various ways automation suppliers have been integrating these systems for process manufacturers. They described three integration levels: interfaced, integrated, and common.

Emerson's Chuck Miller has written a whitepaper, Realizing the Capital and Operational Benefits of a ICSS System. It explores how the technologies and integrated approach of the basic process control system (BPCS) and SIS, combined with work processes, can improve capital expenditure (CapEx) and operational expenditure (OpEx) performance.

In the whitepaper, Chuck describes the integrated control and safety system (ICSS) that is built upon redundant Ethernet control networks, distributed and scalable process controllers, distributed and scalable safety controllers, human machine interfaces (HMIs), engineering workstations, and application servers. He describes how CapEx savings can be achieved if the engineering tools are common when configuring the process and safety controllers and the HMI is common in communicating with the controllers. Functions such as alarm handling, time synchronization, user security, and device health monitoring are also shared between systems.

Another example on the CapEx side is compliance with the IEC 61511 international safety standard. Device audit trails, calibration histories, process and safety configuration audit trails, process and event histories all contribute to the detailed documentation and change management required for a process manufacturer's safety management program.

For the safety instrumented functions (SIFs) managed by the safety controllers (or logic solvers in safety parlance), Chuck notes the importance of diagnostics from the sensors and final control elements. From a sensor standpoint, HART device alerts can be sent to operators and maintenance personnel as an early warning of problems with the device or surrounding process (see my earlier HART diagnostics post). For final control elements, non-disruptive actuator partial stroke testing can be performed to make sure the safety valves do not become stuck from long periods of inactivity.

These predictive tests help on the OpEx side of the equation. Through a continuous process of detection and notification, which in turn feeds the work process associated with rapid correction, spurious trips and on-demand failures can be avoided. Chuck uses the analogy of an automobile service technician. The process begins by performing diagnostic tests. With the results in hand, the person or people with the right set of skills can be assigned to resolve the situation quickly.

Similarly, process manufacturers can organize to take advantage of the diagnostics within both the process automation and safety instrumented systems to avoid unplanned shutdowns and respond more quickly to abnormal situations.

Give the whitepaper a read for many more ways both the CapEx side and OpEx side of your plant budget are impacted by the integration of these systems. Also, look for and join the discussions on SIS integration in the Process Automation Usability Project site, on the DeltaV SIS LinkedIn group, and from the @DeltaVSIS Twitter account.

MP3 | iTunes

I just read a great article, How to Achieve Competent Workforce for Safety, in the May edition of Automation World magazine. Written by editor-in-chief, Gary Mintchell (also of Feed Forward blog, Automation Gear blog and Twitter fame), this article looks at the people side of ensuring safety. It examines some of the existing regulations and standards around competency, views from both process and discrete automation suppliers and views from safety-focused organizations.

Emerson's Chuck Miller is quoted in the article and has long articulated the role of people in effective safety programs. The article notes that both the U.S. Occupational Health and Safety Administration (OSHA) and the global IEC organizations, through the IEC 61508 and IEC 61511 standards, "state that people involved with the safety lifecycle must be competent in the area in which they deal."

The safety lifecycle covers a broad spectrum of responsibilities, and Chuck notes, "even people we consider to be safety experts may not be expert in all areas of the lifecycle. For example, a reliability engineer may know a lot about the equipment, but may not be able to competently go into the plant and effectively calibrate and maintain that equipment."

The article describes the top-down support and commitment to build a strong safety culture with competent people across all phases of the safety lifecycle. To help in this competency requirement, Emerson developed a safety management system built according to IEC 61511 and had its processes audited and certified by TÜV in 2006.

A safety management system should clearly define the organization, competency policy, safety audit procedures and the safety lifecycle activities. Good guidelines exist to help. The United Kingdom's Health and Safety Executive (HSE) in 2007 published, Managing competence for safety-related system, Part 1: Key Guidance. It includes 16 principles across the plan, design, operate and audit/review phases of the safety lifecycle.

Emerson's safety management system defines clear policies and processes, roles, role competency requirements and the training/experience required to achieve the identified skills for each role. Examples of roles in the project phase are SIS consultants, SIS project leads, SIS software engineering personnel, SIS hardware engineering personnel, and SIS field equipment engineering personnel. In addition to an employee's work experience, a key part of Emerson's safety competency requirements program is the Certified Functional Safety Expert (CFSE) certification. I did a quick search on the list of CFSE/CFSP certified safety professionals and counted more than 60 global Emerson folks that are now certified.

I caught up with Mike Boudreaux to find other ways that Emerson helps end users to address their SIS competency requirements. Thorough knowledge of the entire safety system is important. Competency requirements should apply to all of the components that make up the SIS, from the sensor to the final element and everything in between. Here are some ways that Emerson is helping:

• SIS Seminars that include a safety overview, discussion of SIS applications and a discussion of the safety lifecycle
• PlantWeb University SIS courses that are free online courses that provide a good overview of IEC 61508/61511 safety lifecycle concepts.
• Process Safety Training Courses that cover the Analysis and Realization phases of the IEC 61511 safety lifecycle
• Training courses on the SIS components that Emerson supplies, including the sensors, logic solvers, final elements, and safety lifecycle tools.
• Emerson has supported the development of the CSFE/CSFP programs through participation on the CFSE Governance Board. The governance board is an independent board that administers certification tests for CFSE.

Mike also points out, "competency goes beyond knowledge of the concepts and technologies that are used to implement an SIS. Good design and implementation reduces the random and common cause hardware failures. It is in preventing the systematic failures where managing competency throughout the entire safety lifecycle becomes so important. For many end users, this means that developing competency management in the Operation phase is very critical."

Knowledge of the process application and the hazards involved is a must. IEC 61511 also calls out the need for "adequate management and leadership skills appropriate to their role in the safety lifecycle activities" as part of competency. This has a lot to do with the type of people that you employ and the company culture that you develop. It is not something that can be created overnight and it takes a long-term commitment to be successful.

Update: Welcome Feed Forward blog readers!

Automation World magazine's Wes Iverson recently had a nice article, The Great Safety Debate. He described the various approaches to safety instrumented systems (SIS) and their connections with basic process control systems (BPCS). The article highlights where the SIS suppliers products fall in the ARC Advisory Group's four categories of SIS: separate, interfaced, integrated and common.

Separate defines complete separation between the BPCS and SIS. Interfaced defines a connection via a gateway using OPC, MODBUS or other communications method to share information, particularly at operator displays. Integrated defines a closer connection perhaps sharing common engineering tools, operator displays, alarms, etc. Common defines a single box does both control and safety.

The article references ARC's viewpoint:

...integrated control/safety systems as one of its "top automation technologies and trends to watch in 2007."

Emerson's Chuck Miller, whom you may recall from earlier process safety-related posts, described DeltaV SIS as being part of the integrated category. He's quoted:

In the Emerson architecture, "our safety and control systems are completely segregated in all the ways that count," says Miller. "The operating systems are different. The hardware is different. The only thing we do share are engineering tools, and even those are password protected for all safety integrated functions," Miller points out. And while integrated DeltaV SIS and DeltaV systems are linked with a dedicated communications channel for information sharing, that link is one-way, he adds. "The SIS sends information out to the BPCS, and while the SIS can see information from the BPCS, that information does not alter the safety instrumented functions implemented in the SIS."

Chuck also added:

"You no longer have to map your safety system into your DCS via Modbus or OPC. You no longer have to run a separate bus for time synchronization to the different subsystems, and you no longer need a stand-alone sequence-of-event system," he explains. "All of those functional subsystems are built into our integrated BPCS/SIS environment."

The article did point offer critiques by suppliers of other suppliers' approaches. The SISs in the separate and interfaced categories point to issues like common mode failures, inadvertent changes in SIS and reliance on functional or logical separation instead of physical separation. The article references that some have called this FUD, as did a blog post from last year, which I confess caused me to LOL.

As the article noted:

Various integrated safety/control systems are on the market today that have met this requirement, say their vendors, as evidenced by certifications received from TÜV [hyperlink added], an independent international certification organization. And once a system is TÜV-certified as meeting international standards for use at a specific safety integrity level, or SIL, that should end any debate, these vendors contend.

If you're looking to address your organization's IEC 61511 safety lifecycle requirements, this article is worth a read to understand the various SIS approaches and critiques of these approaches.

Update: I received an email from DeltaV SIS Product Manager, Mike Boudreaux who notes that beyond the engineering tools, the operator station (HMI) software and asset management software (AMS Intelligent Device Manager) are also shared by both the DeltaV system and DeltaV SIS.

The ControlGlobal.com site has a great article on process safety, Leading the Way to Process Safety. Author Peter Montagna describes the importance of leadership:

With strong leadership, a process safety program can achieve many goals. It can satisfy shareholders and company management with improved productivity and profitability; satisfy the community with fewer incidents; and satisfy employees with a healthy and safe working environment.

I ran this by Emerson's Chuck Miller whom you may recall from earlier posts on process safety. He's been preaching the critical importance of competency in functional safety management.

When I forwarded the RSS feed of the ControlGlobal.com story his way and asked his thoughts, Chuck as usual had some good ones. He wholeheartedly agrees that leadership is an important component:

...safety culture and competency ... that is culture creation has to be a driven from the top down. The leadership must set the standards and evaluate the process of the program. Management relates to the implementation of the process.

Chuck adds that there is a distinction between management and leadership. He writes:

However, many do not separate management and leadership, but instead combine the two. I place this as the leading metric of success or failure of the process. Changing culture in a work environment requires that you have the right people in place. They are hard to find but they are out there. To be effective it takes someone from the outside (of the work group) with the right credentials to drive the mission--no relationships or baggage to complicate the change agent with compromises.

Peter expressed a point in the article, "Then the process safety specialist leader has to form a team and help it create a compelling vision..." Chuck took a different view. He writes:

I put this responsibility on leadership (visa vie our Functional Safety Management Board) whose visionary commitment sets the goal and strategies to get there. For me it takes leadership PLUS a commitment from all levels of the organization--these implementers are the safety specialists and they drive the commitment.

For your process safety efforts, what are your experiences?

In one of those hallway conversations, Chuck Miller reminded me of a workshop at last year's Emerson Exchange. Chuck, well known for his safety instrumented system and safety compliance expertise, co-presented with a process manufacturer on the topic of cyber security in the control domain.

Automation systems have gone through quite a change from the '70s and '80s to our current decade. The architecture changed from proprietary data highways separated by gateways from operation stations, and separated from the enterprise local area network by another gateway--if they were connected at all. Using the ISA-95 (S95) model to describe the various levels of the architecture, the automation systems evolved where Ethernet/IP addressing is used between levels one and two, and between levels two and three. This move from proprietary technologies to commercially available technologies means that the issues with cyber-security must be considered and addressed.

The presenters defined risk as likelihood multiplied by consequence. Likelihood was defined as threat, vulnerability and target attractiveness multiplied together.

The process manufacturer described their risk assessment/reduction process. It included a risk assessment phase, risk reduction workshop phase, development of a risk reduction plan, and implementing that plan. Two key tenets of this process were that only the site personnel had the knowledge to assess the risks to their plants and their systems and that each site would use a risk assessment tool to develop a site risk profile. ISA-SP99 can help in the elements involved in this risk assessment.

Security levels were assigned based upon the consequences of a successful attack. Considerations included the level of hazard associated with the process or product, the location of the plant, and applicable federal critical infrastructure processes. The last consideration impacts the target attractiveness part of the risk equation.

They discussed the areas of the automation system that need to be addressed including the control of network access, user access and physical access. A key point is multiple layers of protection must be considered. Their analogy was a medieval castle protected by a moat, then by a drawbridge, then by a portcullis, then by murder holes, then by the outer walls and finally by the keep. Not all these layers of protection made castles impenetrable, but certainly extremely difficult to "hack into".

An automation system has points of entry that must be addressed by the security plan. These include the connection to the plant network or other external networks, modems, CDs, floppies, USB devices, equipment on the level-one control network between the controllers and PCs and underneath from the I/O subsystems.

One example, the control network, should require that no devices other than the controllers and PCs running operator, engineering, and applications be permitted to connect. Also, controller firewalls can be added between the PCs and controllers. These function to protect the controllers that are installed on the secure side of the firewall against message flooding and denial of service attacks. This firewall is in addition to the router/firewall above the PCs between the automation system and level 3 applications.

In the case of this process manufacturer, this router/firewall was managed by the operations organization. They created a DMZ above the automation system, which contained an anti-virus server, data server, and historian server. Above these was another router/firewall, managed by the IT organization, which connected to the plant local area network.

The presenters also discussed anti-virus strategies, security bulletins, and disaster planning. They summed up the presentation with elements that should be in the plan. These include:

• Assess the risks
• Define the critical systems
• Mitigate for (at least) the high cyber security risks
• Test the plan on a regular basis
• Train the users in the plan
• Get stakeholder signoff

This whole security risk assessment process is not easy, but like process manufacturers' safety risk assessments, is critical. For other automation system cyber security considerations, take a look at best practices in cyber security that is written around Emerson's DeltaV system.

Emerson's Chuck Miller is one passionately guy when it comes to process safety and the international safety standards, IEC 61508 and IEC 61511. He is on a mission to put the focus of functional safety management where he believes it belongs--on the competency of safety professionals involved in the safety lifecycle.

Chuck noted a panel discussion he sat in on at last fall's ISA Expo in Houston. The panel discussed various approaches to process manufacturing risk mitigation. These included combining control and safety in the same control system platform, the standalone safety instrumented system (SIS) approach, and the separate-yet-integrated safety system approach.

An end user on the panel discussed the common platform approach. He emphasized that his company's internal policies and procedures for risk assessment, implementation, operations and maintenance were well understood and consistently applied. These factors drove the decision to implement systems in this manner.

A safety instrumented system supplier discussed the standalone SIS approach and one of Chuck's colleagues discussed the separate yet integrated approach that is represented by safety instrumented systems like DeltaV SIS. Using several advanced technology examples including advancements in diagnostic coverage; common programming environments and global databases the presenter illustrated how such technologies, when appropriately applied, provided measurable savings throughout the safety lifecycle without compromising the SIS's ability to conform to international safety standards, such as IEC 61511.

Chuck's revelation was that the real issue is not so much the philosophy, the approach, the architecture, or even the platform selected. What really drives a successful SIS implementation is competency. Each of the presenters was passionate about their approach being the best solution because their individual competency was based on that particular philosophy and approach.

His bottom line--functional safety management must be implemented around the requirements of a technology and supported by competent safety professionals that always ensure that the SIS solution is defined, designed, installed, operated and maintained in a way that meets its defined functional safety requirements throughout its lifecycle.

As this group of panelists demonstrated in their exchanges with the audience--there are several philosophies, architectures and platforms to mitigate process manufacturers' safety risks. It takes competent safety professionals to work with these throughout the safety lifecycle.

Earlier I mentioned Emerson's Dean Taggart's work with complex sequences in safety instrumented systems, based on an ongoing oil sands gasification project. John Kingston, from Emerson local business partner Spartan Controls, is presenting on this topic along with Emerson's Chuck Miller at the upcoming ISA Expo 2007.

I received a copy of the submitted paper that, among other things, explores the separation between basic process control systems (BPCS) and safety instrumented systems (SIS). Historically, the SIS was a separate entity, but with technological advances, this has begun to change. The authors note that the IEC 61508 international safety standard does not provide a definition of separation. It does mention physical separation as a highly effective technique. Given that the standard is much more performance-based than prescriptive-based, they note that there are few statements defining separation.

The paper refers to a few specific clauses in 61508-1 such as 7.5.2.4, where when the control system places a demand on one of the safety-related systems, then it "...shall be separate and independent" from the safety-related systems. In order to satisfy this clause the control system must be proven sufficiently independent from the SIS. Certification agencies like the various TÜV organizations and other third-party testing labs help provide this proof for SIS suppliers per the IEC 61508 performance standards.

61508-1 Clause 7.6.2.7 addresses common cause failures by requiring functional diversity, technology diversity, diverse parts, services, and support, and that the BPCS and SIS not share common operational, maintenance, or test procedures, and that they be physically separated. Safety instrumented systems like DeltaV SIS address these in the authors' words:

Those factors [governing independence] include diversity, which essentially means that the BPCS and SIS should have different components, operating systems, chip sets, central processing units, etc. When looking at sharing parts, services, and support systems, once must ensure that the BPCS and SIS have different power sources, and that a safety network dedicated to safety related communications is used. They should not share test procedures, which means that if you are testing either the BPCS or the SIS, that those tests should be able to be run completely independently of each other. Finally, physical separation applies to how the architecture of the system is laid out, and how cabinetry is designed; in essence, this is where one would look at separating DCS cabinets from SIS cabinets, and perhaps maintaining the SIS from a different workstation than the one used for the BPCS.

A final clause that is discussed, 61508-2 Clause 7.4.2.3 explores how non-safety functions implemented in an SIS need to be treated as safety-related unless it can be shown it is sufficiently independent (that the failure of any non-safety-related functions does not cause a dangerous failure of the safety-related functions.) This implies that control and safety functions can exist within the same system as long as sufficient care is taken in design and throughout the IEC 61511 safety lifecycle.

The authors summarize the implications of separation well:

Essentially, everything all boils down to good engineering designs and practices. One must consider the standards carefully, and understand the implications before going down a certain path. One cannot simply look at a system and know if it satisfies these requirements, because almost every system has a different level of independence. One must look at the specific details of a system to verify that it satisfies the requirements.

Dean summed up how these applied to the asphaltene gasification project:

The complexity of the process led to a need for integration as well as separation. Integration brings the benefits of integrated development and operating environments, less training cost, simpler architectures, faster and more reliable communications, reduced integration time, better handling of status information, and improved fault handling. The safety requirements of gasification focus on preventing damage to the burner, reactor, and syngas cooler, as well as operator safety. The process itself leads to the need for an intricate startup, as well as multiple methods of shutting down the process depending on the current state. An integrated but separate solution can provide several advantages while still providing the required amount of separation.