Session Actions

Session Details

PLC / DCS Configuration, Migration, and Management

6 November 9:15 a.m. - 10:45 a.m.

Track: Industrial Automation and Control

Paths(s): EngineerEngineer   Academia/R&D/ScientistAcademia/R&D/Scientist   

Paper(s):

Route 2H Implications on IEC 61511 - Are We Opening Pandora's Box?

Luis Manuel Garcia B. Eng, Mech Eng. CFSE, Siemens Industry Inc

Abstract:

In 2010, The International Electrotechnical Commission (IEC), the leading global organization that prepares and publishes International Standards for all electrical, electronic and related technologies, released the second edition of IEC 61508 (Functional safety of electrical/electronic/programmable electronic safety-related systems).  Among several changes in edition 2, there is one which modifies the definition of Safe Failure.  This turns out to affect the weight of architectural constraints known also as Hardware Fault Tolerance (HFT) tables.  These tables act as safety nets for Hardware Safety Integrity evaluations and have forced some equipment evaluation teams to follow a new alternative validation route in order to certify instrumentation. This is because in some cases, the Safe Failure Fraction (SFF) values in the original tables are now much harder to reach. This new route (2H), which appears to be originally developed for Type A equipment, (yet allowed for Type B equipment with Diagnostic Coverage higher than 60 %) is based on the strict management of data as per IEC 61649 and IEC 60300. This paper discusses why in the newer version of IEC 61511 (which is being reviewed as this paper is written), there is no real need to include any related changes as they already are naturally implied by both 61511 and 61508 in the definitions of their scope.

The Integration of DCS I/O to an Existing PLC

Debashis Sadhukhan PE, NASA Glenn Research Center Read Bio

I received my BSEE from the University of Akron in 1990, my MSEE from the University of Toledo in 1995 and my MBA from Clevealnd State University in 2000.  I have been working at NASA in Process Controls Engineering since 1991 and currently hold the position of Process Controls System Manager. 

Abstract:

At NASA Glenn Research Center (GRC), Existing Programmable Logic Controller (PLC) I/O was replaced with Distributed Control System (DCS) I/O, while keeping the existing PLC sequence Logic.  The reason for integration of the PLC logic and DCS I/O and evaluation of the resulting system is the subject of this paper.  Pros and cons of the old system and new upgrade are described including operator workstation screen update times.  Detail of the physical layout and the communication between the PLC, the DCS I/O and the operator workstations are illustrated. The complex characteristics of a central process control system and the plan to remove the PLC processors in future upgrades is also discussed.

Is Your Automation Problem Really a Power Quality Problem in Disguise?

David Paul, MAVERICK Technologies Read Bio

B.S. Electrical Engineering Clemson University 1986
Registered Professional Engineer in the States of: California, Illinois, South Carolina
Professional Employment:
Fluor Daniel  - Automation Engineer 1986-1989
John D. Hollingsworth on Wheels -  Electrical Engineer 1989-1996
Worldwide Technologies - Electrical Engineer 1996-1999
Self Employed 1999-2005
Tegron - Project Engineer 2005-2009
MAVERICK Technologies - Principal Engineer 2010-Present

Abstract:

Do you have production losses or shutdowns in your plant attributed to the automation system?  Do you have automation problems attributed to software “Bugs” or software anomalies that happen at random?  Does your automation system experience excessive or repeated hardware failure of components such as PLCs, Power Supplies, Variable Frequency Drives and Communication Devices? Many facilities attribute these costly failures and production losses to poor vendor hardware and/or poor software programming practices.  Many plants simply write off these excessive costs as a “cost of doing business”, replace failed hardware, and reset the software.   These issues should not be tolerated.

Many of these automation problems are symptoms which have their root cause in the electrical power system. The analysis of these problems requires a holistic approach as there is interaction and interrelationship between the electrical power system and the automation system components.  Unfortunately, power system engineers generally don’t understand automation and automation engineers don’t have a good working knowledge of electrical power systems.  It may take both these engineers working together to find a solution as many times the best solution is a balanced tradeoff between several different options.   Discussion will include a logical method to investigate these problems and typical problems that are encountered.  The presentation will include case studies of actual investigations and projects that resolved long standing, difficult to solve automation problems that had their root cause in the electrical power system.