1. ISA Division Newsletter
Safety
Summer 2005
Brian Smith, Editor Division
Director’s Message
By Edward M. Marszal, PE, CFSE
Dear ISA Safety Division Member,
I am very flattered to have been nominated and approved as Director
of the Safety Division of ISA. I am very excited about this opportunity
and have big plans to expand the membership of the Division by providing
Member benefits that will make the Division a “must have” resource for anyone who is
involved with engineering instrumentation containing safety aspects. Some of the plans involve
expanding the scope of the Division to cover all facets of instrumentation design that have
a safety critical impact. This might include such tasks as alarm system design, alarm
rationalization, and security considerations for safety instrumented systems (SIS).
I firmly believe that in order to make our Division a success we need to provide benefits that
cannot be obtained in any other place. We have had a great start under Paul Gruhn, when we
established a Division Symposium that has become a must-attend event for safety practitioners,
and a Web site (www.isa.org/divatsafety) that contains loads of information that is not available
anywhere else. We hope to renew these events starting in Spring 2006. I’d like to continue this
path by continuing to expand the value and size of safety-focused conferences and adding more
to the Web site sections that are only viewable by Division Members. I’d like to see the Web
site expand from providing the papers of past safety conferences (which is an excellent start) to
providing electronic tools and data for performing safety lifecycle tasks. This could include
IN THIS ISSUE:
tutorial presentations in PowerPoint, MPEG, or Flash format, spreadsheet tools for performing
SIS related calculations, and submittals of actual proven-in-use field data from end users for
Director’s Message 1 various types of equipment. These tools, along with the ability to share ideas and debate tech-
niques, both electronically and during conferences, will make Membership in the Division an
Past Director’s Message 2
indispensable tool.
Safety Instrumented Burner I am also very pleased to announce the 2005 slate of officers and sub-committee chairmen,
Management Systems — along with a new line-up of subcommittees.
Ready or Not Here
They Come! 3 STAFF SUPPORT: Rodney Jones, ISA, (919) 990-9418, rjones@isa.org
Application Software VOLUNTEER STAFF: Position Name Company
Fault Analysis 4 Director Ed Marszal Kenexis
Director-Elect Bud Adler AE Solutions
API Standards and
Program/Member Chair Carl Sossman (Acting) WSMS
Recommended Practices
Webmaster/Newsletter Brian Smith Nova Chemicals
for Offshore Facilities 6
Alarm Management for SUBCOMMITTEES: Burner Management Systems
Safety Alarms 6 Chair Mike Scott AE Solutions
Chair-Elect Kevin Maki
Book Reviews 7
Control Systems Security
Chair David Teumim Consultant
Fire and Gas Protection/Detection
Chair Charles Fialkowski Siemens
continued on page 2

2. Safety Division Newsletter • Summer 2005 Page 2
SUBCOMMITTEES: (continued) Nuclear Safety
Chair Troy Martel Past Director’s Message
Offshore Safety Paul Gruhn, PE, CFSE
Chair David Haysley Albert-Garaudy Associates Safety Division Past Director
Chair-Elect C.R.Ragu ONGC
I’m pleased to inform
Safety Instrumented Systems (Safety PES)
you that the Safety
Chair Andrew Dennant Emerson
Division won three
awards in 2003:
Safety Field Equipment
• Outstanding Divi-
Chair Bill Goble exida.com
sion — Honorable
Alarm Management
Mention
Chair Chris Wilson TiPS • Most Improved
Division
For anyone who is considering risk-based inspection consulting. In his • Division Communications Award
becoming active in the Division, it is a current position, he has experience in SIS (tied with the Analysis Division)
very satisfying and rewarding experi- implementation and process safety man- We were the ONLY Division to win
ence. If you see a sub-committee that agement projects for a variety of process three awards! A total of three other
does not have a chair-elect and would plants in diverse world-wide locations. Divisions won two awards each. We’ve
like to participate, please let me know. Marszal received a B.S.Ch.E. from Ohio accomplished a lot in just two years and
Also, we are looking to give Carl State University in 1992 with emphasis have much to be proud of! It wouldn’t
Sossman, who has been working tire- on control systems and artificial intelli- have been possible without the work of
lessly for the Division, a break from has gence. After receiving his degree he all of our board members. I am especially
seemingly endless responsibility for pro- joined UOP, a licensor of process units to grateful to Brian Smith (our Newsletter
gram direction with a fresh recruit. I the petroleum and petrochemical indus- Editor/Web Master) and Carl Sossman
have some ideas, but if you would like tries, where he performed field verifica- (our 2003 Program Chair). The fruits of
to throw your hat in the ring for this tion of control and safety instrumented their efforts are the most visible and
high-profile position, please let me systems at customer sites, and designed require the most work.
know. and managed development of custom I have completed my two-year term as
I am looking forward to a great year control and SIS projects. After leaving Division Director. Erwin Icayan will now
with the Division getting back on track UOP he worked with ERM-Risk, a risk take over as Director. Ed Marszal will be
in terms of growth and programming. management consulting firm specializing the next Director-Elect. I can’t think of
For those of you who don’t know me, in risk analysis and process safety man- two more qualified and capable leaders.
I’ve included some bio information agement. In this position he performed A number of the subcommittees are
below. Please feel free to call or write to and managed risk assessment projects changing faces as well. Butch Taggart
discuss any questions or comments you that included quantitative analysis. (Offshore Safety) will be passing over his
have about the Division, or safety Recommendations from these projects chair to Don Ogwude. Don is a consult-
instrumented systems in general. were used to ensure regulatory compli- ant who spent many years with Chevron
ance, justify risk reduction expenditures in California and is a member of the ISA
Edward M. Marszal, PE, CFSE and optimize insurance coverage. He SP84 committee. Mike Scott and Kevin
President, Kenexis Consulting teaches many of the Kenexis courses on Maki will be swapping their roles as
Corporation process safety management and safety chair and assistant in Burner Management
Phone: (614) 451-7031 ext. 1 instrumented system design and analysis. Systems. Simon Pate will be passing his
Fax: (614) 451-2643 He also regularly lectures on loss preven- chair position in Fire & Gas Systems over
Mobile: (614) 226-4263 tion topics at Ohio State University. to Robert Seitz. Robert is a PE in Alaska
E-mail: edward.marszal@kenexis.com Marszal peer reviews papers for ISA who specializes in such systems and serves
http://www.kenexis.com Technical Conferences and ISA on several standards committees.
Transactions, and is the author of the Palaniappan Kannan will serve as our
BIO: Mr. Marszal has over twelve years award winning ISA book Safety Integrity 2004 Spring Program Chair. Kalpen
of experience in safety instrumented sys- Level Selection. He is active in ISA at the Vachharajani will serve as our 2004 Fall
tems design and risk analysis. He is local and national levels, holding several Program Chair.
President of Kenexis Consulting positions with the ISA Columbus Section, Division board members have discussed
Corporation and responsible for engi- of which he is currently Vice-President, the idea of having Security receive a
neered safeguards design basis consulting and as a member of several safety related much higher profile within the Division
including: safety instrumented system standards committees, including SP84, (than it’s current subcommittee status).
implementation projects, process hazards SP91, and SP18. He is a registered pro- We discussed this with the Chair of our
analysis, quantitative risk analysis, alarm fessional engineer in Ohio and Illinois Security Subcommittee and certain mem-
management and rationalization, pres- and also a TÜV certified functional safe-
continued on page 3
sure relief valve and system surveys, and ty expert.

3. Safety Division Newsletter • Summer 2005 Page 3
Safety Instrumented Burner Management Systems
Ready or Not Here They Come!
Michael D. Scott, P.E., Safety Division BMS Chairman
VP – Process Safety, AE Solutions, P.O. Box 26566, Greenville, SC 29616
The concept of a Safety Instrumented • EN 50156-1 – A German standard • FM Representative
Burner Management System (SI-BMS) is covering electrical equipment for • NFPA 85/86 Representative
here to stay. If you are unsure of this furnaces that is scheduled for • ISA SP84 BMS Sub-Committee
statement one should consider that six revision in 2004. This document Member
different codes/standards currently exist invokes SIS requirements for a • Process Industry End Users
and/or are being revised to invoke the BMS.
Safety Lifecycle with respect to Burner • API 556 – Document governs
Management Systems. This includes the design of BMS’s in the petroleum
following: industry. Is being revised to invoke
• The Black Liquor Recovery Boiler SIS requirements on BMS’s.
Advisory Committee (BLRBAC)
has developed several guideline To promote the SI-BMS concept, ISA
documents regarding design and has developed a Web seminar and is in
operation of Recovery Boilers in the process of introducing a one-day
the Pulp and Paper Industry. These course on this topic. The schedule for the
documents invoke SIS requirements next BMS-related training is as follows:
on the Recovery Boiler BMS. • Is a Burner Management System a
• FM 7605 – Factory Mutual Safety Instrumented System? Web
requires that any PLC listed for use seminar 14 July 2005 & 16
in combustion safeguard service November 2005
meet the SIS requirements con- • Safety Instrumented — Burner
tained in IEC 61508. At this writ- Management Systems: A How To
ing we are aware of only one ven- Primer One-day seminar (Dates to
dor who has a product submitted be announced in the near future)
to FM for approval with respect to
SI-BMS. If the above subject is of interest to Check out this
• SP84 – The ISA SP84 committee you, or if you have other intriguing informative book
has formed a BMS sub-committee questions regarding BMS designs, the
to develop a document that clari- Safety Division provides an excellent from ISA.
fies how SIS concepts apply to a forum to search for answers. This can Go to www.isa.org/
BMS. Examples being included in be accomplished in three ways:
safetyreliability for more
the document for each code or 1) Join the Safety Bulletin Board and
standard are: post your BMS questions for the information on this and other
• NFPA 85 – Single burner boiler Division members to answer. safety-related books from ISA.
• NFPA 86 – Thermal oxidizer 2) Plan on attending ISA EXPO 2005 Read a review of this book
• API 556 – Process heater with in Chicago. A BMS paper session
multiple burners and/or panel session is planned to on page 7.
• API 14C – Reboiler address this subject. Contact Mike
• API 14C – Heater Treater Scott if you wish to present papers
The goal of the SP84 committee and/or participate in a panel session
is for industrial users to properly on BMS designs. Past Director’s Message
follow the safety lifecycle to define 3) The ISA EXPO 2005 panel session continued from page 2
the risk associated with every BMS will provide a forum for the audi-
to determine if it is a SIS. ence to ask questions of industry bers of the SP99 security standard com-
• NFPA 86 Committee is planning to experts on the design and applica- mittee. ISA has already had at least two
update this standard to reflect their tion of BMS’s. The goal of this Security Conferences. It would make
agreement that an industrial BMS panel session is to review NFPA sense for both groups to join forces and
is a SIS and that a safety PLC requirements for BMS’s and com- take advantage of the synergy. Perhaps
should be used. A linking para- pare/contrast these issues with the we may change our name to the Safety &
graph will be added that refers to requirements of SIS standards (i.e. Security Division. Stay tuned for where
ANSI/ISA-84.00.01-2004 as ANSI/ISA-84). Erwin may lead us in this area.
acceptable methodology. • Proposed Panel Session Members It’s been a pleasure serving with you.

4. Safety Division Newsletter • Summer 2005 Page 4
Application Software Fault Analysis
Palaniappan R. Kannan
SISRA Consultants, Singapore 650319, Rmp66@singnet.com.sg
Abstract are the ones that can be used effectively • Improper handling of data types
A Programmable Electronic System and when they should be used in the • Truncation and rounding off errors
(PES) consists of both hardware and process of software development. This • Improper handling of abnormal
software. Hardware failures are pre- requires knowledge about the software conditions
dictable whereas software faults and faults that occur in the first place, which • Calculation overflow
failures are not. These software compo- needs to be categorized in order to
nents are what make PESs more com- understand the problem areas. Variable Initialization: The initial val-
plex. The only way to address software The major categories of application ues assigned to variables at the start and
related failures in PESs is through imple- software faults are: re-start of program execution need to be
mentation of proper development • Calculation error free for the proper execution of
process, programming methods and rig- • Variable Initialization the programs and resulting outputs. In
orous testing. This article will review • Timing Synchronization case of hardware or processor redun-
various types of faults that can occur in • Interface dancies, the variable values should
application software development. • Change Impact transfer correctly for proper continua-
• Omission/Commission tion of their succeeding runs. Counters
Introduction • Configuration Management and timers also need to be considered.
Application software is one of the • Data Typical problems found in variable ini-
components that contributes to the • Requirement Specification tialisation are:
unavailability of a PES. Software failures • Logic • Lack of, or incorrect, initial values
are one type of systematic failures that when programs start or restart
reside inside the system as built in faults. Calculation: Calculation errors can be • Initial or present value storing and
In order to avoid software based failures due to programming the algorithm/for- transfer problems for succeeding
of a system, it is important to identify mula incorrectly or computational errors. runs and hardware transfers
and rectify all the software faults during Types of registers, their addressing meth-
the various phases of its development. ods, and the way the processor handles Timing Synchronization: This factor
Many software faults are not self-reveal- the floating-point values are different for comes into play when there is real time
ing. Also, unlike hardware failure rates, different systems. Proper understanding execution of software processes and
software failure rates are not predictable of these points is essential. Typical prob- when different processes executed in dif-
and cannot be accurately quantified. lems found in calculation faults are: ferent domains need to interact.
Failure rates cannot be used effectively • Incorrect coding of constants Depending on the points of interaction
to determine safety integrity levels. • Improper handling of boundary this can affect data acquisition, code
There are many reasons for software- conditions execution, system functioning, and/or
related failures. These range from poor
development processes, application
Software
complexity, interaction between mod- Software Validation
ules, poor personnel competence, vari- Requirement Testing
Specification
ability, and use of off-the-shelf software.
Software Development Process
The first step in avoiding software Software
faults is to follow a good development Architecture Software
and System Integration
process. The process should handle the Testing
Design
complexity associated in the development
of software. Various standards recom-
mend the classic “V-model” (see Figure
1), which emphasizes modular develop- Software
Module Software Module
ment and testing each phase. Test plans Testing
Design
and methods need to be established.
Software Faults
There are numerous methods for Figure 1: The V-Model
software fault prevention and detection. of Software Development
However, it’s necessary to know which Software Coding
and Testing
continued on page 5

5. Safety Division Newsletter • Summer 2005 Page 5
continued from page 4 configuration management procedures Logic: Logic faults have their roots in
system outputs. Typical problems found should be adopted throughout the soft- requirements, design and/or code. Logic
in timing synchronization are: ware lifecycle. Three areas that require problems do not relate to phases, but
• Interacting processes going out of configuration management is required rather to the whole development process.
synchronization are documentation, hardware, and soft- Competent personnel and their ability to
• Inaccurate real time clock ware. Software versioning tools are now understand the requirements are key.
• Non-occurrence of event due to available as part of application develop- Typical logic related problems are:
timer failure ment. Configuration management also • Faults due to incomplete or incor-
helps to set responsibilities and account- rect logic
Interface: In order to perform its ability and should be part of software • Faults due to interaction between
functions and provide useful output the development management. Typical various modules
system software needs to interface with problems in configuration management • Improper functioning during
other system devices and software. are: abnormal conditions and states
These can be inputs devices, outputs • Selection of incompatible hardware • Coding errors
devices, or other systems performing and software
other functions. The requirement speci- • Failure to upgrade other systems to Conclusion
software changes This article reviewed various types of
fication should describe all interface
• Use of incorrect master program faults that can occur in application soft-
needs. All interfaces should be traceable
for software revisions ware development. Adopting a good
to the requirement specification. Typical
development process is of paramount
problems found in interfaces are:
Data: Faults can occur due to data importance. It is important to identify
• I/O interface errors
types, units, range values, and acceptable probable fault categories and the neces-
• Calling of incorrect functions and
change magnitude/frequency. Hardware sary techniques that need to be used to
sub-routine
manuals should exist and should provide avoid them. The identified fault cate-
• Mistakes in passing of parameters
details about the limitations in data codi- gories and detection/prevention tech-
fication. Programs should contain diag- niques need to be assigned to various
Change Impact: Software development
nostic code to handle data faults, such as phases of the development process. Once
contains many feedback paths. Revisiting
data validation techniques. For example, this is done, resources can be identified
earlier phases and making changes are
all input data can have a valid range and test cases can be prepared.
common. After all, software requirements
specified, and if a value goes out of range However, it is difficult to identify
are based on overall system requirements
a diagnostic alarm can be triggered. one’s own fault. This also applies to the
and changes in software requirements can
Another way of avoiding data faults is to software development team. Therefore,
also occur as the design progresses. Every
use typed data tables. Typical data relat- review by different competent persons
time a change is incorporated, the overall
ed problems are: not belonging to the team can greatly
impact of that change should be studied
• System failure due to invalid input help in fault finding. Assessment and
thoroughly. Typical problems due to
data assurance can accomplish this.
change impact are:
• Problems in database data retrieval Every software application is unique,
• Inability to properly execute logic
and so are its faults and failures. Iden-
and sequential function
Requirements: The starting point of tification of faults requires feedback
• Incompatibility of existing systems
software development is the requirement from existing applications. Therefore,
with changed device
specifications. This is critical for the fault related data collection from differ-
• Loss of existing function
completeness and correctness of the final ent applications can be of great value in
• Change not verified and validated
product. Care should be taken to devel- understanding the types of problems in
op a correct requirement specification specific application domains and devel-
Omission/Commission: Anything
which should deal with performance oping prevention/detection techniques.
produced by human beings is subjected
to omission and/or commission errors. requirements, functional requirements
and interface requirements. Semi-formal References
Software is no exception. These errors
methods such as function block dia- 1. Functional safety of electrical/elec-
can result in missing required system
grams, flow charts, truth tables, etc., can tronic/programmable electronic safety-
functions and/or additional system func-
be used in specifying various functions. related systems, IEC 61508, 2000,
tions not required by system. System
Verification and validation are key steps International Electrotechnical
functional documents, which are
to ensure that the software produced Commission, Geneva, Switzerland.
required as part of the development
complies with the requirements. Typical 2. Wallace, Dolores R., Laura Ippolito,
process, can also have omission and
problems caused by requirement specifi- and Barabara Cuthill, “Reference
commission faults. Typical problems
cations are: Information for the Software Verification
due to omission and/or commission are:
• Unspecified exceptional conditions and Validation Process,” NIST SP 500-
• Missing (or) improper documentation
and states 234, National Institute of Standards and
• Missing specification requirements
• Missing functions in the specification Technology, MD 20899, April 1996.
• Missing functions
Configuration management: Good • Unspecified testing requirements
continued on page 6

6. Safety Division Newsletter • Summer 2005 Page 6
continued from page 5
API Standards and Recommended Practices
Author Bio
Palaniappan Kannan has 18 years of for Offshore Facilities
instrumentation, process, control and
safety system experience. He has To understand the needs of the • API RP 14G – “Recommended
worked in various phases of oil and gas upstream segment facilities for the Practices For Fire Prevention and
and petrochemical projects in operation petroleum industry, it is necessary to be Control on Open Type Offshore
and maintenance, engineering, consul- familiar with the basic standards that Production Platforms”
tancy, and system integration. are used. During the coming year, it is • API RP 14J – “Recommended
Palaniappan has a Bachelors degree in the goal of the ISA Safety Division Practices For Design and Hazards
instrumentation and is a Certified (Offshore Sub-Committee) to develop Analysis for Offshore Production
Functional Safety Expert (CFSE). CFSE is and publish papers on some of the Facilities”
an accreditation by TÜV certifying com- applicable API standards and recom- As Chairman of this subcommittee, I
petency to implement Safety Instrument mended practices that deal with safety am requesting input on these documents,
Systems (SIS) in line with international issues in the design, fabrication, installa- or any other documents that would be
standards such as IEC 61508 and IEC tion, and operation of this segment of applicable. Details on any experience
61511. Palaniappan has a Masters degree the petroleum industry. It is intended with combining the requirements of these
in Business Administration (MBA) and is that these papers will cover general safe- API documents and the ISA/IEC SIS stan-
a certified Project Management ty issues and, to the extent possible, dards would be greatly appreciated. If
Professional (PMP-PMI). focus on BPCS, Fire and Gas Detections you have papers, or want to develop a
Palaniappan is actively involved in Systems, and SIS. Co-ordination of these paper, please contact us.
professional bodies like ISA and IEEE. documents with the current ISA Also if you have any recommendations
He has published articles and developed (ANSI/ISA-SP84.00.01) & IEC (IEC- on other activities that our subcommittee
software tools in the SIS area. He is a 61511) standards will also be addressed. should pursue, we would like to hear
committee member of ISA SP84- Preliminary Listing of Documents: them.
Programmable Electronic System (PES) • API RP 75 – “Development of
for Use in Safety Applications and ISA Safety and Environmental Contact:
SP99 – Manufacturing and Control Management Program for Outer David Haysley
System Security standard committees. Continental Shelf Operations and Albert-Garaudy and Associates, Inc.
Throughout his career Palaniappan Facilities” 3500 N. Causeway Blvd.
has been involved in HAZOP studies, • API RP 14C – “Recommended Metairie, LA 70005
developed SIS specifications, engineered Practice for Analysis, Design, (504) 846-6466
SIS systems, performed SIL verification Installation and Testing of Basic Cell: (504) 231-5262
calculations, and developed SIS func- Surface Safety Systems for dhaysley@aga-engineers.com
tional testing procedures. Offshore Production Facilities”
Alarm Management for Safety Alarms
At ISA EXPO 2004 last year, I had similar to a HazOp study. Some support imize the possibility of a mistake when
the opportunity to sit down and discuss a more simplistic view, a “lightweight” removing or changing alarms, consider
a growing concern that current trends in version of alarm management that does the mass of alarms that were added
“alarm management” ignored the safety not involve the paperwork, personnel, without any formal review.
ramifications of changing the alarm sys- resource overhead of a “HazOp-style” Alarm management projects are
tem. The conversations centered on the alarm management project. intended to remove the smoke from oper-
loss of safety related alarms due to People who support a more compre- ators’ eyes. How much of that smoke was
incomplete or arbitrary reviews prior to hensive approach to alarm management arbitrarily implemented? Perhaps if we
the removal or modification of alarm almost always focus on the process of embraced a HazOp-style process of alarm
system settings. Emphatic points were removing alarms. Don’t doubt that a system design and of controlling changes,
made in support of a safety-centric holistic review and redesign of an alarm we can prevent the need for massive
review process, or at least for the inclu- system can be a painful proposition. alarm redesign projects in the future.
sion of HazOp information during the There is no magic button that can
review process. reverse what has already become a Chris Wilson
Many involved in defining what alarm problem, but there is a way to prevent Marketing Manager
management is embrace a safety oriented the problem in the future. TiPS, Inc.
viewpoint and feel that it aligns well with Alarm management exists because (512) 863-3653 x 520
their already established opinion that the alarms have gone out of control. Some chris@tipsweb.com
process of alarm management should be level of due diligence is required to min-

7. Safety Division Newsletter • Summer 2005 Page 7
Book Reviews
FMEDA data and many product specific and control manager. The shift of control
entries based on specific FMEDA data systems from proprietary to commercial-
from TÜV, FM, exida and others. off-the-shelf hardware and software and
The handbook can be purchased network connectivity have created new
through the following three sales vulnerabilities in industrial networks. But
channels: cybersecurity alone is not enough. A
• exida.com online store complete security program also includes
• ISA online store, www.isa.org/books personnel security, and physical security.
• Amazon.com Cybersecurity consists of protecting
the availability, integrity, and confiden-
tiality of the systems and data. This
Safety Equipment Reliability requires understanding the threats to the
systems and the vulnerabilities of the
Handbook systems. Threats like the Slammer worm
Published by exida.com and buffer overflows are explained.
ISBN: 0-9727234-0-4 Some of the highlights of this book are
the examples of real attacks on control
Are you performing Safety Instrumented systems and the consequences.
Function verification calculations? Countermeasures can be designed to
Regardless of what method you are using protect against the threats. Usually a
– Simplified Equations, Reliability Block system for identification, authentication,
Diagrams, Fault Tree Analysis, Markov and authorization is one of the most
Modeling, or a commercially available important layers of defense.
tool – you need failure rate and failure The remainder of the book covers the
mode data. The exida Safety Equipment
Industrial Network Security steps, at a very general level, to execute
Reliability Handbook contains the infor- By David Teumim an industrial network security program.
mation you are looking for. Published by ISA The first step is planning and design for
The exida Safety Equipment ISBN: 1-55617-874-3 security, such as separation of networks.
Reliability Handbook was officially An understanding of the technology, like
released in March 2003. The handbook The ABCs of Network Security encryption and firewalls is important.
was created to solve one of the major Reviewed by Nick Sands To make an effective security system
problems when implementing Safety One of the hottest topics in the con- requires writing clear policies for the
Instrumented Function verification cal- trol industry is security for process con- application of technology, trained and
culations, i.e. getting failure rate and trol systems and networks. Finally ISA aware people, and periodic audits and
failure mode data. The handbook was has a book on the subject: Industrial other methods to provide assurance of
created to supply that information in a Network Security by David Teumim. the effectiveness of the security pro-
format specific to safety integrity verifi- Teumim is a certified information system gram. Some example approaches to
cation and to allow for easy comparison security professional (CISSP) and a industrial network security programs
between equipment items or designs on workgroup leader for SP99, the commit- from Dupont and Proctor & Gamble
failure rates, failure mode distributions, tee working on manufacturing and con- form the last chapter.
and diagnostic detection capability. trol system security. The book is very Every company in the control commu-
(This is the primary difference between basic – an introduction to an introduc- nity will have people that can benefit
the exida handbook and other more tion on the subject. But with such a new from reading this book, people that need
generic reliability data sources, such as area, this elementary book is a good a basic understanding of information
OREDA – Offshore Reliability Data, beginning to the body of knowledge. security for manufacturing and control
AIChE, IEEE, and others.) The first chapters are an introduction systems. Teumim just introduces the sub-
It contains data on a wide variety of and background, answering many ques- ject though, with little detailed informa-
safety-related equipment, such as pres- tions. What is an industrial network? tion. Future books or revisions of this
sure transmitters, temperature transmit- Why should it be secure? Can it be book will have more lasting value as ref-
ters, safety PLCs, input and output secure and open? Who should work on erences. So, even though this book is a
interface modules, valve controllers, security? How is the cost justified? must read, it is not a must buy at $54
valves, and many more. It contains Teumim contrasts IT security issues, (ISA Member price). It is a great book to
generic failure rate data based on indus- managed corporately by a CIO and a borrow.
try database compilations and field fail- cybersecurity manager, with security for It is available online at:
ure data, generic failure mode informa- manufacturing control systems, managed • ISA online store, www.isa.org/books
tion derived from field failure data and by a plant personnel like the automation • Amazon.com