.
WBF-WG ``Flow Analysis''
Draft Technical Report
WBF-WG ``Flow Analysis''
ISA-88 Modeling using Flow Analysis
Draft 3 - September 2003
This document is a draft that represents work being done by a WBF
Working Group
WBF grants permission to anyone to reproduce and distribute copies of
this WBF draft, in whole or in part, but only for the following purposes
and only as long as the recipient is not charged any fee for the copy
(nor may the copy be included as part of a package with other materials
or presentations for which a fee is charged):
1. Review of and comment on the draft standard;
2. Provide to others for review and comment;
3. Promotion of the WG work; or
4. Informing and educating others about the WG.
In addition, all copies must reproduce a copyright notice as follows:
(c) Copyright 2001 WBF. All rights reserved. Reproduced and distributed
with permission of WBF.
WBF reserves all other rights to the draft. Any other reproduction or
distribution without the prior written consent of WBF is prohibited.
The reader is cautioned that this document has not been approved and
cannot be presumed to reflect the position of WBF or any other
committee, society, or group. Although every effort has been made to
ensure accuracy, neither WBF, members of WG, nor their employers shall
be held liable for errors or limitations.
Yellow highlighting: under construction
Blue highlighting: question marks, editor's notes
WBF-WG_FA Draft on Flow Analysis
Copyright (c) 2001 by WBF. All rights reserved. Not for resale.
Printed in the United States of America
World Batch Forum
107 S. Southgate Drive
Chandler, Arizona 85226
Phone: 480-893-8803 Fax: 480.893.7775
E-mail: deann@kc-a.com
Preface
WBF working groups provide an unbiased means for the investigation and
development of work items of interest to the members. People of like
interests meet (in person or electronically) in order to delve into
specific topics. Although the topics addressed will be determined by
each working group possible topics are:
XML based batch data exchange formats
Exception handling
Continuation or publication of EBF working group results
Process plant analysis based on ISA-88
Procedure Function Chart examples
Good practices
Benchmarks
While the WBF will own the copyright to all WBF Working Group Reports,
all working group members are given royalty free use of the WBF Working
Group Reports for personal and professional purposes. This includes use
by the employers of working group members, to use work products of the
working group, including any work published by the working group.
This draft technical report has been issued by the World Batch Forum
(WBF), Working Group ``Flow Analysis''
The following served as members of this group:
Email Name Company Country
HYPERLINK "mailto:a-smith@its-ltd.co.uk" a-smith@its-ltd.co.uk
Anthony Smith INDUSTRIAL TECHNOLOGY LTD UK
HYPERLINK "mailto:alain.bosatelli@eu.rhodia.com"
alain.bosatelli@eu.rhodia.com Alain Bosatelli RHODIA FR
HYPERLINK "mailto:alfonso.sancho@honeywell.com"
alfonso.sancho@honeywell.com Alfonso Sancho HONEYWELL
HYPERLINK "mailto:bernard.cubizolles@isa-france.org"
bernard.cubizolles@isa-france.org Bernard Cubizolles ASOPHIA FR
HYPERLINK "mailto:bertrand.ricque@euraltech.fr"
bertrand.ricque@euraltech.fr Bertrand Ricque EURALTECH FR
HYPERLINK "mailto:dbrick@aegiscorp.com" dbrick@aegiscorp.com D.
Brick AEGIS ANALYTICAL US
HYPERLINK "mailto:dclermon@lu.danone.com" dclermon@lu.danone.com
Dominique Clermont DANONE FR
HYPERLINK "mailto:djoannes@danonefr.danone.com"
djoannes@danonefr.danone.com Didier Joannes DANONE FR
HYPERLINK "mailto:dror@specsoft-pfs.com" dror@specsoft-pfs.com Dror
Eyal SPEC SOFT IS
HYPERLINK "mailto:Ed.Lynch@pfizer.com" Ed.Lynch@pfizer.com Ed Lynch
PFIZER US
HYPERLINK "mailto:emerson@dallas.yca.com" emerson@dallas.yca.com
Dave Emerson YOKOGAWA US
HYPERLINK "mailto:emol@starren.nl" emol@starren.nl Elbert Mol
STARREN NL
HYPERLINK "mailto:eric_vitte@mail.schneider.fr"
eric_vitte@mail.schneider.fr Eric Vitte SCHNEIDER ELECTRIC FR
HYPERLINK "mailto:etsmrb@aol.com" etsmrb@aol.com Remi Metras RMB FR
HYPERLINK "mailto:fl@controldraw.co.uk" fl@controldraw.co.uk Francis
Lovering CONTROL DRAW UK
HYPERLINK "mailto:j.relland@alpha-cim.com" j.relland@alpha-cim.com
Jose Relland ALPHA-CIM FR
HYPERLINK "mailto:Jacky.Tachon@aventis.com" Jacky.Tachon@aventis.com
Jacky Tachon AVENTIS FR
HYPERLINK "mailto:Jacques.cothenet@eu.rhodia.com"
Jacques.cothenet@eu.rhodia.com Jacques Cothenet RHODIA FR
HYPERLINK "mailto:jacques.grossin@adp.fr" jacques.grossin@adp.fr
Jacques Grossin AEROPORTS DE PARIS FR
HYPERLINK "mailto:jean-francois.cardot@isa-france.org"
jean-francois.cardot@isa-france.org Jean-Francois Cardot RHODIA FR
HYPERLINK "mailto:jean-pierre.bovee@aventis.com"
jean-pierre.bovee@aventis.com Jean-Pierre Bovee AVENTIS PHARMA DE
HYPERLINK "mailto:jean.vieille@isa-france.org"
jean.vieille@isa-france.org Jean Vieille* *** CONSULTANT FR
HYPERLINK "mailto:jmrayon@jmrconseils.fr" jmrayon@jmrconseils.fr
Jean-Michel Rayon CONSULTANT FR
HYPERLINK "mailto:Josef.Meixner@erls.siemens.de"
Josef.Meixner@erls.siemens.de Joseph Meixner SIEMENS DE
HYPERLINK "mailto:jwindle@Foxboro.com" jwindle@Foxboro.com John
Windle FOXBORO US
HYPERLINK "mailto:khaled.kassem@cran.uhp-nancy.fr"
khaled.kassem@cran.uhp-nancy.fr Khaled Kassem CRAN University of Nancy
FR
HYPERLINK "mailto:lionelcerisier@yahoo.fr" lionelcerisier@yahoo.fr
Lionel Cerisier
FR
HYPERLINK "mailto:mcelenk@hotmail.com" mcelenk@hotmail.com Metin
CELENK YILDIZ Holding TU
HYPERLINK "mailto:omer.akdeniz@frenchbatchforum.org"
omer.akdeniz@frenchbatchforum.org Omer Akdeniz** SINFOR AUTOMATION FR
HYPERLINK "mailto:p.levrard@arcinfo.com" p.levrard@arcinfo.com
Philippe Levrard ARC INFORMATIQUE FR
HYPERLINK "mailto:Patrick.Richard@aventis.com"
Patrick.Richard@aventis.com Patrick Richard AVENTIS FR
HYPERLINK "mailto:paul.jones@eu.rhodia.com" paul.jones@eu.rhodia.com
Paul Jones RHODIA UK
HYPERLINK "mailto:pallot@ordinal.fr" pallot@ordinal.fr Philippe
Allot ORDINAL TECHNOLOGIES FR
HYPERLINK "mailto:quem@tpg.com.au" quem@tpg.com.au Spiro
Georgakopoulos QUEMM ASSOCIATES PTY LTD AU
HYPERLINK "mailto:rdespins@foxboro.com" rdespins@foxboro.com Robert
Despins FOXBORO FR
HYPERLINK "mailto:rfp@optusnet.com.au" rfp@optusnet.com.au Robert
Price CSL Ltd. AU
HYPERLINK "mailto:smmcleod_uk@yahoo.co.uk" smmcleod_uk@yahoo.co.uk
Steve MacLeod JACOBS ENGINEERING UK
HYPERLINK "mailto:Tony@simmons.demon.co.uk" Tony@simmons.demon.co.uk
Tony Simmons CONSULTANT UK
HYPERLINK "mailto:viruega@ensgi.inpg.fr" viruega@ensgi.inpg.fr
Jean-Louis Viruega ENSGI INPG FR
HYPERLINK "mailto:willie.lotz@sabreweries.com"
willie.lotz@sabreweries.com Willie Lotz SOUTH AFRICAN BREWERIES SA
HYPERLINK "mailto:yong.miao@aspentech.com" yong.miao@aspentech.com
Yong Miao ASPEN TECH
HYPERLINK "mailto:yusaksp@yahoo.com" yusaksp@yahoo.com Yusak
Pandiana Technical University of Delft NL
* Editor
** FBF WG4 chair
*** WBF ``FA'' WG chair
The following companies have sponsored this work:
SCHNEIDER ELECTRIC (Draft 1)
ROCKWELL AUTOMATION (Draft 2)
SIEMENS Automation & Drives (Draft 3)
Contents
Page
TOC \o "1-5" \t
"Style1,1,Style2,2,Style3,3,Style4,4,Foreword,1,Introduction,1" 1 Scope
PAGEREF _Toc49853634 \h 12
2 references PAGEREF _Toc49853635 \h 12
2.1 Normative references PAGEREF _Toc49853636 \h 12
2.2 Other documentation PAGEREF _Toc49853637 \h 12
3 Definitions PAGEREF _Toc49853638 \h 14
3.1 Complex node PAGEREF _Toc49853639 \h 14
3.2 Confining node PAGEREF _Toc49853640 \h 14
3.3 Connection PAGEREF _Toc49853641 \h 14
3.4 Directing node PAGEREF _Toc49853642 \h 14
3.5 Equipment procedural element (EPE) PAGEREF _Toc49853643 \h 14
3.6 Flow PAGEREF _Toc49853644 \h 14
3.7 Flow Analysis PAGEREF _Toc49853645 \h 14
3.8 Flow breaker PAGEREF _Toc49853646 \h 14
3.9 Node PAGEREF _Toc49853647 \h 15
3.10 Path PAGEREF _Toc49853648 \h 15
3.11 Terminal PAGEREF _Toc49853649 \h 15
4 Overview of Flow analysis PAGEREF _Toc49853650 \h 16
4.1 A constraints based modeling PAGEREF _Toc49853651 \h 16
4.2 Intrinsically safe operational vs conventional interlocking
PAGEREF _Toc49853652 \h 16
4.3 Production Plant from Flow Analysis point of view PAGEREF
_Toc49853653 \h 18
5 Modeling principles and terminology PAGEREF _Toc49853654 \h 21
5.1 Basic principles PAGEREF _Toc49853655 \h 21
5.2 Modeling a process cell PAGEREF _Toc49853656 \h 21
5.3 Nodes, Terminals and Connections PAGEREF _Toc49853657 \h 22
5.4 Directing nodes and flow breakers PAGEREF _Toc49853658 \h 23
5.5 Confining nodes (CN) PAGEREF _Toc49853659 \h 24
5.6 Terminals PAGEREF _Toc49853660 \h 25
5.7 Connections PAGEREF _Toc49853661 \h 26
5.8 Complex nodes PAGEREF _Toc49853662 \h 27
5.8.1 Grouping nodes together PAGEREF _Toc49853663 \h 27
5.8.2 Nodes Breakdown principles PAGEREF _Toc49853664 \h 28
5.8.3 Grouping directing and confining nodes PAGEREF _Toc49853665 \h
29
5.9 Generic model PAGEREF _Toc49853666 \h 29
5.10 Mapping FA entities on S88 equipment entities PAGEREF
_Toc49853667 \h 30
5.11 Functional view: Equipment Procedural Entities PAGEREF
_Toc49853668 \h 30
6 Object model and attributes PAGEREF _Toc49853669 \h 32
6.1 Overview PAGEREF _Toc49853670 \h 32
6.2 Control Module Object Model PAGEREF _Toc49853671 \h 32
6.3 S88 Objects PAGEREF _Toc49853672 \h 32
6.4 Attributes and Properties objects PAGEREF _Toc49853673 \h 33
6.5 Path object PAGEREF _Toc49853674 \h 34
6.6 Flow object PAGEREF _Toc49853675 \h 34
6.6.1 Flow object attributes PAGEREF _Toc49853676 \h 34
6.6.2 Flow properties PAGEREF _Toc49853677 \h 34
6.6.3 Material requirement properties PAGEREF _Toc49853678 \h 35
6.6.4 Flow object operations PAGEREF _Toc49853679 \h 35
6.7 Node object PAGEREF _Toc49853680 \h 35
6.7.1 Types of nodes PAGEREF _Toc49853681 \h 35
6.7.2 Node object attributes PAGEREF _Toc49853682 \h 36
6.7.3 Node properties PAGEREF _Toc49853683 \h 37
6.7.4 Node object operations PAGEREF _Toc49853684 \h 37
6.8 Directing Node object PAGEREF _Toc49853685 \h 37
6.8.1 Directing node object attributes PAGEREF _Toc49853686 \h 37
6.8.2 Directing node properties PAGEREF _Toc49853687 \h 38
6.8.3 Directing node operations PAGEREF _Toc49853688 \h 38
6.9 Confining node object PAGEREF _Toc49853689 \h 40
6.9.1 Confining node object attributes PAGEREF _Toc49853690 \h 40
6.9.2 Confining node properties PAGEREF _Toc49853691 \h 40
6.9.3 Confining node object operations PAGEREF _Toc49853692 \h 40
6.10 Complex node object PAGEREF _Toc49853693 \h 40
6.10.1 Complex node object attributes PAGEREF _Toc49853694 \h 40
6.10.2 Complex node properties PAGEREF _Toc49853695 \h 40
6.10.3 Complex node object operations PAGEREF _Toc49853696 \h 40
6.11 Terminal object PAGEREF _Toc49853697 \h 41
6.11.1 Terminal object attributes PAGEREF _Toc49853698 \h 41
6.11.2 Terminal properties PAGEREF _Toc49853699 \h 41
6.11.3 Terminal object operations PAGEREF _Toc49853700 \h 41
6.12 Relationship object PAGEREF _Toc49853701 \h 41
6.12.1 Relationship object attributes PAGEREF _Toc49853702 \h 42
6.12.2 Relationship object operations PAGEREF _Toc49853703 \h 43
6.13 Terminal configuration object PAGEREF _Toc49853704 \h 43
6.13.1 Terminal configuration object attributes PAGEREF _Toc49853705
\h 43
6.13.2 Terminal configuration object operations PAGEREF _Toc49853706
\h 43
6.14 Connection object PAGEREF _Toc49853707 \h 43
6.14.1 Connection object attributes PAGEREF _Toc49853708 \h 43
6.14.2 Connection properties PAGEREF _Toc49853709 \h 43
6.14.3 Connection object operations PAGEREF _Toc49853710 \h 44
7 Implementing flow analysis PAGEREF _Toc49853711 \h 45
list of Figures
Page
TOC \h \z \c "Figure" HYPERLINK \l "_Toc49853539" Figure 1: Flow
integrity concern with complex networked process cells PAGEREF
_Toc49853539 \h 17
HYPERLINK \l "_Toc49853540" Figure 2: Flow Analysis conceptual view
PAGEREF _Toc49853540 \h 19
HYPERLINK \l "_Toc49853541" Figure 3: Free nodes unconnected by flow
vectors PAGEREF _Toc49853541 \h 20
HYPERLINK \l "_Toc49853542" Figure 4: Nodes and vectors making a path
PAGEREF _Toc49853542 \h 20
HYPERLINK \l "_Toc49853543" Figure 5: Process cell example 1
PAGEREF _Toc49853543 \h 21
HYPERLINK \l "_Toc49853544" Figure 6 : Nodes, terminals, connections
PAGEREF _Toc49853544 \h 22
HYPERLINK \l "_Toc49853545" Figure 7: Liquid/Gaseous nodes interface
PAGEREF _Toc49853545 \h 23
HYPERLINK \l "_Toc49853546" Figure 8: Directing nodes PAGEREF
_Toc49853546 \h 23
HYPERLINK \l "_Toc49853547" Figure 9: Ultimate directing node
breakdown : Flow breakers PAGEREF _Toc49853547 \h 24
HYPERLINK \l "_Toc49853548" Figure 10: Confining nodes PAGEREF
_Toc49853548 \h 24
HYPERLINK \l "_Toc49853549" Figure 11: Information propagation
PAGEREF _Toc49853549 \h 26
HYPERLINK \l "_Toc49853550" Figure 12: Higher level process cell
modularization PAGEREF _Toc49853550 \h 27
HYPERLINK \l "_Toc49853551" Figure 13: The whole plant as
interconnected nodes PAGEREF _Toc49853551 \h 28
HYPERLINK \l "_Toc49853552" Figure 14: Recursive Nodes - Generic
model PAGEREF _Toc49853552 \h 30
HYPERLINK \l "_Toc49853553" Figure 15: Object model PAGEREF
_Toc49853553 \h 32
HYPERLINK \l "_Toc49853554" Figure 16: Directing node control
PAGEREF _Toc49853554 \h 39
HYPERLINK \l "_Toc49853555" Figure 17 : Internal node relationships
PAGEREF _Toc49853555 \h 42
list of tables
TOC \h \z \c "Table" HYPERLINK \l "_Toc49853520" Table 1: Nodes
breakdown rules PAGEREF _Toc49853520 \h 29
HYPERLINK \l "_Toc49853521" Table 2: Directing nodes attachment rules
PAGEREF _Toc49853521 \h 29
HYPERLINK \l "_Toc49853522" Table 3: Property object attributes
PAGEREF _Toc49853522 \h 33
HYPERLINK \l "_Toc49853523" Table 4: Node object attributes PAGEREF
_Toc49853523 \h 34
HYPERLINK \l "_Toc49853524" Table 5: Flow properties PAGEREF
_Toc49853524 \h 35
HYPERLINK \l "_Toc49853525" Table 6: Material properties PAGEREF
_Toc49853525 \h 35
HYPERLINK \l "_Toc49853526" Table 7: Node object attributes PAGEREF
_Toc49853526 \h 37
HYPERLINK \l "_Toc49853527" Table 8: Node properties PAGEREF
_Toc49853527 \h 37
HYPERLINK \l "_Toc49853528" Table 9: Directing node object attributes
PAGEREF _Toc49853528 \h 38
HYPERLINK \l "_Toc49853529" Table 10: Directing node properties
PAGEREF _Toc49853529 \h 38
HYPERLINK \l "_Toc49853530" Table 11: Confining node object
attributes PAGEREF _Toc49853530 \h 40
HYPERLINK \l "_Toc49853531" Table 12: Confining node properties
PAGEREF _Toc49853531 \h 40
HYPERLINK \l "_Toc49853532" Table 13: Terminal object attributes
PAGEREF _Toc49853532 \h 41
HYPERLINK \l "_Toc49853533" Table 14: Terminal properties PAGEREF
_Toc49853533 \h 41
HYPERLINK \l "_Toc49853534" Table 15: Possible node relationships
PAGEREF _Toc49853534 \h 42
HYPERLINK \l "_Toc49853535" Table 16: Relationship object attributes
PAGEREF _Toc49853535 \h 42
HYPERLINK \l "_Toc49853536" Table 17: Terminal configuration object
attributes PAGEREF _Toc49853536 \h 43
HYPERLINK \l "_Toc49853537" Table 18: Connection object attributes
PAGEREF _Toc49853537 \h 43
HYPERLINK \l "_Toc49853538" Table 19: Terminal properties PAGEREF
_Toc49853538 \h 44
Introduction
Although ANSI/ISA-88.01-1995 standard helps a lot in clarifying batch
control, it can only be successfully implemented by experienced batch
specialists. First implementations are proven to be always difficult and
time consuming before taking all the benefits of S88 concepts.
Among difficulties, exception handling takes care of any situation that
is not expected in normal operation when their probability of occurrence
is above an acceptable level. It is often allocated as much as 80% of
the design effort, leading to a huge number of discrete interlocks to
prevent wrong operations.
The standard does not provide much information for the specification of
Control and Equipment modules boundaries. Many S88 implementation
reports raise the issue of Process Cell breakdown into its lower level
components (i.e. Units, Equipment Modules and Control modules) and
exception handling. From the ``Top-Down'' to the ``Bottom-Up'' through
the mixed approaches, each project involves user preferences through
specific, often inconsistent guidelines.
According to Spiro Georgakopoulos and Robert Price (see REF
_Ref536520284 \w \h \* MERGEFORMAT 2.2 REF _Ref536520291 \h \*
MERGEFORMAT Other documentation )
``S88.01 - LIMITATIONS AND SOLUTIONS
The S88.01 standard explicitly excludes offering any specific guidance
in the area of low level
decomposition. It expressly draws a line above the protective layer -
``total explanation of process
segmentation is beyond the scope of this standard''. At the same time,
the standard recognizes the difficulty and importance of decomposition
to the whole modeling exercise -``Effective subdivision of the process
cell into well defined equipment entities is a complex activity, highly
dependent on the specific environment in which the batch process
exists.''
A poor decomposition can be recognized by a high number of dangling
control modules that the batch server must monitor and manage. In
addition, methodologies which treat the protective layer separately from
the process result in a large number of interlocks that need to be
enabled or defeated with each phase. Either way, the modularity aspect
of S88 which promises so much is compromised in a tangle of ``special
cases''.
There is a clear need of more practical guidelines beyond the general
S88 concepts to build applications.
Flow analysis outcome is an efficient modularization that simplifies
modules interactions, improves operation safety and dramatically reduces
exception handling overhead. It may apply to any control models, however
this report considers its application within S88 models.
The purpose of the WBF Flow Analysis Working Group is to develop
guidelines based on current practices to complement S88 models to
enforce physical and equipment procedural model design.
Editor's note:
Not sure it corresponds to the current scope
This work is intended to help people from process design, operation and
process control communities to well understand these concepts and to
communicate together, producing robust and safe applications on a
consistent basis.
It should also help vendors to develop supporting tools based on
consensual concepts.
BATCH CONTROL
ISA-88 Modeling using Flow Analysis
Scope
This report focuses on design requirements for inherent actuators
interlocks based on flow analysis. It addresses :
Process cell equipment breakdown (typically at the Control Module level)
Exception handling at the process actuator level
Other subsequent reports may develop other aspects of flow analysis in
S88 control design.
The expected results will be an S88 compliant guideline to address
specific issues encountered in actual implementations of the standard.
The expected benefits are:
Control Modules breakdown consistency leading to a high level of
reusability
Improvement of operation safety
Easier Exception Handling
references
Normative references
The following normative documents contain provisions, which through
reference in this text, constitute provisions of this part of this
report. At the time of publication, the editions indicated were valid.
All normative documents are subject to revision, and parties to
agreements based on this part of this standard are encouraged to
investigate the possibility of applying the most recent editions of the
normative documents indicated below. Members of IEC and ISO maintain
registers of currently valid normative documents.
IEC60902:1987, Industrial-process measurement and control : Terms and
definitions
IEC61512-1:1997, ANSI/ISA-88.01-1995, Batch control- Part 1: Models and
terminology
IEC61512-2:2001, ANSI/ISA-88.00.02-2001, Batch control - Part 2: Data
Structures and Guidelines for Languages.
Note :
In this report, the ANSI/ISA-88 standard will be referred to as S88.
Other documentation
The following documents are related to existing flow-based
methodologies. Although the present report uses fundamental elements
from this documentation, it may not comply with the terminology and
features used or expressed in them. However, the reader may find helpful
information about the genesis of the methodology.
``Methodological guide for the analysis of multipurpose batch process
plants'' RHONE-POULENC N? 501/93.875 - GET 5/EM/519/97/1119 - GT ASTRID
``DELTA NODES Automated flows methodology'' JMR Conseils N?
JMR86/R01-2001_v3
``A Flow Stream Approach for Process Cell Modularization'' - By Francois
Lebourgeois (Rhone Poulenc), Jean Michel Rayon (JMR Conseil) and Jean
Vieille (Consultant) - Presented at the World Batch Forum Conference in
Atlantic City (NJ, USA) on 23/04/2000
``The Missing Link - A generic process control model'' - By Spiro
Georgakopoulos and Robert Price (Quemm Associates Pty Ltd) - Presented
at the 6th World Congress of Chemical Engineering in Melbourne,
Australia on 23-27 September 2001
BatchML XML schemas developed by the World Batch Forum.
Definitions
For the purposes of this part of this report, the following definitions
apply. All terms defined here are italicized in the text when their use
corresponds to the definition. Abbreviations are included in the
definitions. They are capitalized in the text.
Complex node
is made of several nodes of both directing and confining types.
Confining node
has the ability to contain the flow.
Connection
links nodes together through their terminals. It is not an equipment
entity (as to flanges assembled together, each flange being owned by its
corresponding node)
Directing node
has the ability to control the flow (direction or confinement).
Directing nodes support inherent interlocks that prevent erroneous
automatic or manual handling according the safety needs.
Equipment procedural element (EPE)
Equipment procedural element is extensively addressed in S88 part 2.
However, it is not formally defined in the current edition of S88.
Equipment procedural element is an element of the part of the S88
procedural model , which applies to equipment control. It can by either
a procedure, a unit procedure, an operation, a phase or any user defined
procedural entity. Its equivalent at the recipe side is the recipe
procedural element.
Flow
the material or energy content in a path, i.e. the stream of product or
energy that takes place within a set of equipment working together on it
Flow Analysis
a methodology based on an analytical review of processing equipment that
aims at modeling equipment entities in a way that allows generic
mechanisms to impose critical actuators to operate within specified
constraints.
It is safety-focused, providing self-immune environment against
automatic control and manual operation errors regarding material and
energy handling.
Flow breaker
a device that has the ability to break the flow. It can be part of a
directing node, part of a complex node, or an elementary directing node.
Node
a consistent equipment entity. It can correspond to any S88 equipment
entity (Control module, equipment module, unit, process cell...), but
would generally comply with Control Modules. It can be confining,
directing or complex (mixed and embedding other sublevel nodes)
Path
the collection of nodes assembled to perform a functionality provided by
an equipment procedural element. A path can support one or several
flows.
Terminal
is the physical interface of a node
Overview of Flow analysis
A constraints based modeling
Process equipment is selected and installed with a clear expectation of
the purpose it will serve in terms of physical and chemical processes it
is to encounter. A process modeling exercise must recognize those
constraints and incorporate them.
A critical constraint is the requirement that the material remains
confined within a specified part of the process equipment. The operating
context dynamically defines which part of the process equipment is
allocated to each executing process oriented functions. A key
performance measure of an operating process plant is how well material
is contained within the process.
In selecting the equipment a number of physical and safety constraints
are imposed, beyond which it cannot operate. In a plant as a whole,
additional constraints derived from the interaction of equipment come in
to play.
Finally, the product being processed will induce additional safety and
operational constraints.
These constraints can be categorized as follow:
Equipment constraints may be physical things like capacity, maximum
operating temperature, pressure, volume or flow. Or they may be a
chemical (material) constraint - a vessel must never process material
with pH less than 5. Or they may relate to hygienic status, etc.
This information is attached to the equipment
Product constraints include things such as maximum temperature, blending
compatibility.
This information is attached to the product
Relational constraints between equipment, between products or between
equipment and products. For example, possible connections between
equipment determine assembling constraints; 2 products may be
incompatible and shall never be in contact; a product may not be
processed by certain equipment...
Intrinsically safe operational vs conventional interlocking
The following simple example below illustrates how flow analysis impacts
on control system implementation and operational safety considering the
confinement control aspect.
This example shows the difficulties that have to be faced of when
dealing with flexible process cells to avoid cross contamination or
pollution by opening a valve which does not contribute to the intended
functionality (here, transferring product from T2 to T8).
Figure SEQ Figure \* ARABIC 1 : Flow integrity concern with complex
networked process cells
Such process layout imposes to implement a protective layer, which must
be effective when the operator manually controls the plant as well as in
automated operation to avoid errors when controlling the different
circuits.
In order to protect the circuit ``A'' transferring product from T2 to
T8, valves Vo1a, Vo2b, Vo3a, Vo4a, Vi5a, Vi6a, Vi7a, Vi8b are to be
forced to their closed position.
A conventional approach begins by a very detailed risk analysis and ends
by
1) a huge list of interlocks such as :
IF PHASE ``TRANSFER T2->T8'' IS ACTIVE THEN
Vo1a FORCED CLOSE
Vo2b FORCED CLOSE
...
2) an equivalent set of starting conditions for phases:
INITIALIZING PHASE ``TRANSFER T2->T8''
CHECK Vo1a CLOSED
CHECK Vo2b CLOSED
...
3) coordination control to suspend the phase if one of these valves fail
This extensive analysis, specification and coding must be performed for
each combination.
Conventional approaches propose to simplify this design by interlocking
phases instead of valves. However, this method constrains the operation
flexibility, and does not prevent a wrong manual operation. Initial
conditions / actuators failures are to be controlled anyway.
As an example, the following values were noted in a typical multipurpose
chemical process cell:
Number of units / shared equipment modules: 34
Number of phases: 180
Number of instruments: 600
Number of interlocks: 1700
Number of interlocks combinations: 13000
Flow analysis provides intrinsic, extensive interlocking for providing a
better level of circuit integrity control than these numerous interlocks
without any additional coding.
Conventional interlocking seldom reaches a high level of safety because
of its exponential complexity. These interlocks may be dramatically
affected when adding new equipment or defining new phases. (The number
of combinations corresponds to the number of cases that are to be
considered when adding/modifying equipment or phases.)
Smart designers implement matrices to define these interlocks. Coding
becomes better, however other issues remain.
Finally, the validation effort is directly affected by the number of
checks to ensure the system will behave as designed. Replacing discrete
interlocks by a single validated FA mechanism dramatically reduces this
effort.
Production Plant from Flow Analysis point of view
Flow analysis is directed at looking at physical (people, material,
energy) flows. It does not address financial, or information flows.
A production plant uses, moves, acts on 2 basic flows:
Material flow
Energy flow
... using suitable equipment
Liquid material: Pumps, valves, pipes, vessels
Solid or Packed material: conveyors, lifts
Powdery material: roots, pipes, conveyors
Electrical energy: cables, bus bars, transformers, breakers
Thermal Energy (i.e. steam): pipes, exchangers...
Mechanical energy: agitators
...
... performing specific or more complex process oriented functionality
Charging, Emptying, Filling, Distillation, Filtering
Heating, stirring,
...
These actions
may have an implicit (i.e. charge a vessel, which end when the requested
quantity is obtained) or an explicit ending (heating, stirring... which
run forever until they are requested to stop).
may act on a single flow (charge, stirring), on several flows (in-line
mixing)
may use one flow to act on another one (heating)
Any production system (i.e. a process cell) can be considered as a set
of ``closed sections'' regarding the different material or energy flows
that can occur into it (e.g. reactors, filters, pump sets). These closed
sections are bounded by flow breakers (e.g. valves), which control their
linkage with other sections.
Note :
Some parts of the production system cannot be considered as closed
locally, but rather as infinite capacities that supply or consume
product or energy. They represent Process Cell connections to raw or
finished material, ancillary fluid or utilities (Sources and Sinks on
the diagram).
Whatever is the part of the plant to be considered, any production
system can be viewed as follow:
Figure SEQ Figure \* ARABIC 2 : Flow Analysis conceptual view
The considered part of the plant (the studied production system) appears
as a set of material and energy networks:
Sources and sinks are the connection points that limit the scope of the
analysis
Nodes are the places were material or energy is transformed, stored,
directed. They are actual equipment such as vessels, reactors,
transformers, exchangers, pipes, valves, pumps, conveyors...
Flow vectors indicates how the pieces of equipment are actually
connected. The connections established by flow vectors define the actual
plant layout. It may be fixed, but it may also be dynamically arranged
for the purpose of the actual product processing requirements. The
figure below shows free nodes that are not yet connected: equipment is
available, but disconnected (imagine it lies disconnected on the
workshop floor) and unable to fulfill any process oriented functionality
(no material nor energy can be processed). It is not presumed to be
assembled in a particular shape until it is used to make something. Flow
vectors do not currently connect the equipment. They are waiting for any
future usage.
Figure SEQ Figure \* ARABIC 3 : Free nodes unconnected by flow
vectors
A process functionality requires the support of a path by allocating
several adjacent nodes (connected by flow vectors). The figure below
shows the path P1 assembled to perform a process functionality using
nodes A, B, F.
Figure SEQ Figure \* ARABIC 4 : Nodes and vectors making a path
Modeling principles and terminology
Basic principles
Analyzing flows in a process cell may be done at different level:
The connection analysis reveals how equipment is actually linked
depending of flow breakers and connections statuses
The static analysis concentrates on motionless flows, in order to check
if static conditions allows the flow to occur (i.e. to open the
corresponding flow breaker). It gives up once an actual flow is
established.
The dynamic analysis focused on operating flows to compare the actual
performance to internal models in order to detect abnormal deviations
and to predict expecting physical conditions.
This report focuses on operation safety, checking the conditions before
the flow occurs to allow a flow breaker to open or a directing node to
operate as requested. It is based on connection and static analysis.
Modeling a process cell
The following figure shows an example of a simple process cell from
which basic concepts, terminology, and modeling rules can be presented.
Figure SEQ Figure \* ARABIC 5 : Process cell example 1
This process cell includes the following equipment:
3 main processing equipment (CN1, CN4, CN5) that could be qualified as
units following S88 definitions.
2 in-line processing equipment (CN2, CN3) that could be qualified as
equipment modules following S88 definitions.
valves or group of valves (DN1-DN7) that could be qualified as control
modules following S88 definitions. These valves are represented as
no-way symbols but they can be removable pipes and/or blind flanges as
well.
Nodes, Terminals and Connections
Figure SEQ Figure \* ARABIC 6 : Nodes, terminals, connections
All identified pieces of equipment are nodes which:
Represent the recipient (the physical equipment) and its content (the
product or energy inside)
Have an informational interface provided by
properties attached to the recipient (equipment statuses and capability,
product id...)
properties attached to the content (physical and chemical conditions)
May have a behavioral interface provided by methods or functionalities
that can be invoked by other entities
Have a physical interface provided by terminals, which
hold specific properties and statuses,
can be linked to together by connections.
Node categories
Nodes can be categorized to address generic set of constraints and
specific modeling rules. For example Astrid / Delta Nodes identifies the
following categories:
Energy
Controls energy through the equipment (Reactor heating jacket, energy
side of an exchanger, vacuum system, agitator)
Utility
Corresponds to common resources delivering or receiving fluids or energy
to or from the process cell. It has no direct contact with the product
being manufactured. It is generally shared by several Units or Process
Cells (Compressed Air supply, N2 distribution, waste collection, venting
system...)
Material
Participates to the product transformation or movement (Pipe, tank,
reactor, transfer line, conveyor, product side of an exchanger...)
Sub types of material can be defined. This can help to distinguish
different flows through the same equipment:
Solid
Liquid
Gaseous
Powdery
...
For example, the liquid side (lower part) of a reactor is member of the
``Material/liquid'' node that can hold the product, while the gaseous
upper part of the reactor is member of the ``Material/gaseous'' node
controlling the pressurization. This allows dealing with 2-chemical
phases equipment in order to allow parallel control using separate
equipment procedural elements. Exclusive node allocation does not
compromise functional flexibility.
Figure SEQ Figure \* ARABIC 7 : Liquid/Gaseous nodes interface
Node types
There are 3 types of nodes:
Confining nodes which contain the flow
Directing nodes which control the flow by their embedded flow breakers
Complex nodes which combines both confining and directing nodes
Directing nodes and flow breakers
Directing nodes (DN) have the ability to control the flow (breaking,
directing). They generally cannot retain the flow inside themselves.
Figure SEQ Figure \* ARABIC 8 : Directing nodes
They embed flow breakers that actually control the flow. Flow breaker
can be the lowest possible breakdown of directing nodes. The following
figure develops the previous one into elementary directing nodes
encompassing single, simple flow breakers.
Figure SEQ Figure \* ARABIC 9 : Ultimate directing node breakdown :
Flow breakers
Depending on the user's choice, directing nodes can be defined at the
appropriate breakdown level ( REF _Ref48731625 \h Figure 8 versus
REF _Ref48731630 \h Figure 9 ).
Several directing nodes can be linked together to form a more complex
flow control equipment.
Flow breaker can be controlled remotely or manually. They are devices
such as
one-way valves, multi-ways valves
liquid / gas interface
feeder or conveyor motor
removable pipes, blind flanges or plugs
doors or windows,
traffic lights or mobile bridges
...
Confining nodes (CN)
Confining nodes do not control the flow, but can contain it. They do not
embed flow breakers, though they can influence the flow by embedded
devices such as pumps or control valves.
All terminals of a confining node are ``statically equipotent'' i.e. if
the flow doesn't move and the node is not running any material or energy
transformer, all physical conditions are the same for all connections
(static analysis). This is generally not completely true: hydrostatic
weight can influence the pressure depending of the altitude of the
terminal. Also, the temperature can be different at different places and
different times. The REF _Ref49748603 \h Figure 10 shows 2 different
examples.
Figure SEQ Figure \* ARABIC 10 : Confining nodes
Confining nodes can be combined into a bigger confining node.
Terminals
Terminals represent the physical interface of nodes. Nodes can be
connected to each other by their terminals linked by connections.
Terminals can be:
Inputs, if they can only receive an incoming flow
Outputs, if they can only send outgoing flow
Bi-directional if they can send or receive flow either.
Terminals can have other characteristics such as:
type and size of connection mean (flange)
Physical limits (max. pressure and temperature
...
Directing nodes terminals have a particular ``Flow'' attribute that
control the flow occurrence. This attribute has 2 values:
Open
Close
The ``close'' state means the terminal is a dead end. The flow does not
go further. Flow breakers that are responsible for this state look at
the terminal information to accept an opening order.
The ``open'' state means the directing nodes has established a way out
for the flow toward another node, and there is at least one way toward a
confining node (i.e. the flow can occur between 2 confining nodes).
Terminals are fundamental in referencing information relative to:
the equipment they are attached to
the product which flows through them: Product related information is
acquired from the terminals to terminals relationships attached to the
node for output terminals, or from other terminals through its
connection to outside equipment for inputs.
Finally, flow breakers will operate under safe conditions that are
assessed by looking at the information available at its terminals
The REF _Ref49679900 \h Figure 11 below shows information
propagation through terminals. Flow breaker B1 is supposed to be closed.
Because the ultimate goal is to protect operation from erroneously
opening a flow breaker, there is no point to consider information
propagation between communicating nodes (static analysis). We only need
to propagate information at the flow breaker terminals from the
corresponding confining nodes. Once the flow breaker has been opened,
the resulting flow is no longer considered, and the terminal information
is not requested anymore.
Figure SEQ Figure \* ARABIC 11 : Information propagation
Connections
Nodes can be connected to each other using connections that link
terminals to each other.
In many cases, the process cell layout and its connections are fixed.
In other cases, connections are built at run time depending of the
process to be executed.
Connections represent the fact that 2 physical entities (terminals) are
purposely and adequately attached to each other. They aren't physical
objects:
A pipe which links 2 equipment is part of the confining node it is
attached to (the side which is connected without valve).
A removable pipe used to connect 2 pieces of equipment, is considered as
a directing node with 2 terminals.
Connections shall fulfill the following requirements:
All confining nodes terminals are to be connected to either another
directing node. This allows the process to containing the flow, because
it guarantees that it is bounded by flow breakers.
Connections can only link compatible terminals:
Terminals can be input, output or bi-directional
An input terminal can be connected to only one output terminals
An output terminal can be connected to several input terminals
A bi-directional terminal has to be properly connected according its
current use
Connected terminals shall have compatible characteristics
The main role of a connection is to link terminals in order to let the
nodes communicate the actual process conditions downstream the flow.
Complex nodes
Grouping nodes together
In the previous example the process cell was broken down in elementary
pieces were elementary flows can be revealed.
The concept of nodes is flexible and can describe any physical
hierarchy. For example, the following figure represents the same process
cell, but identifies ``macro nodes'', which are consistent with the
mechanical engineering (each node corresponds to separately engineered
modules, or skids delivered by different subcontractors)
Figure SEQ Figure \* ARABIC 12 : Higher level process cell
modularization
Complex nodes do not allow the best flexible and accurate flow
management (for example to deal with bi-directional connections),
because the relationships between terminals are too complex to be
efficiently modeled. However, if bounding flow breakers are identified
as nodes, it becomes possible to control incoming and outgoing flows.
This may be useful when integrating packages.
Complex nodes are obtained by increasing the modularization granularity
(see REF _Ref49746912 \r \h 5.8.2 ). It dramatically simplifies the
control system implementation by reducing the number of modules.
At the highest level, a plant may be analyzed the same way :
Figure SEQ Figure \* ARABIC 13 : The whole plant as interconnected
nodes
Nodes Breakdown principles
Material or energy flows are supported by Paths. A node represents a
part of a Path, acting as a container of material or energy. The
breakdown of the facility into nodes is made by applying the following
rules:
Breakdown rules (BK) give guidance to split the process cell in nodes.
Strictly applied, these rules leads to the most refined breakdown and
results in the highest number of nodes
Aggregation rules (AG) give guidance to possibly reduce the number of
nodes (end the subsequent control system complexity) in grouping
equipment entities that form a set of equipment, which works
independently.
The following table presents the rules that can be applied at the lowest
breakdown level (the nodes the control system will have to deal with,
regardless they are combined together to form higher level entities).
Rule Type BK AG Description, Comments
Closed (confined) section Confining X
A node is bounded by flow breakers
Example, this rule is mentally applied to piped installation by
``blowing'' in any part of the cell while flow breakers are operating
(valves are closed). The identified node is the under-pressure part of
the cell.
Flexibility
All
X When grouping nodes, the resulting diminished flexibility shall be
challenged by checking if different parts of the same node could be used
by different phases at the same time.
Inter-CMs Constraints
All
X Aggregation releases constraints enforcement between aggregated nodes.
A coarse breakdown may lead to lose the benefit of secured operation,
which is basically the intent of the Flow analysis.
Reusability All
X Looking for reusability suggests to isolating equipment subsets that
are fully standards and match the actual equipment once assembled.
The number of different nodes increases with aggregation. The designer
shall compromise between reusability and the number of nodes.
Virtuality
Confining X
It is sometime difficult to identify the equipment the node represents.
That could be the case for controlled physical measurement that are not
part of any mechanical part of the equipment acting on one or several
actuators. (Example: a remote vision system)
Table SEQ Table \* ARABIC 1 : Nodes breakdown rules
Grouping directing and confining nodes
It may be convenient to group confining and directing nodes in complex
nodes that can be consistently managed as autonomous equipment entities
(Control Modules). As a side result, directing nodes are seldom found as
separate entities. An outstanding drawback of this grouping is that it
cannot comply with bi-directional and merging flows.
The resulting complex nodes forms the S88 control module layer or the
Astrid / Delta Node Resource layer. The following table proposes the
rules to attach a particular directing node to the appropriate confining
node.
Attachment Rule Node Type Comment
Upstream driven Material
Sky This rule applies to finite nodes corresponding to process related
flows.
The directing node is attached to the upstream confining node
considering the flow direction.
Process side driven Energy Utility This rule applies to nodes that
control a shared utility to the process.
The directing node is attached to the process side confining node
whatever the direction of the utility fluid is.
Table SEQ Table \* ARABIC 2 : Directing nodes attachment rules
Generic model
Nodes are connected to each other, and embedded within higher-level
nodes.
Depending on the primary breakdown, nodes can be elementary confining or
directing nodes, as well as combined directing nodes or complex nodes.
Nodes hierarchy and internal relationship is modeled until the
lowest-level defined nodes. At the lowest level, it becomes a black box
with terminal internal relationships.
Figure SEQ Figure \* ARABIC 14 : Recursive Nodes - Generic model
Mapping FA entities on S88 equipment entities
As shown above, any physical entity can be interpreted as a node. All
S88 equipment entities physical can be represented as nodes whatever is
their level in the S88 physical model.
The application field of the flow analysis is widely open. However, for
the purpose of this report, we will concentrate at the lowest physical
level where the flows are actually controlled, in order to support the
protective layer that will secure the actuator operation.
Typically, the finest nodes breakdown will correspond to Control
Modules.
Functional view: Equipment Procedural Entities
In order to make a product, a production system must:
Provide the required basic process functions its equipment is capable of
doing (EPE, equipment procedural element). In S88 EPEs can be Phases,
Operations, Unit Procedures, Procedures.
Orchestrate these EPEs following the product processing rules (Recipes,
made of Recipe Procedural Elements or RPEs)
This is the S88 concept of separation between equipment control and
process control. flow analysis may interprets EPEs as follow (the term
node is replaced by control module :
In order to execute a specific EPE, the needed control modules
(initially considered lying dismantled on the floor) need to be
assembled to establish a path. The path represents the physical extent
of its execution and is exclusively allocated to its initiating EPE.
An EPE can execute only if its path can be initialized i.e. the
corresponding Control Modules are available to its use - not currently
used by another EPE allocating an overlapping path or disabled for
whatever reason - and the necessary connections are feasible.
A path may enable one or more flows. Any combination of flows in a path
is allowed from the control point of view; however, it should be
consistent with the mechanical reality (connection check).
As stated in the scope section, this report only concentrates on the
protective layer and basic control. The functional (procedural) aspects
will not be further discussed here.
Object model and attributes
Overview
When dealing with an actual application, designers may take benefit of
flow analysis to help modeling and implementation. Examples of
applications examples are given in annexes.
This section presents the detailed FA elements in order to facilitate
design and implementation.
Control Module Object Model
Figure SEQ Figure \* ARABIC 15 : Object model
S88 Objects
The object model starts by the S88 equipment entity, which is
specialized into control module type, equipment module type, unit type
or process cell type, as well as any user defined level (extensibility
of S88 models).
Whatever they are, S88 entities may be associated to nodes.
Note : Another option could have been to merge S88 Equipment Entity and
Node concepts, which are pretty similar. However, such an approach
would have been more complex because types of nodes would have
overlapped with S88 physical level. It also allow flow analysis concept
to be used with different concepts than S88.
The corresponding objects are not defined in this report:
S88_EqptEntity
S88_ControlModule
S88_EquipmentModule
S88_Unit
S88_ProcessCell
S88_UserEqptEntity
S88_EPE
S88_Procedure
S88_UnitProcedure
S88_Operation
S88_Phase
S88_UserEPE
Attributes and Properties objects
In the model each object has a set of generic attributes. These
attributes may be optional or required.
Note :
Data types are not defined, interoperability is not address in this
report (and shall not be a concern within the scope of this report).
Properties are process related information. All property objects are
based on the same meta-class
Property meta-class object attributes
Attribute Name Description Examples
ID An identification of a property of the associated object.
Description Contains additional information and descriptions of the
property.
UOM The unit of measure of the associated property value, if
applicable.
DesignValue Design or typical value, set of values, or range of the
property.
CurrentValue Current value of the property
MaxValue Maximum value of the property
MinValue Minimum value of the property
Table SEQ Table \* ARABIC 3 : Property object attributes
This meta-class defines the design information (design, maximum and
minimum values), as well as the current value of the same information.
This is the basic information to check flow consistency by comparing
design and actual values:
design value of the node at the downstream side of a flow breaker
against actual value of the node at the upstream side of the flow
breaker
Actual and design values within the same equipment
The following classes are based on this meta-class:
Flow_Property
Material_Property
Node_Property
DirectingNode_Property
ConfiningNode_Property
Connection_Property
Terminal_Property
Properties can also be used for additional information as a mean to
extend the model without compromising its consistency and easily
identify user / implementation specifics.
Path object
The path establishes the relationship between a flow and the nodes.
Editor's note:
Do we need the path object?
Flow object
A flow shall correspond to an S88 equipment procedural entity, which is
the S88 equipment process oriented functionality. (Astrid / Delta Nodes
gives use both ``Functions'' and ``Flow'' terms do designate the
functionality and the flow which is built to uniquely support it).
This object is presented on the model, because it holds material
requirement properties, which are needed to control the proper
conditions of the allocated nodes.
Nodes are actually acquired by flows at run-time. If the acquired node
is made of lower level nodes, the owning flow information is propagated
downstream in the hierarchy, allowing any node to control its current
conditions against material requirements.
In actual implementations, several EPEs may run together to form a given
flow. It is the case when a TRANSFER phase is synchronized with a
RECEIVE phase on 2 different units. This is represented by a flow
containing 2 lower-level flows, each of them being associated to the
corresponding phase.
Flow is a recursive structure, and each flow may be related to 0 or
several EPE.
Flow object attributes
Node object attributes
Attribute Name Description Examples
ID An identification of the object.
Description Contains additional information and descriptions of the
object.
S88_ProceduralLevel Specifies the S88 EPE procedural hierarchy level
Possible values are:
Procedure
Unit procedure
Operation
Phase
BatchID Batch identifier.
Product ID Product identifier
OperatorID Operator Identifier.
ActivationStatus Activation status of the flow. Possible values are:
IDLE
RUNNING
STOPPED
HOLD
FAULT
ActivationSubStatus Additional identifier, documents the
ActivationStatus. (Application specific values)
It identifies specific running behaviors or mitigation methods
Table SEQ Table \* ARABIC 4 : Node object attributes
Flow properties
To be completed
Example of flow properties
Property Name Description Examples
Table SEQ Table \* ARABIC 5 : Flow properties
Material requirement properties
Material requirement information is attached to the flow because this
information is defined in the recipe and has to be downloaded into
EPEs/flows at run-time. It propagates from the Recipe Execution domain
to the operating EPE/flow and finally to the acting control modules to
feed flow control interlocks.
Example of material properties
Property Name Description Examples
Quantity Quantity of product to be processed
Specific mass
SizeL
SizeW
FlowRate Required flow
Temperature Required Temperature
Pressure Required pressure
PH Required PH
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 6 : Material properties
Flow object operations
Any flow can have incorporated operations that can be invoked for
performing procedural control as EPEs.
There are no specifics regarding flow analysis regarding procedural
control.
Node object
Types of nodes
Nodes can be specialized in 2 types: directing nodes, confining nodes.
Node structure is recursive; a node can be made of other nodes:
Directing nodes can content other directing nodes. At the last level,
they content flow breakers
Confining nodes can content other confining nodes
A complex node is made of both type of nodes
Information attached to the node (attributes or properties) is mainly
equipment related.
Node object attributes
Node object attributes
Attribute Name Description Examples
ID An identification of the object.
Description Contains additional information and descriptions of the
object.
S88_EqptEntity Corresponding S88 equipment entity
S88_EqptLevel Specifies the S88 physical hierarchy level. Possible
values are:
Control Module,
Equipment module,
Unit,
Process Cell
ContainedIn Node this node is contained in
Type Type of the node.
The complex type can be self-specified if the node contains both type of
nodes or a complex node.
It has to be specified if the breakdown does not model the node
components. Possible values are:
Confining
Directing
Complex
Category Category of the node.
Other values can be defined in properties Possible values are:
Material/Powdery
Material/Liquid
Material/Solid
Material/Gaseous
Energy
Utility
BatchID Batch identifier.
It may be set by the owning EPE and shall propagate downstream in the
node hierarchy
It may by set by the directing nodes terminals and shall propagate
upstream in the node hierarchy. Multiple batch identifiers may result in
flow merging depending on the node composition and equipment usage
ProductID Identifier of the last product the node contained
FlowID The flow identifier is set by the acquiring EPE.
It propagates downstream in the node hierarchy.
OperatorID Operator Identifier.
It is set by the owning EPE
It propagates downstream in the node hierarchy
ActivationStatus Activation status of the node. Possible values are:
STOPPED
RUNNING
FAULT
ActivationSubStatus Additional identifier, documents the
ActivationStatus. (Application specific values)
It identifies specific running behaviors or mitigation methods
OperationalStatus Status of the current operational conditions Possible
values are:
Normal operation
Direct manual operation
Broken down
Under maintenance
Repaired
SanitaryStatus Cleanness, sterility, sanitary Status. Possible values
are:
clean
contaminated
sterile
unknown
Product
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 7 : Node object attributes
These attributes apply to any node whatever is its type.
Node properties
Node properties include the physico-chemical information of the
equipment: are configured at the engineering level providing additional,
application specific information that describes:
Example of node properties
Property Name Description Examples
Capacity capacity of the equipment
Weight
Level
Volume
DimensionL
DimensionW
Flow Flow of the equipment
Temperature Temperature
Pressure
PH
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 8 : Node properties
Node object operations
Any node can have incorporated operations that can be invoked for
performing elementary actions.
There are no specifics regarding flow analysis at this level (however,
directing nodes have specifics regarding flow control)
Directing Node object
Directing node object attributes
Directing node object attributes are specific information about this
type of nodes
Directing_Node object attributes
Attribute Name Description Possible values
OperationMode The mode of operation is the way the device is controlled.
Unlike most methods, flow analysis is concerned by all actuators
regardless they are connected to the control system or not.
Possible values:
Handled (driven by the operator - no connection with the control system)
Ex:A blind flange
Controlled (driven by the control system). Ex: actuated on-off valve
Virtual (there are no corresponding device to control). Ex: a glass
fiber can be broken at the outlet of the glass oven, corresponding to a
``virtual'' flow breaker
...
Table SEQ Table \* ARABIC 9 : Directing node object attributes
Directing node properties
To be completed
Example of directing node properties
Property Name Description Examples
Table SEQ Table \* ARABIC 10 : Directing node properties
Directing node operations
Directing nodes actually controls the flow. It gets information on
conditions at its terminals and takes the appropriate protecting
decision depending of them.
The REF _Ref49767332 \h Figure 16 shows the different control a
directing node is under. Flow control is actually part of the directing
node. It acts as an interlock between automatic/manual control and the
actuators.
Figure SEQ Figure \* ARABIC 16 : Directing node control
Directing nodes support the flow analysis safety layer. This safety
layer act as an interlock between automatic and manual control, and the
actuators within the node. They perform the following flow control
operations:
Set the direction
Basic control that acts on flow breakers and other actuators
Before establishing a flow
Control the equipment compatibility
Check for the invoked terminal relationship if the ``open'' terminals
have compatible statuses with terminals of the connected nodes (a
``PayReceive'' terminal shall be connected to either a ``MaySend'' or a
``MaySendOrReceive'' terminal
Control the flow integrity
Check if the nodes that will be linked are part of the same flow
Control the product-process / equipment compatibility
Check if the process conditions of the nodes that will be linked are
compatible with the equipment capabilities (ex: maximum temperature) and
status (ex: clean)
Control the product-process compatibility
Check if the products that will be mixed are compatible
When the flow is estblished
Control the process conditions against material requirements
Check if the operating conditions are compatible with the material
requirements
To be developed
Confining node object
Confining node object attributes
To be completed
Confining_Node object attributes
Attribute Name Description Examples
...
Table SEQ Table \* ARABIC 11 : Confining node object attributes
Confining node properties
To be completed
Example of directing node properties
Property Name Description Examples
Table SEQ Table \* ARABIC 12 : Confining node properties
Confining node object operations
To be completed
Complex node object
To be completed
Complex node object attributes
To be completed
Complex node properties
Complex nodes don't have specific properties. They can be either
directing or confining nodes properties.
Complex node object operations
To be completed
Terminal object
Terminal object attributes
Terminal object attributes
Attribute Name Description Examples
ID An identification of the object.
TerminalStatus Status of the terminal regarding the flow that
determines if the terminal is or not an end of the flow. An open
terminal indicates that the node is part of the flow, but not the last.
A close terminal indicates this node is an end of the flow. Possible
values are:
Open
Close
FlowStatus Status of the terminal regarding the flow. Possible values
for a closed terminal:
MaySend
MayReceive
MaySendOrReceive
Possible values for an open terminal:
Receiving
Sending
...
Table SEQ Table \* ARABIC 13 : Terminal object attributes
Terminal properties
To be completed
Example of terminal properties
Property Name Description Examples
Table SEQ Table \* ARABIC 14 : Terminal properties
Terminal object operations
To be completed
Relationship object
Relationships object defines the possible ways through the node.
These relationships are normally associated with / activated by node
operations, which set the different flow breakers (actuators) patterns.
At least one relationship shall be defined for each node.
Relationship may be active or inactive (at run-time).
Active relationships determine all actual node internal connections
between its terminals.
If no relationships are active, default relationship apply .
Several relationships may be active at the same time. That means that
several separated flows All relationships sharing at least 1 terminal
are all connected together.
Example:
Figure SEQ Figure \* ARABIC 17 : Internal node relationships
The following table represents all possible Relationships:
Terminal 1 Terminal 2 Terminal 3 Terminal 4 Terminal 5 Terminal 6
RelationShip 1
RelationShip 2
RelationShip 3
RelationShip 4
RelationShip 5
RelationShip 6
RelationShip 7
RelationShip 8
Table SEQ Table \* ARABIC 15 : Possible node relationships
For example, relationship 1 lets communicate terminal 1 and 4
Relationship object attributes
Editor's note
The model only consider simplistic relationships between terminals. More
complex relationships regarding physical information transformation
(flow, temperature, pressure...) are not taken into account. Is that a
problem?
Relationship object attributes
Attribute Name Description Examples
ID An identification of the object.
ActiveStatus Flag for the active relationship.
Several relationship can be active at the same time Possible values:
True
False
DefaultRelation Identifies the relationship that is enable when no
relationships are invoked (i.e. the ActivationStatus of the node is
``stopped'', or if the node is not controlled)
Several relationship can be default Possible values are
True
False
Table SEQ Table \* ARABIC 16 : Relationship object attributes
Relationship object operations
To be completed
Terminal configuration object
Terminal configuration set the attributes to all terminals for each
identified relationship. The attachment of terminals to relationships
must be more
Terminal configuration object attributes
Terminal configuration object attributes
Attribute Name Description Examples
TerminalID Identification of the terminal
TerminalStatus Set the corresponding terminal status.
All unused / blind terminals are set to ``Close''. Other are open
Possible values are:
Open
Close
FlowStatus Set the terminal ability regarding the direction of the flow
Possible are:
MaySend
MayReceive
MaySendOrReceive
Table SEQ Table \* ARABIC 17 : Terminal configuration object
attributes
Terminal configuration object operations
To be completed
Connection object
Connection objects defines links between nodes. It tells a terminal
which other terminals from external nodes are connected to it.
I allows the directing node to know the actual conditions in front of
each closed terminal, in order to check flow consistency and authorize
the corresponding flow breaker to operate.
Connection object attributes
Connection object attributes
Attribute Name Description Examples
ID An identification of the object.
Terminal1 First terminal the connection links
Terminal2 Second terminal the connection links
Table SEQ Table \* ARABIC 18 : Connection object attributes
Connection properties
To be completed
Example of connection properties
Property Name Description Examples
Table SEQ Table \* ARABIC 19 : Terminal properties
Connection object operations
To be completed
Implementing flow analysis
This section provides guidance in order to facilitate FA implementation
in control systems.
To be completed.
Editor's note:
Shall include an actual example and possibly its implementation.
Shall address the possible overhead when implementing the full
methodology
Shall discuss the location of all information attached to the objects
(within the PLC/Controller, from an external data-base...) While I
thought it was a design / integration only issue, several comments
revealed that it is already a concern at our conceptual level
Shall discuss Internal exception handling
Page PAGE 11 / NUMPAGES 45 DATE \@ "dd/MM/yyyy" 28/08/2003
FILENAME \* MERGEFORMAT WBF-WG-FA_Draft3.doc
Draft Technical Report
WBF-WG ``Flow Analysis''
ISA-88 Modeling using Flow Analysis
Draft 3 - September 2003
This document is a draft that represents work being done by a WBF
Working Group
WBF grants permission to anyone to reproduce and distribute copies of
this WBF draft, in whole or in part, but only for the following purposes
and only as long as the recipient is not charged any fee for the copy
(nor may the copy be included as part of a package with other materials
or presentations for which a fee is charged):
1. Review of and comment on the draft standard;
2. Provide to others for review and comment;
3. Promotion of the WG work; or
4. Informing and educating others about the WG.
In addition, all copies must reproduce a copyright notice as follows:
(c) Copyright 2001 WBF. All rights reserved. Reproduced and distributed
with permission of WBF.
WBF reserves all other rights to the draft. Any other reproduction or
distribution without the prior written consent of WBF is prohibited.
The reader is cautioned that this document has not been approved and
cannot be presumed to reflect the position of WBF or any other
committee, society, or group. Although every effort has been made to
ensure accuracy, neither WBF, members of WG, nor their employers shall
be held liable for errors or limitations.
Yellow highlighting: under construction
Blue highlighting: question marks, editor's notes
WBF-WG_FA Draft on Flow Analysis
Copyright (c) 2001 by WBF. All rights reserved. Not for resale.
Printed in the United States of America
World Batch Forum
107 S. Southgate Drive
Chandler, Arizona 85226
Phone: 480-893-8803 Fax: 480.893.7775
E-mail: deann@kc-a.com
Preface
WBF working groups provide an unbiased means for the investigation and
development of work items of interest to the members. People of like
interests meet (in person or electronically) in order to delve into
specific topics. Although the topics addressed will be determined by
each working group possible topics are:
XML based batch data exchange formats
Exception handling
Continuation or publication of EBF working group results
Process plant analysis based on ISA-88
Procedure Function Chart examples
Good practices
Benchmarks
While the WBF will own the copyright to all WBF Working Group Reports,
all working group members are given royalty free use of the WBF Working
Group Reports for personal and professional purposes. This includes use
by the employers of working group members, to use work products of the
working group, including any work published by the working group.
This draft technical report has been issued by the World Batch Forum
(WBF), Working Group ``Flow Analysis''
The following served as members of this group:
Email Name Company Country
HYPERLINK "mailto:a-smith@its-ltd.co.uk" a-smith@its-ltd.co.uk
Anthony Smith INDUSTRIAL TECHNOLOGY LTD UK
HYPERLINK "mailto:alain.bosatelli@eu.rhodia.com"
alain.bosatelli@eu.rhodia.com Alain Bosatelli RHODIA FR
HYPERLINK "mailto:alfonso.sancho@honeywell.com"
alfonso.sancho@honeywell.com Alfonso Sancho HONEYWELL
HYPERLINK "mailto:bernard.cubizolles@isa-france.org"
bernard.cubizolles@isa-france.org Bernard Cubizolles ASOPHIA FR
HYPERLINK "mailto:bertrand.ricque@euraltech.fr"
bertrand.ricque@euraltech.fr Bertrand Ricque EURALTECH FR
HYPERLINK "mailto:dbrick@aegiscorp.com" dbrick@aegiscorp.com D.
Brick AEGIS ANALYTICAL US
HYPERLINK "mailto:dclermon@lu.danone.com" dclermon@lu.danone.com
Dominique Clermont DANONE FR
HYPERLINK "mailto:djoannes@danonefr.danone.com"
djoannes@danonefr.danone.com Didier Joannes DANONE FR
HYPERLINK "mailto:dror@specsoft-pfs.com" dror@specsoft-pfs.com Dror
Eyal SPEC SOFT IS
HYPERLINK "mailto:Ed.Lynch@pfizer.com" Ed.Lynch@pfizer.com Ed Lynch
PFIZER US
HYPERLINK "mailto:emerson@dallas.yca.com" emerson@dallas.yca.com
Dave Emerson YOKOGAWA US
HYPERLINK "mailto:emol@starren.nl" emol@starren.nl Elbert Mol
STARREN NL
HYPERLINK "mailto:eric_vitte@mail.schneider.fr"
eric_vitte@mail.schneider.fr Eric Vitte SCHNEIDER ELECTRIC FR
HYPERLINK "mailto:etsmrb@aol.com" etsmrb@aol.com Remi Metras RMB FR
HYPERLINK "mailto:fl@controldraw.co.uk" fl@controldraw.co.uk Francis
Lovering CONTROL DRAW UK
HYPERLINK "mailto:j.relland@alpha-cim.com" j.relland@alpha-cim.com
Jose Relland ALPHA-CIM FR
HYPERLINK "mailto:Jacky.Tachon@aventis.com" Jacky.Tachon@aventis.com
Jacky Tachon AVENTIS FR
HYPERLINK "mailto:Jacques.cothenet@eu.rhodia.com"
Jacques.cothenet@eu.rhodia.com Jacques Cothenet RHODIA FR
HYPERLINK "mailto:jacques.grossin@adp.fr" jacques.grossin@adp.fr
Jacques Grossin AEROPORTS DE PARIS FR
HYPERLINK "mailto:jean-francois.cardot@isa-france.org"
jean-francois.cardot@isa-france.org Jean-Francois Cardot RHODIA FR
HYPERLINK "mailto:jean-pierre.bovee@aventis.com"
jean-pierre.bovee@aventis.com Jean-Pierre Bovee AVENTIS PHARMA DE
HYPERLINK "mailto:jean.vieille@isa-france.org"
jean.vieille@isa-france.org Jean Vieille* *** CONSULTANT FR
HYPERLINK "mailto:jmrayon@jmrconseils.fr" jmrayon@jmrconseils.fr
Jean-Michel Rayon CONSULTANT FR
HYPERLINK "mailto:Josef.Meixner@erls.siemens.de"
Josef.Meixner@erls.siemens.de Joseph Meixner SIEMENS DE
HYPERLINK "mailto:jwindle@Foxboro.com" jwindle@Foxboro.com John
Windle FOXBORO US
HYPERLINK "mailto:khaled.kassem@cran.uhp-nancy.fr"
khaled.kassem@cran.uhp-nancy.fr Khaled Kassem CRAN University of Nancy
FR
HYPERLINK "mailto:lionelcerisier@yahoo.fr" lionelcerisier@yahoo.fr
Lionel Cerisier
FR
HYPERLINK "mailto:mcelenk@hotmail.com" mcelenk@hotmail.com Metin
CELENK YILDIZ Holding TU
HYPERLINK "mailto:omer.akdeniz@frenchbatchforum.org"
omer.akdeniz@frenchbatchforum.org Omer Akdeniz** SINFOR AUTOMATION FR
HYPERLINK "mailto:p.levrard@arcinfo.com" p.levrard@arcinfo.com
Philippe Levrard ARC INFORMATIQUE FR
HYPERLINK "mailto:Patrick.Richard@aventis.com"
Patrick.Richard@aventis.com Patrick Richard AVENTIS FR
HYPERLINK "mailto:paul.jones@eu.rhodia.com" paul.jones@eu.rhodia.com
Paul Jones RHODIA UK
HYPERLINK "mailto:pallot@ordinal.fr" pallot@ordinal.fr Philippe
Allot ORDINAL TECHNOLOGIES FR
HYPERLINK "mailto:quem@tpg.com.au" quem@tpg.com.au Spiro
Georgakopoulos QUEMM ASSOCIATES PTY LTD AU
HYPERLINK "mailto:rdespins@foxboro.com" rdespins@foxboro.com Robert
Despins FOXBORO FR
HYPERLINK "mailto:rfp@optusnet.com.au" rfp@optusnet.com.au Robert
Price CSL Ltd. AU
HYPERLINK "mailto:smmcleod_uk@yahoo.co.uk" smmcleod_uk@yahoo.co.uk
Steve MacLeod JACOBS ENGINEERING UK
HYPERLINK "mailto:Tony@simmons.demon.co.uk" Tony@simmons.demon.co.uk
Tony Simmons CONSULTANT UK
HYPERLINK "mailto:viruega@ensgi.inpg.fr" viruega@ensgi.inpg.fr
Jean-Louis Viruega ENSGI INPG FR
HYPERLINK "mailto:willie.lotz@sabreweries.com"
willie.lotz@sabreweries.com Willie Lotz SOUTH AFRICAN BREWERIES SA
HYPERLINK "mailto:yong.miao@aspentech.com" yong.miao@aspentech.com
Yong Miao ASPEN TECH
HYPERLINK "mailto:yusaksp@yahoo.com" yusaksp@yahoo.com Yusak
Pandiana Technical University of Delft NL
* Editor
** FBF WG4 chair
*** WBF ``FA'' WG chair
The following companies have sponsored this work:
SCHNEIDER ELECTRIC (Draft 1)
ROCKWELL AUTOMATION (Draft 2)
SIEMENS Automation & Drives (Draft 3)
Contents
Page
TOC \o "1-5" \t
"Style1,1,Style2,2,Style3,3,Style4,4,Foreword,1,Introduction,1" 1 Scope
PAGEREF _Toc49853634 \h 12
2 references PAGEREF _Toc49853635 \h 12
2.1 Normative references PAGEREF _Toc49853636 \h 12
2.2 Other documentation PAGEREF _Toc49853637 \h 12
3 Definitions PAGEREF _Toc49853638 \h 14
3.1 Complex node PAGEREF _Toc49853639 \h 14
3.2 Confining node PAGEREF _Toc49853640 \h 14
3.3 Connection PAGEREF _Toc49853641 \h 14
3.4 Directing node PAGEREF _Toc49853642 \h 14
3.5 Equipment procedural element (EPE) PAGEREF _Toc49853643 \h 14
3.6 Flow PAGEREF _Toc49853644 \h 14
3.7 Flow Analysis PAGEREF _Toc49853645 \h 14
3.8 Flow breaker PAGEREF _Toc49853646 \h 14
3.9 Node PAGEREF _Toc49853647 \h 15
3.10 Path PAGEREF _Toc49853648 \h 15
3.11 Terminal PAGEREF _Toc49853649 \h 15
4 Overview of Flow analysis PAGEREF _Toc49853650 \h 16
4.1 A constraints based modeling PAGEREF _Toc49853651 \h 16
4.2 Intrinsically safe operational vs conventional interlocking
PAGEREF _Toc49853652 \h 16
4.3 Production Plant from Flow Analysis point of view PAGEREF
_Toc49853653 \h 18
5 Modeling principles and terminology PAGEREF _Toc49853654 \h 21
5.1 Basic principles PAGEREF _Toc49853655 \h 21
5.2 Modeling a process cell PAGEREF _Toc49853656 \h 21
5.3 Nodes, Terminals and Connections PAGEREF _Toc49853657 \h 22
5.4 Directing nodes and flow breakers PAGEREF _Toc49853658 \h 23
5.5 Confining nodes (CN) PAGEREF _Toc49853659 \h 24
5.6 Terminals PAGEREF _Toc49853660 \h 25
5.7 Connections PAGEREF _Toc49853661 \h 26
5.8 Complex nodes PAGEREF _Toc49853662 \h 27
5.8.1 Grouping nodes together PAGEREF _Toc49853663 \h 27
5.8.2 Nodes Breakdown principles PAGEREF _Toc49853664 \h 28
5.8.3 Grouping directing and confining nodes PAGEREF _Toc49853665 \h
29
5.9 Generic model PAGEREF _Toc49853666 \h 29
5.10 Mapping FA entities on S88 equipment entities PAGEREF
_Toc49853667 \h 30
5.11 Functional view: Equipment Procedural Entities PAGEREF
_Toc49853668 \h 30
6 Object model and attributes PAGEREF _Toc49853669 \h 32
6.1 Overview PAGEREF _Toc49853670 \h 32
6.2 Control Module Object Model PAGEREF _Toc49853671 \h 32
6.3 S88 Objects PAGEREF _Toc49853672 \h 32
6.4 Attributes and Properties objects PAGEREF _Toc49853673 \h 33
6.5 Path object PAGEREF _Toc49853674 \h 34
6.6 Flow object PAGEREF _Toc49853675 \h 34
6.6.1 Flow object attributes PAGEREF _Toc49853676 \h 34
6.6.2 Flow properties PAGEREF _Toc49853677 \h 34
6.6.3 Material requirement properties PAGEREF _Toc49853678 \h 35
6.6.4 Flow object operations PAGEREF _Toc49853679 \h 35
6.7 Node object PAGEREF _Toc49853680 \h 35
6.7.1 Types of nodes PAGEREF _Toc49853681 \h 35
6.7.2 Node object attributes PAGEREF _Toc49853682 \h 36
6.7.3 Node properties PAGEREF _Toc49853683 \h 37
6.7.4 Node object operations PAGEREF _Toc49853684 \h 37
6.8 Directing Node object PAGEREF _Toc49853685 \h 37
6.8.1 Directing node object attributes PAGEREF _Toc49853686 \h 37
6.8.2 Directing node properties PAGEREF _Toc49853687 \h 38
6.8.3 Directing node operations PAGEREF _Toc49853688 \h 38
6.9 Confining node object PAGEREF _Toc49853689 \h 40
6.9.1 Confining node object attributes PAGEREF _Toc49853690 \h 40
6.9.2 Confining node properties PAGEREF _Toc49853691 \h 40
6.9.3 Confining node object operations PAGEREF _Toc49853692 \h 40
6.10 Complex node object PAGEREF _Toc49853693 \h 40
6.10.1 Complex node object attributes PAGEREF _Toc49853694 \h 40
6.10.2 Complex node properties PAGEREF _Toc49853695 \h 40
6.10.3 Complex node object operations PAGEREF _Toc49853696 \h 40
6.11 Terminal object PAGEREF _Toc49853697 \h 41
6.11.1 Terminal object attributes PAGEREF _Toc49853698 \h 41
6.11.2 Terminal properties PAGEREF _Toc49853699 \h 41
6.11.3 Terminal object operations PAGEREF _Toc49853700 \h 41
6.12 Relationship object PAGEREF _Toc49853701 \h 41
6.12.1 Relationship object attributes PAGEREF _Toc49853702 \h 42
6.12.2 Relationship object operations PAGEREF _Toc49853703 \h 43
6.13 Terminal configuration object PAGEREF _Toc49853704 \h 43
6.13.1 Terminal configuration object attributes PAGEREF _Toc49853705
\h 43
6.13.2 Terminal configuration object operations PAGEREF _Toc49853706
\h 43
6.14 Connection object PAGEREF _Toc49853707 \h 43
6.14.1 Connection object attributes PAGEREF _Toc49853708 \h 43
6.14.2 Connection properties PAGEREF _Toc49853709 \h 43
6.14.3 Connection object operations PAGEREF _Toc49853710 \h 44
7 Implementing flow analysis PAGEREF _Toc49853711 \h 45
list of Figures
Page
TOC \h \z \c "Figure" HYPERLINK \l "_Toc49853539" Figure 1: Flow
integrity concern with complex networked process cells PAGEREF
_Toc49853539 \h 17
HYPERLINK \l "_Toc49853540" Figure 2: Flow Analysis conceptual view
PAGEREF _Toc49853540 \h 19
HYPERLINK \l "_Toc49853541" Figure 3: Free nodes unconnected by flow
vectors PAGEREF _Toc49853541 \h 20
HYPERLINK \l "_Toc49853542" Figure 4: Nodes and vectors making a path
PAGEREF _Toc49853542 \h 20
HYPERLINK \l "_Toc49853543" Figure 5: Process cell example 1
PAGEREF _Toc49853543 \h 21
HYPERLINK \l "_Toc49853544" Figure 6 : Nodes, terminals, connections
PAGEREF _Toc49853544 \h 22
HYPERLINK \l "_Toc49853545" Figure 7: Liquid/Gaseous nodes interface
PAGEREF _Toc49853545 \h 23
HYPERLINK \l "_Toc49853546" Figure 8: Directing nodes PAGEREF
_Toc49853546 \h 23
HYPERLINK \l "_Toc49853547" Figure 9: Ultimate directing node
breakdown : Flow breakers PAGEREF _Toc49853547 \h 24
HYPERLINK \l "_Toc49853548" Figure 10: Confining nodes PAGEREF
_Toc49853548 \h 24
HYPERLINK \l "_Toc49853549" Figure 11: Information propagation
PAGEREF _Toc49853549 \h 26
HYPERLINK \l "_Toc49853550" Figure 12: Higher level process cell
modularization PAGEREF _Toc49853550 \h 27
HYPERLINK \l "_Toc49853551" Figure 13: The whole plant as
interconnected nodes PAGEREF _Toc49853551 \h 28
HYPERLINK \l "_Toc49853552" Figure 14: Recursive Nodes - Generic
model PAGEREF _Toc49853552 \h 30
HYPERLINK \l "_Toc49853553" Figure 15: Object model PAGEREF
_Toc49853553 \h 32
HYPERLINK \l "_Toc49853554" Figure 16: Directing node control
PAGEREF _Toc49853554 \h 39
HYPERLINK \l "_Toc49853555" Figure 17 : Internal node relationships
PAGEREF _Toc49853555 \h 42
list of tables
TOC \h \z \c "Table" HYPERLINK \l "_Toc49853520" Table 1: Nodes
breakdown rules PAGEREF _Toc49853520 \h 29
HYPERLINK \l "_Toc49853521" Table 2: Directing nodes attachment rules
PAGEREF _Toc49853521 \h 29
HYPERLINK \l "_Toc49853522" Table 3: Property object attributes
PAGEREF _Toc49853522 \h 33
HYPERLINK \l "_Toc49853523" Table 4: Node object attributes PAGEREF
_Toc49853523 \h 34
HYPERLINK \l "_Toc49853524" Table 5: Flow properties PAGEREF
_Toc49853524 \h 35
HYPERLINK \l "_Toc49853525" Table 6: Material properties PAGEREF
_Toc49853525 \h 35
HYPERLINK \l "_Toc49853526" Table 7: Node object attributes PAGEREF
_Toc49853526 \h 37
HYPERLINK \l "_Toc49853527" Table 8: Node properties PAGEREF
_Toc49853527 \h 37
HYPERLINK \l "_Toc49853528" Table 9: Directing node object attributes
PAGEREF _Toc49853528 \h 38
HYPERLINK \l "_Toc49853529" Table 10: Directing node properties
PAGEREF _Toc49853529 \h 38
HYPERLINK \l "_Toc49853530" Table 11: Confining node object
attributes PAGEREF _Toc49853530 \h 40
HYPERLINK \l "_Toc49853531" Table 12: Confining node properties
PAGEREF _Toc49853531 \h 40
HYPERLINK \l "_Toc49853532" Table 13: Terminal object attributes
PAGEREF _Toc49853532 \h 41
HYPERLINK \l "_Toc49853533" Table 14: Terminal properties PAGEREF
_Toc49853533 \h 41
HYPERLINK \l "_Toc49853534" Table 15: Possible node relationships
PAGEREF _Toc49853534 \h 42
HYPERLINK \l "_Toc49853535" Table 16: Relationship object attributes
PAGEREF _Toc49853535 \h 42
HYPERLINK \l "_Toc49853536" Table 17: Terminal configuration object
attributes PAGEREF _Toc49853536 \h 43
HYPERLINK \l "_Toc49853537" Table 18: Connection object attributes
PAGEREF _Toc49853537 \h 43
HYPERLINK \l "_Toc49853538" Table 19: Terminal properties PAGEREF
_Toc49853538 \h 44
Introduction
Although ANSI/ISA-88.01-1995 standard helps a lot in clarifying batch
control, it can only be successfully implemented by experienced batch
specialists. First implementations are proven to be always difficult and
time consuming before taking all the benefits of S88 concepts.
Among difficulties, exception handling takes care of any situation that
is not expected in normal operation when their probability of occurrence
is above an acceptable level. It is often allocated as much as 80% of
the design effort, leading to a huge number of discrete interlocks to
prevent wrong operations.
The standard does not provide much information for the specification of
Control and Equipment modules boundaries. Many S88 implementation
reports raise the issue of Process Cell breakdown into its lower level
components (i.e. Units, Equipment Modules and Control modules) and
exception handling. From the ``Top-Down'' to the ``Bottom-Up'' through
the mixed approaches, each project involves user preferences through
specific, often inconsistent guidelines.
According to Spiro Georgakopoulos and Robert Price (see REF
_Ref536520284 \w \h \* MERGEFORMAT 2.2 REF _Ref536520291 \h \*
MERGEFORMAT Other documentation )
``S88.01 - LIMITATIONS AND SOLUTIONS
The S88.01 standard explicitly excludes offering any specific guidance
in the area of low level
decomposition. It expressly draws a line above the protective layer -
``total explanation of process
segmentation is beyond the scope of this standard''. At the same time,
the standard recognizes the difficulty and importance of decomposition
to the whole modeling exercise -``Effective subdivision of the process
cell into well defined equipment entities is a complex activity, highly
dependent on the specific environment in which the batch process
exists.''
A poor decomposition can be recognized by a high number of dangling
control modules that the batch server must monitor and manage. In
addition, methodologies which treat the protective layer separately from
the process result in a large number of interlocks that need to be
enabled or defeated with each phase. Either way, the modularity aspect
of S88 which promises so much is compromised in a tangle of ``special
cases''.
There is a clear need of more practical guidelines beyond the general
S88 concepts to build applications.
Flow analysis outcome is an efficient modularization that simplifies
modules interactions, improves operation safety and dramatically reduces
exception handling overhead. It may apply to any control models, however
this report considers its application within S88 models.
The purpose of the WBF Flow Analysis Working Group is to develop
guidelines based on current practices to complement S88 models to
enforce physical and equipment procedural model design.
Editor's note:
Not sure it corresponds to the current scope
This work is intended to help people from process design, operation and
process control communities to well understand these concepts and to
communicate together, producing robust and safe applications on a
consistent basis.
It should also help vendors to develop supporting tools based on
consensual concepts.
BATCH CONTROL
ISA-88 Modeling using Flow Analysis
Scope
This report focuses on design requirements for inherent actuators
interlocks based on flow analysis. It addresses :
Process cell equipment breakdown (typically at the Control Module level)
Exception handling at the process actuator level
Other subsequent reports may develop other aspects of flow analysis in
S88 control design.
The expected results will be an S88 compliant guideline to address
specific issues encountered in actual implementations of the standard.
The expected benefits are:
Control Modules breakdown consistency leading to a high level of
reusability
Improvement of operation safety
Easier Exception Handling
references
Normative references
The following normative documents contain provisions, which through
reference in this text, constitute provisions of this part of this
report. At the time of publication, the editions indicated were valid.
All normative documents are subject to revision, and parties to
agreements based on this part of this standard are encouraged to
investigate the possibility of applying the most recent editions of the
normative documents indicated below. Members of IEC and ISO maintain
registers of currently valid normative documents.
IEC60902:1987, Industrial-process measurement and control : Terms and
definitions
IEC61512-1:1997, ANSI/ISA-88.01-1995, Batch control- Part 1: Models and
terminology
IEC61512-2:2001, ANSI/ISA-88.00.02-2001, Batch control - Part 2: Data
Structures and Guidelines for Languages.
Note :
In this report, the ANSI/ISA-88 standard will be referred to as S88.
Other documentation
The following documents are related to existing flow-based
methodologies. Although the present report uses fundamental elements
from this documentation, it may not comply with the terminology and
features used or expressed in them. However, the reader may find helpful
information about the genesis of the methodology.
``Methodological guide for the analysis of multipurpose batch process
plants'' RHONE-POULENC N? 501/93.875 - GET 5/EM/519/97/1119 - GT ASTRID
``DELTA NODES Automated flows methodology'' JMR Conseils N?
JMR86/R01-2001_v3
``A Flow Stream Approach for Process Cell Modularization'' - By Francois
Lebourgeois (Rhone Poulenc), Jean Michel Rayon (JMR Conseil) and Jean
Vieille (Consultant) - Presented at the World Batch Forum Conference in
Atlantic City (NJ, USA) on 23/04/2000
``The Missing Link - A generic process control model'' - By Spiro
Georgakopoulos and Robert Price (Quemm Associates Pty Ltd) - Presented
at the 6th World Congress of Chemical Engineering in Melbourne,
Australia on 23-27 September 2001
BatchML XML schemas developed by the World Batch Forum.
Definitions
For the purposes of this part of this report, the following definitions
apply. All terms defined here are italicized in the text when their use
corresponds to the definition. Abbreviations are included in the
definitions. They are capitalized in the text.
Complex node
is made of several nodes of both directing and confining types.
Confining node
has the ability to contain the flow.
Connection
links nodes together through their terminals. It is not an equipment
entity (as to flanges assembled together, each flange being owned by its
corresponding node)
Directing node
has the ability to control the flow (direction or confinement).
Directing nodes support inherent interlocks that prevent erroneous
automatic or manual handling according the safety needs.
Equipment procedural element (EPE)
Equipment procedural element is extensively addressed in S88 part 2.
However, it is not formally defined in the current edition of S88.
Equipment procedural element is an element of the part of the S88
procedural model , which applies to equipment control. It can by either
a procedure, a unit procedure, an operation, a phase or any user defined
procedural entity. Its equivalent at the recipe side is the recipe
procedural element.
Flow
the material or energy content in a path, i.e. the stream of product or
energy that takes place within a set of equipment working together on it
Flow Analysis
a methodology based on an analytical review of processing equipment that
aims at modeling equipment entities in a way that allows generic
mechanisms to impose critical actuators to operate within specified
constraints.
It is safety-focused, providing self-immune environment against
automatic control and manual operation errors regarding material and
energy handling.
Flow breaker
a device that has the ability to break the flow. It can be part of a
directing node, part of a complex node, or an elementary directing node.
Node
a consistent equipment entity. It can correspond to any S88 equipment
entity (Control module, equipment module, unit, process cell...), but
would generally comply with Control Modules. It can be confining,
directing or complex (mixed and embedding other sublevel nodes)
Path
the collection of nodes assembled to perform a functionality provided by
an equipment procedural element. A path can support one or several
flows.
Terminal
is the physical interface of a node
Overview of Flow analysis
A constraints based modeling
Process equipment is selected and installed with a clear expectation of
the purpose it will serve in terms of physical and chemical processes it
is to encounter. A process modeling exercise must recognize those
constraints and incorporate them.
A critical constraint is the requirement that the material remains
confined within a specified part of the process equipment. The operating
context dynamically defines which part of the process equipment is
allocated to each executing process oriented functions. A key
performance measure of an operating process plant is how well material
is contained within the process.
In selecting the equipment a number of physical and safety constraints
are imposed, beyond which it cannot operate. In a plant as a whole,
additional constraints derived from the interaction of equipment come in
to play.
Finally, the product being processed will induce additional safety and
operational constraints.
These constraints can be categorized as follow:
Equipment constraints may be physical things like capacity, maximum
operating temperature, pressure, volume or flow. Or they may be a
chemical (material) constraint - a vessel must never process material
with pH less than 5. Or they may relate to hygienic status, etc.
This information is attached to the equipment
Product constraints include things such as maximum temperature, blending
compatibility.
This information is attached to the product
Relational constraints between equipment, between products or between
equipment and products. For example, possible connections between
equipment determine assembling constraints; 2 products may be
incompatible and shall never be in contact; a product may not be
processed by certain equipment...
Intrinsically safe operational vs conventional interlocking
The following simple example below illustrates how flow analysis impacts
on control system implementation and operational safety considering the
confinement control aspect.
This example shows the difficulties that have to be faced of when
dealing with flexible process cells to avoid cross contamination or
pollution by opening a valve which does not contribute to the intended
functionality (here, transferring product from T2 to T8).
Figure SEQ Figure \* ARABIC 1 : Flow integrity concern with complex
networked process cells
Such process layout imposes to implement a protective layer, which must
be effective when the operator manually controls the plant as well as in
automated operation to avoid errors when controlling the different
circuits.
In order to protect the circuit ``A'' transferring product from T2 to
T8, valves Vo1a, Vo2b, Vo3a, Vo4a, Vi5a, Vi6a, Vi7a, Vi8b are to be
forced to their closed position.
A conventional approach begins by a very detailed risk analysis and ends
by
1) a huge list of interlocks such as :
IF PHASE ``TRANSFER T2->T8'' IS ACTIVE THEN
Vo1a FORCED CLOSE
Vo2b FORCED CLOSE
...
2) an equivalent set of starting conditions for phases:
INITIALIZING PHASE ``TRANSFER T2->T8''
CHECK Vo1a CLOSED
CHECK Vo2b CLOSED
...
3) coordination control to suspend the phase if one of these valves fail
This extensive analysis, specification and coding must be performed for
each combination.
Conventional approaches propose to simplify this design by interlocking
phases instead of valves. However, this method constrains the operation
flexibility, and does not prevent a wrong manual operation. Initial
conditions / actuators failures are to be controlled anyway.
As an example, the following values were noted in a typical multipurpose
chemical process cell:
Number of units / shared equipment modules: 34
Number of phases: 180
Number of instruments: 600
Number of interlocks: 1700
Number of interlocks combinations: 13000
Flow analysis provides intrinsic, extensive interlocking for providing a
better level of circuit integrity control than these numerous interlocks
without any additional coding.
Conventional interlocking seldom reaches a high level of safety because
of its exponential complexity. These interlocks may be dramatically
affected when adding new equipment or defining new phases. (The number
of combinations corresponds to the number of cases that are to be
considered when adding/modifying equipment or phases.)
Smart designers implement matrices to define these interlocks. Coding
becomes better, however other issues remain.
Finally, the validation effort is directly affected by the number of
checks to ensure the system will behave as designed. Replacing discrete
interlocks by a single validated FA mechanism dramatically reduces this
effort.
Production Plant from Flow Analysis point of view
Flow analysis is directed at looking at physical (people, material,
energy) flows. It does not address financial, or information flows.
A production plant uses, moves, acts on 2 basic flows:
Material flow
Energy flow
... using suitable equipment
Liquid material: Pumps, valves, pipes, vessels
Solid or Packed material: conveyors, lifts
Powdery material: roots, pipes, conveyors
Electrical energy: cables, bus bars, transformers, breakers
Thermal Energy (i.e. steam): pipes, exchangers...
Mechanical energy: agitators
...
... performing specific or more complex process oriented functionality
Charging, Emptying, Filling, Distillation, Filtering
Heating, stirring,
...
These actions
may have an implicit (i.e. charge a vessel, which end when the requested
quantity is obtained) or an explicit ending (heating, stirring... which
run forever until they are requested to stop).
may act on a single flow (charge, stirring), on several flows (in-line
mixing)
may use one flow to act on another one (heating)
Any production system (i.e. a process cell) can be considered as a set
of ``closed sections'' regarding the different material or energy flows
that can occur into it (e.g. reactors, filters, pump sets). These closed
sections are bounded by flow breakers (e.g. valves), which control their
linkage with other sections.
Note :
Some parts of the production system cannot be considered as closed
locally, but rather as infinite capacities that supply or consume
product or energy. They represent Process Cell connections to raw or
finished material, ancillary fluid or utilities (Sources and Sinks on
the diagram).
Whatever is the part of the plant to be considered, any production
system can be viewed as follow:
Figure SEQ Figure \* ARABIC 2 : Flow Analysis conceptual view
The considered part of the plant (the studied production system) appears
as a set of material and energy networks:
Sources and sinks are the connection points that limit the scope of the
analysis
Nodes are the places were material or energy is transformed, stored,
directed. They are actual equipment such as vessels, reactors,
transformers, exchangers, pipes, valves, pumps, conveyors...
Flow vectors indicates how the pieces of equipment are actually
connected. The connections established by flow vectors define the actual
plant layout. It may be fixed, but it may also be dynamically arranged
for the purpose of the actual product processing requirements. The
figure below shows free nodes that are not yet connected: equipment is
available, but disconnected (imagine it lies disconnected on the
workshop floor) and unable to fulfill any process oriented functionality
(no material nor energy can be processed). It is not presumed to be
assembled in a particular shape until it is used to make something. Flow
vectors do not currently connect the equipment. They are waiting for any
future usage.
Figure SEQ Figure \* ARABIC 3 : Free nodes unconnected by flow
vectors
A process functionality requires the support of a path by allocating
several adjacent nodes (connected by flow vectors). The figure below
shows the path P1 assembled to perform a process functionality using
nodes A, B, F.
Figure SEQ Figure \* ARABIC 4 : Nodes and vectors making a path
Modeling principles and terminology
Basic principles
Analyzing flows in a process cell may be done at different level:
The connection analysis reveals how equipment is actually linked
depending of flow breakers and connections statuses
The static analysis concentrates on motionless flows, in order to check
if static conditions allows the flow to occur (i.e. to open the
corresponding flow breaker). It gives up once an actual flow is
established.
The dynamic analysis focused on operating flows to compare the actual
performance to internal models in order to detect abnormal deviations
and to predict expecting physical conditions.
This report focuses on operation safety, checking the conditions before
the flow occurs to allow a flow breaker to open or a directing node to
operate as requested. It is based on connection and static analysis.
Modeling a process cell
The following figure shows an example of a simple process cell from
which basic concepts, terminology, and modeling rules can be presented.
Figure SEQ Figure \* ARABIC 5 : Process cell example 1
This process cell includes the following equipment:
3 main processing equipment (CN1, CN4, CN5) that could be qualified as
units following S88 definitions.
2 in-line processing equipment (CN2, CN3) that could be qualified as
equipment modules following S88 definitions.
valves or group of valves (DN1-DN7) that could be qualified as control
modules following S88 definitions. These valves are represented as
no-way symbols but they can be removable pipes and/or blind flanges as
well.
Nodes, Terminals and Connections
Figure SEQ Figure \* ARABIC 6 : Nodes, terminals, connections
All identified pieces of equipment are nodes which:
Represent the recipient (the physical equipment) and its content (the
product or energy inside)
Have an informational interface provided by
properties attached to the recipient (equipment statuses and capability,
product id...)
properties attached to the content (physical and chemical conditions)
May have a behavioral interface provided by methods or functionalities
that can be invoked by other entities
Have a physical interface provided by terminals, which
hold specific properties and statuses,
can be linked to together by connections.
Node categories
Nodes can be categorized to address generic set of constraints and
specific modeling rules. For example Astrid / Delta Nodes identifies the
following categories:
Energy
Controls energy through the equipment (Reactor heating jacket, energy
side of an exchanger, vacuum system, agitator)
Utility
Corresponds to common resources delivering or receiving fluids or energy
to or from the process cell. It has no direct contact with the product
being manufactured. It is generally shared by several Units or Process
Cells (Compressed Air supply, N2 distribution, waste collection, venting
system...)
Material
Participates to the product transformation or movement (Pipe, tank,
reactor, transfer line, conveyor, product side of an exchanger...)
Sub types of material can be defined. This can help to distinguish
different flows through the same equipment:
Solid
Liquid
Gaseous
Powdery
...
For example, the liquid side (lower part) of a reactor is member of the
``Material/liquid'' node that can hold the product, while the gaseous
upper part of the reactor is member of the ``Material/gaseous'' node
controlling the pressurization. This allows dealing with 2-chemical
phases equipment in order to allow parallel control using separate
equipment procedural elements. Exclusive node allocation does not
compromise functional flexibility.
Figure SEQ Figure \* ARABIC 7 : Liquid/Gaseous nodes interface
Node types
There are 3 types of nodes:
Confining nodes which contain the flow
Directing nodes which control the flow by their embedded flow breakers
Complex nodes which combines both confining and directing nodes
Directing nodes and flow breakers
Directing nodes (DN) have the ability to control the flow (breaking,
directing). They generally cannot retain the flow inside themselves.
Figure SEQ Figure \* ARABIC 8 : Directing nodes
They embed flow breakers that actually control the flow. Flow breaker
can be the lowest possible breakdown of directing nodes. The following
figure develops the previous one into elementary directing nodes
encompassing single, simple flow breakers.
Figure SEQ Figure \* ARABIC 9 : Ultimate directing node breakdown :
Flow breakers
Depending on the user's choice, directing nodes can be defined at the
appropriate breakdown level ( REF _Ref48731625 \h Figure 8 versus
REF _Ref48731630 \h Figure 9 ).
Several directing nodes can be linked together to form a more complex
flow control equipment.
Flow breaker can be controlled remotely or manually. They are devices
such as
one-way valves, multi-ways valves
liquid / gas interface
feeder or conveyor motor
removable pipes, blind flanges or plugs
doors or windows,
traffic lights or mobile bridges
...
Confining nodes (CN)
Confining nodes do not control the flow, but can contain it. They do not
embed flow breakers, though they can influence the flow by embedded
devices such as pumps or control valves.
All terminals of a confining node are ``statically equipotent'' i.e. if
the flow doesn't move and the node is not running any material or energy
transformer, all physical conditions are the same for all connections
(static analysis). This is generally not completely true: hydrostatic
weight can influence the pressure depending of the altitude of the
terminal. Also, the temperature can be different at different places and
different times. The REF _Ref49748603 \h Figure 10 shows 2 different
examples.
Figure SEQ Figure \* ARABIC 10 : Confining nodes
Confining nodes can be combined into a bigger confining node.
Terminals
Terminals represent the physical interface of nodes. Nodes can be
connected to each other by their terminals linked by connections.
Terminals can be:
Inputs, if they can only receive an incoming flow
Outputs, if they can only send outgoing flow
Bi-directional if they can send or receive flow either.
Terminals can have other characteristics such as:
type and size of connection mean (flange)
Physical limits (max. pressure and temperature
...
Directing nodes terminals have a particular ``Flow'' attribute that
control the flow occurrence. This attribute has 2 values:
Open
Close
The ``close'' state means the terminal is a dead end. The flow does not
go further. Flow breakers that are responsible for this state look at
the terminal information to accept an opening order.
The ``open'' state means the directing nodes has established a way out
for the flow toward another node, and there is at least one way toward a
confining node (i.e. the flow can occur between 2 confining nodes).
Terminals are fundamental in referencing information relative to:
the equipment they are attached to
the product which flows through them: Product related information is
acquired from the terminals to terminals relationships attached to the
node for output terminals, or from other terminals through its
connection to outside equipment for inputs.
Finally, flow breakers will operate under safe conditions that are
assessed by looking at the information available at its terminals
The REF _Ref49679900 \h Figure 11 below shows information
propagation through terminals. Flow breaker B1 is supposed to be closed.
Because the ultimate goal is to protect operation from erroneously
opening a flow breaker, there is no point to consider information
propagation between communicating nodes (static analysis). We only need
to propagate information at the flow breaker terminals from the
corresponding confining nodes. Once the flow breaker has been opened,
the resulting flow is no longer considered, and the terminal information
is not requested anymore.
Figure SEQ Figure \* ARABIC 11 : Information propagation
Connections
Nodes can be connected to each other using connections that link
terminals to each other.
In many cases, the process cell layout and its connections are fixed.
In other cases, connections are built at run time depending of the
process to be executed.
Connections represent the fact that 2 physical entities (terminals) are
purposely and adequately attached to each other. They aren't physical
objects:
A pipe which links 2 equipment is part of the confining node it is
attached to (the side which is connected without valve).
A removable pipe used to connect 2 pieces of equipment, is considered as
a directing node with 2 terminals.
Connections shall fulfill the following requirements:
All confining nodes terminals are to be connected to either another
directing node. This allows the process to containing the flow, because
it guarantees that it is bounded by flow breakers.
Connections can only link compatible terminals:
Terminals can be input, output or bi-directional
An input terminal can be connected to only one output terminals
An output terminal can be connected to several input terminals
A bi-directional terminal has to be properly connected according its
current use
Connected terminals shall have compatible characteristics
The main role of a connection is to link terminals in order to let the
nodes communicate the actual process conditions downstream the flow.
Complex nodes
Grouping nodes together
In the previous example the process cell was broken down in elementary
pieces were elementary flows can be revealed.
The concept of nodes is flexible and can describe any physical
hierarchy. For example, the following figure represents the same process
cell, but identifies ``macro nodes'', which are consistent with the
mechanical engineering (each node corresponds to separately engineered
modules, or skids delivered by different subcontractors)
Figure SEQ Figure \* ARABIC 12 : Higher level process cell
modularization
Complex nodes do not allow the best flexible and accurate flow
management (for example to deal with bi-directional connections),
because the relationships between terminals are too complex to be
efficiently modeled. However, if bounding flow breakers are identified
as nodes, it becomes possible to control incoming and outgoing flows.
This may be useful when integrating packages.
Complex nodes are obtained by increasing the modularization granularity
(see REF _Ref49746912 \r \h 5.8.2 ). It dramatically simplifies the
control system implementation by reducing the number of modules.
At the highest level, a plant may be analyzed the same way :
Figure SEQ Figure \* ARABIC 13 : The whole plant as interconnected
nodes
Nodes Breakdown principles
Material or energy flows are supported by Paths. A node represents a
part of a Path, acting as a container of material or energy. The
breakdown of the facility into nodes is made by applying the following
rules:
Breakdown rules (BK) give guidance to split the process cell in nodes.
Strictly applied, these rules leads to the most refined breakdown and
results in the highest number of nodes
Aggregation rules (AG) give guidance to possibly reduce the number of
nodes (end the subsequent control system complexity) in grouping
equipment entities that form a set of equipment, which works
independently.
The following table presents the rules that can be applied at the lowest
breakdown level (the nodes the control system will have to deal with,
regardless they are combined together to form higher level entities).
Rule Type BK AG Description, Comments
Closed (confined) section Confining X
A node is bounded by flow breakers
Example, this rule is mentally applied to piped installation by
``blowing'' in any part of the cell while flow breakers are operating
(valves are closed). The identified node is the under-pressure part of
the cell.
Flexibility
All
X When grouping nodes, the resulting diminished flexibility shall be
challenged by checking if different parts of the same node could be used
by different phases at the same time.
Inter-CMs Constraints
All
X Aggregation releases constraints enforcement between aggregated nodes.
A coarse breakdown may lead to lose the benefit of secured operation,
which is basically the intent of the Flow analysis.
Reusability All
X Looking for reusability suggests to isolating equipment subsets that
are fully standards and match the actual equipment once assembled.
The number of different nodes increases with aggregation. The designer
shall compromise between reusability and the number of nodes.
Virtuality
Confining X
It is sometime difficult to identify the equipment the node represents.
That could be the case for controlled physical measurement that are not
part of any mechanical part of the equipment acting on one or several
actuators. (Example: a remote vision system)
Table SEQ Table \* ARABIC 1 : Nodes breakdown rules
Grouping directing and confining nodes
It may be convenient to group confining and directing nodes in complex
nodes that can be consistently managed as autonomous equipment entities
(Control Modules). As a side result, directing nodes are seldom found as
separate entities. An outstanding drawback of this grouping is that it
cannot comply with bi-directional and merging flows.
The resulting complex nodes forms the S88 control module layer or the
Astrid / Delta Node Resource layer. The following table proposes the
rules to attach a particular directing node to the appropriate confining
node.
Attachment Rule Node Type Comment
Upstream driven Material
Sky This rule applies to finite nodes corresponding to process related
flows.
The directing node is attached to the upstream confining node
considering the flow direction.
Process side driven Energy Utility This rule applies to nodes that
control a shared utility to the process.
The directing node is attached to the process side confining node
whatever the direction of the utility fluid is.
Table SEQ Table \* ARABIC 2 : Directing nodes attachment rules
Generic model
Nodes are connected to each other, and embedded within higher-level
nodes.
Depending on the primary breakdown, nodes can be elementary confining or
directing nodes, as well as combined directing nodes or complex nodes.
Nodes hierarchy and internal relationship is modeled until the
lowest-level defined nodes. At the lowest level, it becomes a black box
with terminal internal relationships.
Figure SEQ Figure \* ARABIC 14 : Recursive Nodes - Generic model
Mapping FA entities on S88 equipment entities
As shown above, any physical entity can be interpreted as a node. All
S88 equipment entities physical can be represented as nodes whatever is
their level in the S88 physical model.
The application field of the flow analysis is widely open. However, for
the purpose of this report, we will concentrate at the lowest physical
level where the flows are actually controlled, in order to support the
protective layer that will secure the actuator operation.
Typically, the finest nodes breakdown will correspond to Control
Modules.
Functional view: Equipment Procedural Entities
In order to make a product, a production system must:
Provide the required basic process functions its equipment is capable of
doing (EPE, equipment procedural element). In S88 EPEs can be Phases,
Operations, Unit Procedures, Procedures.
Orchestrate these EPEs following the product processing rules (Recipes,
made of Recipe Procedural Elements or RPEs)
This is the S88 concept of separation between equipment control and
process control. flow analysis may interprets EPEs as follow (the term
node is replaced by control module :
In order to execute a specific EPE, the needed control modules
(initially considered lying dismantled on the floor) need to be
assembled to establish a path. The path represents the physical extent
of its execution and is exclusively allocated to its initiating EPE.
An EPE can execute only if its path can be initialized i.e. the
corresponding Control Modules are available to its use - not currently
used by another EPE allocating an overlapping path or disabled for
whatever reason - and the necessary connections are feasible.
A path may enable one or more flows. Any combination of flows in a path
is allowed from the control point of view; however, it should be
consistent with the mechanical reality (connection check).
As stated in the scope section, this report only concentrates on the
protective layer and basic control. The functional (procedural) aspects
will not be further discussed here.
Object model and attributes
Overview
When dealing with an actual application, designers may take benefit of
flow analysis to help modeling and implementation. Examples of
applications examples are given in annexes.
This section presents the detailed FA elements in order to facilitate
design and implementation.
Control Module Object Model
Figure SEQ Figure \* ARABIC 15 : Object model
S88 Objects
The object model starts by the S88 equipment entity, which is
specialized into control module type, equipment module type, unit type
or process cell type, as well as any user defined level (extensibility
of S88 models).
Whatever they are, S88 entities may be associated to nodes.
Note : Another option could have been to merge S88 Equipment Entity and
Node concepts, which are pretty similar. However, such an approach
would have been more complex because types of nodes would have
overlapped with S88 physical level. It also allow flow analysis concept
to be used with different concepts than S88.
The corresponding objects are not defined in this report:
S88_EqptEntity
S88_ControlModule
S88_EquipmentModule
S88_Unit
S88_ProcessCell
S88_UserEqptEntity
S88_EPE
S88_Procedure
S88_UnitProcedure
S88_Operation
S88_Phase
S88_UserEPE
Attributes and Properties objects
In the model each object has a set of generic attributes. These
attributes may be optional or required.
Note :
Data types are not defined, interoperability is not address in this
report (and shall not be a concern within the scope of this report).
Properties are process related information. All property objects are
based on the same meta-class
Property meta-class object attributes
Attribute Name Description Examples
ID An identification of a property of the associated object.
Description Contains additional information and descriptions of the
property.
UOM The unit of measure of the associated property value, if
applicable.
DesignValue Design or typical value, set of values, or range of the
property.
CurrentValue Current value of the property
MaxValue Maximum value of the property
MinValue Minimum value of the property
Table SEQ Table \* ARABIC 3 : Property object attributes
This meta-class defines the design information (design, maximum and
minimum values), as well as the current value of the same information.
This is the basic information to check flow consistency by comparing
design and actual values:
design value of the node at the downstream side of a flow breaker
against actual value of the node at the upstream side of the flow
breaker
Actual and design values within the same equipment
The following classes are based on this meta-class:
Flow_Property
Material_Property
Node_Property
DirectingNode_Property
ConfiningNode_Property
Connection_Property
Terminal_Property
Properties can also be used for additional information as a mean to
extend the model without compromising its consistency and easily
identify user / implementation specifics.
Path object
The path establishes the relationship between a flow and the nodes.
Editor's note:
Do we need the path object?
Flow object
A flow shall correspond to an S88 equipment procedural entity, which is
the S88 equipment process oriented functionality. (Astrid / Delta Nodes
gives use both ``Functions'' and ``Flow'' terms do designate the
functionality and the flow which is built to uniquely support it).
This object is presented on the model, because it holds material
requirement properties, which are needed to control the proper
conditions of the allocated nodes.
Nodes are actually acquired by flows at run-time. If the acquired node
is made of lower level nodes, the owning flow information is propagated
downstream in the hierarchy, allowing any node to control its current
conditions against material requirements.
In actual implementations, several EPEs may run together to form a given
flow. It is the case when a TRANSFER phase is synchronized with a
RECEIVE phase on 2 different units. This is represented by a flow
containing 2 lower-level flows, each of them being associated to the
corresponding phase.
Flow is a recursive structure, and each flow may be related to 0 or
several EPE.
Flow object attributes
Node object attributes
Attribute Name Description Examples
ID An identification of the object.
Description Contains additional information and descriptions of the
object.
S88_ProceduralLevel Specifies the S88 EPE procedural hierarchy level
Possible values are:
Procedure
Unit procedure
Operation
Phase
BatchID Batch identifier.
Product ID Product identifier
OperatorID Operator Identifier.
ActivationStatus Activation status of the flow. Possible values are:
IDLE
RUNNING
STOPPED
HOLD
FAULT
ActivationSubStatus Additional identifier, documents the
ActivationStatus. (Application specific values)
It identifies specific running behaviors or mitigation methods
Table SEQ Table \* ARABIC 4 : Node object attributes
Flow properties
To be completed
Example of flow properties
Property Name Description Examples
Table SEQ Table \* ARABIC 5 : Flow properties
Material requirement properties
Material requirement information is attached to the flow because this
information is defined in the recipe and has to be downloaded into
EPEs/flows at run-time. It propagates from the Recipe Execution domain
to the operating EPE/flow and finally to the acting control modules to
feed flow control interlocks.
Example of material properties
Property Name Description Examples
Quantity Quantity of product to be processed
Specific mass
SizeL
SizeW
FlowRate Required flow
Temperature Required Temperature
Pressure Required pressure
PH Required PH
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 6 : Material properties
Flow object operations
Any flow can have incorporated operations that can be invoked for
performing procedural control as EPEs.
There are no specifics regarding flow analysis regarding procedural
control.
Node object
Types of nodes
Nodes can be specialized in 2 types: directing nodes, confining nodes.
Node structure is recursive; a node can be made of other nodes:
Directing nodes can content other directing nodes. At the last level,
they content flow breakers
Confining nodes can content other confining nodes
A complex node is made of both type of nodes
Information attached to the node (attributes or properties) is mainly
equipment related.
Node object attributes
Node object attributes
Attribute Name Description Examples
ID An identification of the object.
Description Contains additional information and descriptions of the
object.
S88_EqptEntity Corresponding S88 equipment entity
S88_EqptLevel Specifies the S88 physical hierarchy level. Possible
values are:
Control Module,
Equipment module,
Unit,
Process Cell
ContainedIn Node this node is contained in
Type Type of the node.
The complex type can be self-specified if the node contains both type of
nodes or a complex node.
It has to be specified if the breakdown does not model the node
components. Possible values are:
Confining
Directing
Complex
Category Category of the node.
Other values can be defined in properties Possible values are:
Material/Powdery
Material/Liquid
Material/Solid
Material/Gaseous
Energy
Utility
BatchID Batch identifier.
It may be set by the owning EPE and shall propagate downstream in the
node hierarchy
It may by set by the directing nodes terminals and shall propagate
upstream in the node hierarchy. Multiple batch identifiers may result in
flow merging depending on the node composition and equipment usage
ProductID Identifier of the last product the node contained
FlowID The flow identifier is set by the acquiring EPE.
It propagates downstream in the node hierarchy.
OperatorID Operator Identifier.
It is set by the owning EPE
It propagates downstream in the node hierarchy
ActivationStatus Activation status of the node. Possible values are:
STOPPED
RUNNING
FAULT
ActivationSubStatus Additional identifier, documents the
ActivationStatus. (Application specific values)
It identifies specific running behaviors or mitigation methods
OperationalStatus Status of the current operational conditions Possible
values are:
Normal operation
Direct manual operation
Broken down
Under maintenance
Repaired
SanitaryStatus Cleanness, sterility, sanitary Status. Possible values
are:
clean
contaminated
sterile
unknown
Product
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 7 : Node object attributes
These attributes apply to any node whatever is its type.
Node properties
Node properties include the physico-chemical information of the
equipment: are configured at the engineering level providing additional,
application specific information that describes:
Example of node properties
Property Name Description Examples
Capacity capacity of the equipment
Weight
Level
Volume
DimensionL
DimensionW
Flow Flow of the equipment
Temperature Temperature
Pressure
PH
... Note :
Other attributes may be defined by the user
Table SEQ Table \* ARABIC 8 : Node properties
Node object operations
Any node can have incorporated operations that can be invoked for
performing elementary actions.
There are no specifics regarding flow analysis at this level (however,
directing nodes have specifics regarding flow control)
Directing Node object
Directing node object attributes
Directing node object attributes are specific information about this
type of nodes
Directing_Node object attributes
Attribute Name Description Possible values
OperationMode The mode of operation is the way the device is controlled.
Unlike most methods, flow analysis is concerned by all actuators
regardless they are connected to the control system or not.
Possible values:
Handled (driven by the operator - no connection with the control system)
Ex:A blind flange
Controlled (driven by the control system). Ex: actuated on-off valve
Virtual (there are no corresponding device to control). Ex: a glass
fiber can be broken at the outlet of the glass oven, corresponding to a
``virtual'' flow breaker
...
Table SEQ Table \* ARABIC 9 : Directing node object attributes
Directing node properties
To be completed
Example of directing node properties
Property Name Description Examples
Table SEQ Table \* ARABIC 10 : Directing node properties
Directing node operations
Directing nodes actually controls the flow. It gets information on
conditions at its terminals and takes the appropriate protecting
decision depending of them.
The REF _Ref49767332 \h Figure 16 shows the different control a
directing node is under. Flow control is actually part of the directing
node. It acts as an interlock between automatic/manual control and the
actuators.
Figure SEQ Figure \* ARABIC 16 : Directing node control
Directing nodes support the flow analysis safety layer. This safety
layer act as an interlock between automatic and manual control, and the
actuators within the node. They perform the following flow control
operations:
Set the direction
Basic control that acts on flow breakers and other actuators
Before establishing a flow
Control the equipment compatibility
Check for the invoked terminal relationship if the ``open'' terminals
have compatible statuses with terminals of the connected nodes (a
``PayReceive'' terminal shall be connected to either a ``MaySend'' or a
``MaySendOrReceive'' terminal
Control the flow integrity
Check if the nodes that will be linked are part of the same flow
Control the product-process / equipment compatibility
Check if the process conditions of the nodes that will be linked are
compatible with the equipment capabilities (ex: maximum temperature) and
status (ex: clean)
Control the product-process compatibility
Check if the products that will be mixed are compatible
When the flow is estblished
Control the process conditions against material requirements
Check if the operating conditions are compatible with the material
requirements
To be developed
Confining node object
Confining node object attributes
To be completed
Confining_Node object attributes
Attribute Name Description Examples
...
Table SEQ Table \* ARABIC 11 : Confining node object attributes
Confining node properties
To be completed
Example of directing node properties
Property Name Description Examples
Table SEQ Table \* ARABIC 12 : Confining node properties
Confining node object operations
To be completed
Complex node object
To be completed
Complex node object attributes
To be completed
Complex node properties
Complex nodes don't have specific properties. They can be either
directing or confining nodes properties.
Complex node object operations
To be completed
Terminal object
Terminal object attributes
Terminal object attributes
Attribute Name Description Examples
ID An identification of the object.
TerminalStatus Status of the terminal regarding the flow that
determines if the terminal is or not an end of the flow. An open
terminal indicates that the node is part of the flow, but not the last.
A close terminal indicates this node is an end of the flow. Possible
values are:
Open
Close
FlowStatus Status of the terminal regarding the flow. Possible values
for a closed terminal:
MaySend
MayReceive
MaySendOrReceive
Possible values for an open terminal:
Receiving
Sending
...
Table SEQ Table \* ARABIC 13 : Terminal object attributes
Terminal properties
To be completed
Example of terminal properties
Property Name Description Examples
Table SEQ Table \* ARABIC 14 : Terminal properties
Terminal object operations
To be completed
Relationship object
Relationships object defines the possible ways through the node.
These relationships are normally associated with / activated by node
operations, which set the different flow breakers (actuators) patterns.
At least one relationship shall be defined for each node.
Relationship may be active or inactive (at run-time).
Active relationships determine all actual node internal connections
between its terminals.
If no relationships are active, default relationship apply .
Several relationships may be active at the same time. That means that
several separated flows All relationships sharing at least 1 terminal
are all connected together.
Example:
Figure SEQ Figure \* ARABIC 17 : Internal node relationships
The following table represents all possible Relationships:
Terminal 1 Terminal 2 Terminal 3 Terminal 4 Terminal 5 Terminal 6
RelationShip 1
RelationShip 2
RelationShip 3
RelationShip 4
RelationShip 5
RelationShip 6
RelationShip 7
RelationShip 8
Table SEQ Table \* ARABIC 15 : Possible node relationships
For example, relationship 1 lets communicate terminal 1 and 4
Relationship object attributes
Editor's note
The model only consider simplistic relationships between terminals. More
complex relationships regarding physical information transformation
(flow, temperature, pressure...) are not taken into account. Is that a
problem?
Relationship object attributes
Attribute Name Description Examples
ID An identification of the object.
ActiveStatus Flag for the active relationship.
Several relationship can be active at the same time Possible values:
True
False
DefaultRelation Identifies the relationship that is enable when no
relationships are invoked (i.e. the ActivationStatus of the node is
``stopped'', or if the node is not controlled)
Several relationship can be default Possible values are
True
False
Table SEQ Table \* ARABIC 16 : Relationship object attributes
Relationship object operations
To be completed
Terminal configuration object
Terminal configuration set the attributes to all terminals for each
identified relationship. The attachment of terminals to relationships
must be more
Terminal configuration object attributes
Terminal configuration object attributes
Attribute Name Description Examples
TerminalID Identification of the terminal
TerminalStatus Set the corresponding terminal status.
All unused / blind terminals are set to ``Close''. Other are open
Possible values are:
Open
Close
FlowStatus Set the terminal ability regarding the direction of the flow
Possible are:
MaySend
MayReceive
MaySendOrReceive
Table SEQ Table \* ARABIC 17 : Terminal configuration object
attributes
Terminal configuration object operations
To be completed
Connection object
Connection objects defines links between nodes. It tells a terminal
which other terminals from external nodes are connected to it.
I allows the directing node to know the actual conditions in front of
each closed terminal, in order to check flow consistency and authorize
the corresponding flow breaker to operate.
Connection object attributes
Connection object attributes
Attribute Name Description Examples
ID An identification of the object.
Terminal1 First terminal the connection links
Terminal2 Second terminal the connection links
Table SEQ Table \* ARABIC 18 : Connection object attributes
Connection properties
To be completed
Example of connection properties
Property Name Description Examples
Table SEQ Table \* ARABIC 19 : Terminal properties
Connection object operations
To be completed
Implementing flow analysis
This section provides guidance in order to facilitate FA implementation
in control systems.
To be completed.
Editor's note:
Shall include an actual example and possibly its implementation.
Shall address the possible overhead when implementing the full
methodology
Shall discuss the location of all information attached to the objects
(within the PLC/Controller, from an external data-base...) While I
thought it was a design / integration only issue, several comments
revealed that it is already a concern at our conceptual level
Shall discuss Internal exception handling
Page PAGE 11 / NUMPAGES 45 DATE \@ "dd/MM/yyyy" 28/08/2003
FILENAME \* MERGEFORMAT WBF-WG-FA_Draft3.doc
Johann Sebastian Bach. the music closest to silence, closest, in spite of its being so highly organized, to pure, one-hundred-degree proof Spirit" (Aldous Huxley, Island)