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