CCPP

Functional design, objects, documents/drawings, design spec’s, coding and break down structures
Table of contents
0 Introduction
1 Definitions. Functional engineering and OntoCAPE
2.1 Manufacturers Embrace Functional Design Paradigm Shift
2.2 What is functional design?
3 Functional engineering for the process industry, functional objects and the documents.
4 Functional engineering for all engineering disciplines in more detail, data exchange and storage
4.1 The Process Flow Diagram - PFD, a schematic illustration of the system
4.2 P&ID General Information
4.3.Functional Equipment Data Sheet (Process and mechanical to complete)
4.4.Functional documents for Process Control
5 Functional Design Specification
6 Coding and break down structures
7. ISO/IEC 11179 Information technology — Metadata registries (MDR) —
8. ISO/TC 10, from DIN-9776 to the harmonized ISO/IEC 81346
9.. The Cohesion of Plant breakdown structure, Identification, Coding, Plant numbering, Structure,
Master Data Management, OntoCAPE, Data exchange, Data storage, STEP AP221, ISO 15926 and
Gellish in the life cycles of a plant. (it deals with information aspects of the translation from
functional engineering to the hardware (materialized) engineering)
0 Introduction
It is an initial drafted part, as part of many papers (book), that describe the different aspects of the lifecycle
of a process plant, in order to harmonize our mutual activities
In this conceptual positon paper on "Functional engineering, objects and documents the second draft".
some of the aspects on the functional (conceptual and wider including Feed) engineering, is discussed
1 Some Definitions.
In the ISO TC 184/SC4 WG 2 T25 communities it is felt necessary to discuss the subject of functional
design also referred to as functional engineering. Functional design in the world has different
meanings, see below. With the OntoCAPE (see page3) developers we like to exchange the
developments
Functional design (computer science) A level of the design process in which subtasks are specified and
the relationships among them defined, so that the total collection of subsystems performs the entire
task of the system.
Functional design (systems engineering) The aspect of system design concerned with the system's
objectives and functions, rather than its specific components.
Difference between process design and Functional design.

From the document Functional and Physical Objects –we use the big picture approach.
1 For critical equipment a spare can be purchased at the same time, or later, against the same
specification. This spare unit can be put in the warehouse or can be installed as an "installed spare",
with or without automatic switch-over (below the resulting numbering with A and B will be addressed).
If, for some reason, the supplier cannot deliver, e.g. because of bankruptcy, another Materialized
Physical Object is purchased from another supplier against the same specification of the class P101.
2 In case an installed spare pump is required, we usually number them with A and B, here: P101A and
P101B. That means that there are two classes that happen to have the same class definition, except
for their service description. That spare pump did not come into existence for process technical
Handbook Process Information Automation (from) chapter 1,2,3,4 rev 15/4/2012 doc hindrik koning, prt 24-03-19 page 1/173
reasons, but for business reasons (we want a maximum uptime of the plant).
3 3 Another case of A and B we may find in certain control valve configurations. For the process
engineer there may be, at a particular point in the plant design, just one control valve, say FV5. Based
on the heat and material balance he then may define a minimum a nd maximum flow that are far apart
from each other, i.e. a large range ability is required, larger than any single control valve can possibly
deliver because of leakage. The control systems engineer (I used to be one for many years) then
specifies two control valves, one with linear and one with equal percentage characteristics, and with
split-range positioners.
Design refers to the planning that is the foundation of making things. There are different design
philosophies, approaches, and methods. Design strikes a balance between a number of different
components, and depending on the situation, it can give more weight to one or another. For example, one
might focus on materials and ask what could be made with a certain collection of items, or one could focus
on aesthetics and try to imagine the most beautiful object to place in a certain setting.
Functional design can refer to a focus on function rather than aesthetics, a concern with objectives rather
than components, or it can refer to the use of a complete requirements document to guide development and
testing or to a computer modeling technique. In addition functional design is an integral part of functional
design specification.
Functional design This term is introduced and amplified in the world of ICT, the computer programming
projects, a business that that after it grew needed new beacons to overcome their initial problems, the
underlying theory and implementation was however used for many years also in the Process and Power
industry, sometimes a bit sloppy.
Functional design. In engineering design In the lifecycle of engineering projects, there are usually
distinguished subsequently: Requirements and Functional specification documents. The
Requirements usually specifies the most important attributes of the requested system. In the Design
specification documents, physical or software processes and systems are frequently the requested
functions.
Functional design In products For advertising and marketing of technical products, the number of
functions they can perform is often counted and used for promotion. For example a calculator
capable of the basic mathematical operations of addition, subtraction, multiplication, and division,
would be called a "four-function" model; when other operations are added, for example for scientific,
financial, or statistical calculations, advertisers speak of "57 scientific functions", etc. A wristwatch
with stopwatch and timer facilities would similarly claim a specified number of functions.
In engineering a process is a set of interrelated tasks that, together, transform inputs into outputs. [1] These
tasks may be carried out by people, nature, or machines using resources; so an engineering process
must be considered in the context of the agents carrying out the tasks, and the resource attributes
involved.[2] Systems Engineering normative documents and those related to Maturity Models are
typically based on processes. For example, System Engineering processes of the EIA-632 and
processes involved in the Capability Maturity Model Integration (CMMI) institutionalization and
improvement approach. Constraints imposed on the tasks and resources required to implement them
are essential for executing the tasks mentioned
Most often, functional design is used to mean that the product’s functionality is taken into account in
important ways as it is imagined and built. For a product to end up being functional, both the end user and
the client need to be considered all the way through the design process. It may take some work to describe
the target audience accurately. The process of functional design begins with the goal of the product: a clear
statement of what it is supposed to do. This does not mean that what the client wants it to do is the only
thing that the user will, in fact do with it. It does need to do well what it was made to do.Usually the end user
is not represented directly in the functional design process, so his or her responses have to be imagined.
Designers must also imagine his or her ability to learn how to use the product, to integrate it with other
products he or she already has, or to adapt it to his or her unique circumstances, if it is the kind of product
that is meant to be personalized. Similarity of design to existing products and well-done documentation can
contribute to the end user’s experience; that is, thoughts about things that are not intrinsic to the product
itself can help the product to be more functional for the user than it would be otherwise. With any product
that has to be plugged in, a feedback system needs to be established. People are used to the light that tells
them that the vacuum is plugged in and the funny sound in their word processing software that tells them
that they’ve tried to do something that has no reasonable outcome. Part of functional design is letting the
user know that the product is or isn’t functioning. Furthermore, if something isn’t working or the user
attempted something that failed, a well-designed product will assist the user in getting things back on track.
WHAT IS FUNCTIONAL ENGINEERING?

Functional engineering is the process of building a mathematically rigorous
representation of the expected functional behavior of the proposed software. The
problem of defining, measuring, and testing detailed functionality has previously been
tackled by hardware engineers, and chip testing engineers in particular. These
engineers needed to be able to quickly confirm the correct functional behavior of
every computer chip coming out of a fabrication plant. The algorithms used to design
tests for chip logic should also apply to the functional logic of software.
Functional engineering in the life cycle.

In the literature functional engineering is done during the better known conceptual
engineering phase.
In some companies we have conceptual, basic and detail engineering for a cost
estimate of respectively
+/- 40 %, +/- 25 % and +/- 10 % accuracy. In other companies no basic engineering is
done. In the first case functional engineering takes place during the conceptual and
basic engineering phase, in the later case we compress conceptual and basic in an
extended conceptual engineering phase.
Functional engineering and CAPE OPEN

The structured chemical process calculations are after the Research made in the first
phase as one of the first activities of the Process department during the conceptual
engineering phase. Aspentech has incorporated this in his software.
CAPE-OPEN standards are the uniform standards for interfacing process modelling software components
developed specifically for the design and operation of chemical processes. They are based on universally
recognized software technologies such as COM and CORBA. CAPE-OPEN standards are open,
multiplatform, uniform and available free of charge. They are described in a formal documentation set.
Hiroshi San did send the promised information.
Functional engineering and OntoCAPE

OntoCAPE is a large-scale ontology for the domain of Computer Aided Process Engineering (CAPE).
Represented in a formal, machine-interpretable ontology language, OntoCAPE captures consensual
knowledge of the process engineering domain in a generic way such that it can be reused and shared by
groups of people and across software systems. On the basis of OntoCAPE, novel software support for
various engineering activities can be developed; possible applications include the systematic management
and retrieval of simulation models and design documents, electronic procurement of plant equipment,
mathematical modeling, as well as the integration of design data from distributed sources.
For the formal specification of OntoCAPE, the Ontology Web Language OWL has been chosen (OWL-DL in
particular, www.w3.org/2004/OWL/). The modeling was accomplished by means of the ontology editor
Protégé for the verification, the reasoner RacerPro has been used. The current release of OntoCAPE
consists of 62 OWL files, each of which includes one module of the ontology.
Conclusion: OntoCAPE has its position within functional engineering in ISO 15926.
We agreed to contact also the developers of ONTOCAPE, A. Wiesner, J. Morbach, A. Yang, B. Bayer, W.
Marquardt RWTH Aachen University Aachener Verfahrenstechnik Process Systems Engineering
52056 Aachen
2.1 Manufacturers Embrace Functional Design Paradigm Shift
Function drives form to redefine CAD.

By Robert "Buzz" Kross, vice president, manufacturing solutions, Autodesk
Nov. 10, 2006

It's often been said that form follows function. I prefer to think that function drives form. Unfortunately, just
the opposite is true for modern CAD tools -- function is a slave to form (or geometry). Given the current
climate of intense global competition, and its associated requirements for increased innovation, form can no
longer stand between an engineer and the functional problem they are trying to solve. Instead, it must
support the engineer on their journey to innovation. And the fastest road for that journey is paved by
Functional Design -- a paradigm shift that is ushering in the redefinition of CAD.
Bridging The Gap Between Form And Function
Take the case of a Cincinnati-based manufacturer of food processing and automation machinery, Planet
Products. Its current line of food processing loaders was at risk of becoming outdated. It needed a redesign
to reduce costs, increase efficiency, and meet the more stringent demands of the food industry. The ability
to easily disassemble and clean the machinery was a critical requirement. Planet Products used a
functional approach to design in order to develop digital prototypes that allowed them to rapidly test new
ideas that redefine the industry standard. The company put function before form to design the SP3 Next
Generation Loader, helping Planet Products become recognized and honored around the world for
innovation in precision equipment design.
What can we learn from Planet Products' success? Their secret lies in the minds of their engineers and the
CAD tools they use to explore ideas. To replicate Planet Products' success, we must look at the way
engineers bridged the gap between form and function. In other words, how the software they used helped
them focus on functional requirements first and geometry second. This enabled them to drive innovation
while the software helped them drive productivity. This is the change Functional Design brings to the
market.
Look at the way another heavy manufacturer, Kone, embraced the concept. Kone is a leading elevator and
escalator company worldwide and the manufacturer of a unique solution that enables complete
modernization of outdated escalators (regardless of brand) by removing all existing mechanical and
electrical components and seamlessly inserting new ones. They employed a functional approach to design
sub-systems of their solution and were able to quickly drive re-use and interoperability across components.
This gave Kone more time to focus on the critical requirement of reducing field installation hours and
improving component fit -- allowing for quick installation of the latest components without major disruption to
customers. Focusing on function first, and geometry second, helps Kone best deploy their engineering
talent.
At the heart of both these examples is a relentless focus on the functional requirements of design -- not the
geometric modeling requirements of the CAD tool. Software should not distract the engineer from their
design process -- it should enable it. In addition, in order for manufacturers to continually drive productivity
and innovation, CAD software should make it fast and easy to create and use digital prototypes throughout
the entire design through manufacturing process.
Harnessing The Power Of Digital Prototypes
The power of such digital prototypes is well established. Along with enabling the engineer to explore the
complete function of their design over and over again without a costly physical prototype, it reduces the
number of physical prototypes required to get to the final design. In the end, this lowers the cost and
complexity of manufacture. Every engineer, in every manufacturing enterprise, should be able to exploit the
power of digital prototyping at all stages in the design process.
Unfortunately, most modern CAD applications don't make that possible. The singular focus of CAD on
creating 3D model geometry distracts the engineer from the most important work they do -- functional
problem solving. Engineers are forced to become 3D modeling experts in order to document ideas they
usually have to solve with pen and paper. Beyond that, they are often forced to use specials modeling
methods and tools in order to "repair" geometry so it is useful. Getting to a digital prototype is even more
complicated - often requiring the engineer to completely recreate model geometry. The result? No time to
exploit the power of the digital prototype. Focusing on geometry not only costs engineers time, it also costs
them opportunities to innovate.
On the other hand, Functional Design keeps the engineer focused on solving design and manufacturing
problems, not 3D modeling problems. Beyond that, it makes it easier to exploit digital prototypes across the
entire design through manufacturing process. More simply, it represents a shift in how engineers use CAD
to bring new products to market. Software with Functional Design capabilities allows the engineer to work
with simple (or schematic) representations to validate a design based on its real-world requirements. The
software then generates 3D geometry automatically, or makes it simple to create, in order to deliver a digital
prototype easily and reliably.
The powerful convergence of visualization, simulation, and automated modeling embraced by Functional
Design blurs the distinction between CAD and CAE and makes it possible to dramatically decrease the
number of physical prototypes while increasing an engineering team's ability to innovate.
Solving Complex Challenges
Competition is increasing for manufacturers all over the world and customers are demanding increasingly
unique solutions to drive their own competitive advantage. This means manufacturers have to focus on both
productivity and innovation in order to succeed. Manufacturers should expect their CAD tools, and the
design processes they support, to evolve in a direction that helps them meet this increasingly complex
challenge. CAD tools that make function a slave to geometry create barriers to productivity and stifle
innovation. Function must drive form and manufacturers should expect nothing less from their CAD tools.
The next generation of best-in-class manufacturers will be exploiting Functional Design to drive their design
through manufacturing process.
Robert "Buzz" Kross is vice president of manufacturing solutions for Autodesk. Autodesk, Inc. is a software
and services company for the manufacturing, infrastructure, building, media and entertainment, and
wireless data services fields. Autodesk's solutions help customers create, manage and share their data and
digital assets more effectively. http://www.autodesk.com
2.2 What is functional design?

SEPTEMBER 27, 2007
A combination of engineering and geometric modeling called “functional design” helps generate digital
prototypes early in the design cycle, letting them be continually validated for form, fit, and function.
Andrew Anagnost
Sr. Director CAD/CAE Products
Autodesk Inc.
San Raphael, Calif.
Edited by Leslie Gordon
A recent Aberdeen Group study showed that best-in-class manufacturers — those that get products to market
faster with the lowest change costs — build about half the number of physical prototypes than other
manufacturers. The reward: they get to market, on average, 58 days faster. A main factor in their success is
digital prototyping. Here, information flows through a digital pipeline that remains unbroken throughout the
product’s life-cycle. Currently, most 3D CAD software does not make it easy to do fully integrated digital
prototyping. Many users find the software is too complex, or they use CAD simply to document design
problems they’ve already solved. For instance, a company might use 3D models to test form and fit and
automate the creation of 2D drawings. What is needed, however, is the ability to quickly and easily build
digital prototypes that let users test form, fit, and function without requiring them to be expert in generating
geometry or managing geometric constraints.
Think about how you use word-processing software (like I am right now). Users need not worry about altering
typefaces so documents will print, or what will happen after deleting a paragraph. They simply turn ideas into
words and let the software take care of printing and text reordering. Unfortunately, CAD functions that are a
direct analogy to word processing’s Print and Delete still hinder many users. For example, unless 3D models
are built by knowledgeable designers, the models will not necessarily let users answer ques t ions about how
the final products will operate in working environments.
Also, the way parts are assembled in 3D CAD does not let users test the function of the parts. It only lets
users put the geometry together. Thus, 3D programs force users to solve geometry problems, not engineering
problems. And today’s software doesn’t make it easy to build digital prototypes. For one thing, users follow
different paths to build digital prototypes than to build geometric models. Users must also deal with CAD
functions such as face-to-face mates and edge constraints that are not real-world inputs — they are mathe-
matical abstractions that were devised so the mathematics of the model could be solved on a computer.
These difficulties mean most manufacturers still rebuild models or hire outside experts to use geometric
models to assess function. Or, more likely, companies do nothing at all. This leads to unpleasant surprises on
the factory floor and lengthy physical prototyping cycles.
Under the hood of a typical 3D modeler

Many design methods have attempted to address the limitations of parametric feature-based modeling soft-
ware. Among them are history-free modeling, rules based design, and even customized systems. However,
the answer lies not with any of them alone, but with a combination of engineering and modeling called
“functional design.” For a good grasp of functional design, it is helpful to first understand the attributes of
typical 3D software and then take a more detailed look at the techniques that have tried to solve modeling
problems.
First, 3D programs are built on top of a geometry kernel (either a broadly available or a proprietary one), i.e.,
a topological solver that does all the heavy mathematical lifting. The programs also create a history of
features that let users define geometric components such as fillets, chamfers, and holes in a sequence of
operations that mimic manufacturing processes. And the programs have constraint solvers that let users alter
the size of sketches and parts, and place them relative to each other in space.
A parametric solver lets users vary the relationships of size and position with numbers and mathematical
formulas. The solvers let users change one piece of geometry based on the size of another — such as the
diameter of a hole that varies with the size of the bolt that must fit through it. The kernel is generally invisible
to users. The history tree and constraints must be actively managed by users and are the primary difficulty
associated with creating, editing, and validating designs with 3D models.
In fact, designers and engineers know exactly how easy it is to get into trouble with 3D modeling. Features
are created with a history — that is, they depend on features created before them — so deleting a feature
early in the history can result in a model that either fails to regenerate (think of this as a document that won’t
print) or no longer represents design intent (imagine your Times New Roman font printing out as Gothic).
Users must thus pay strict attention to the order in which features are created (called the “feature tree”) to get
the right result. Only then do they get intelligent models that can be reused by others and edited rapidly to
respond to design changes. Parametric constraints have similar problems. When users don’t pay attention to
how and when they apply constraints, they build models that are either impossible to change or not usable by
others, let alone being useful as digital prototypes.
Past techniques
When it comes to the techniques that tried to solve modeling problems, one mentioned above is history-free
modeling. It delivers an intuitive interface that lets users quickly and easily create models without worrying
about the order of modeling operations. The models are stable (meaning they almost always regenerate after
a change), but they lack the design and manufacturing intelligence of parametric features. History-free
modelers build models that cannot be used to validate form, fit, and function of designs. They are, in many
ways, a move backward to modeling solutions that preceded parametrics and history, and remind us why
those technologies evolved in the first place.
Another method, knowledge based systems, tries to describe an entire product from engineering rules, and
then use the rules to create 3D geometry that can be used to validate form, fit, and function, as well as
generate 2D drawings. Essentially, rules-based programming is layered on top of the CAD system to program
3D models. This works well with highly repeatable designs (for example, conveyors, escalators, and
elevators). But the cost and expertise needed to create intelligent models is prohibitive. The technology is
currently limited to companies that can justify the consulting expenses.
Last is custom designs, prevalent in large automotive and aerospace companies. These systems consist of a
series of applications (usually based on a core 3D CAD package) purpose-built to automate or simplify
specific design and digital prototyping tasks that are done over and over again each time a car or aircraft is
designed. The highly regulated nature of these industries, along with the per-unit costs and product volumes,
justify investing in these tools, but few of them are in widespread use.
The functional fix

As mentioned previously, 3D CAD users are largely unaware of the mathematics needed to create computer
representations of 3D parts. The same should be true for history and non history based features, constraints,
and parametrics. A functional design approach with Inventor software, for instance, pushes these capabilities
back to the level of kernels operating behind the scenes. The software exploits the feature history, delivers the
ease of use of local history-free operations, and leverages rules to generate parametrically constrained
geometry, all from simple functional representations of a product design. .Functional design does not
eliminate the need to solve geometric modeling problems, but it minimizes the amount of time users spend on
such problems. And it ensures the generated geometry is usable as a digital prototype.
To do this, functional design tools have what is called a functional engine. It sits on top of the various
modeling kernels and technologies and uses 2D and 3D schematics to create 3D geometry that is editable
and also a digital prototype, i.e., a model that can be validated for form, fit, and function. Complete automation
of designs will probably never happen, but the number of cases that are targets for automation far exceeds
those that are not. Simple examples come from shafts, pulleys, and transmissions. More complex examples
come from conveyors, drive trains, and wiring and piping systems. Their functional requirements can be
captured and the rules that govern them are well understood or easily customized.
Thus, the functional approach captures real-world design intelligence earlier in the cycle because design
elements are active, not static. The elements reflect the behavior of parts they represent, including
relationships to other parts. For example, when tools in the software build torque and speed characteristics
into a gear, the component knows it must interact with another gear — it is not just a disk with a certain
number of teeth and a set of dimensions.
Functional design lets users generate parts from real-world inputs such as speed, power, and material
properties. Simulation in the software continually computes dynamic operating conditions. This lets users, at
any stage of the design, size motors, select actuators to sustain certain loads, and analyze positions,
velocities, accelerations, and loads that affect each component in a mechanism. The software also replaces
abstract entities such as edge constraints with functional, real-world constraints in the form of sliders, ball
joints, and hinges. Engineers, thus, can solve engineering problems early on, with the simplest representation
— sometimes a 3D model, sometimes a sketch. Once the problem is solved, the software generates the
correct geometry.
Functional design brings exciting changes to the CAD industry. The next 10 years will bring even more
change. By then, 3D design tools will be used in all aspects of manufacturing by tens of millions of users
worldwide to rapidly validate form, fit and function using digital prototypes. This future vision requires that
design-software developers introduce functional design tools that let users focus on problems they’re trying to
solve. autodesk.com
Digital prototypes such as the hydraulic power mechanism helped automate the design of a seaway lock system for the Saint Lawrence
Seaway.
An aerial view of the Saint Lawrence Seaway shows the modernized lock system Bosch
Rexroth Canada developed using digital prototypes developed using digital prototypes .
3 Functional engineering for the process industry, functional objects and the documents.
For the sake of an argument we could say functional engineering is part of the work done during the
conceptual engineering phase. One could also argue that functional engineering is the similar to the
things we do during conceptual engineering, such is correct if it is only limited to pure engineering.
But when the initial project phase starts many other studies have to be made and the negotiations with
the authorities do start. Functional engineering is performed by the use of functional objects so without
materializing them into the physical object.
This is aligned to computer programming projects, a business that after initial problems introduced this
term, the underlying theory and implementation was used for many years, sometimes a bit sloppy.
Difference between process design and functional design.

(Extract from “Functional and Physical Objects- the big picture”, Hans Teijgeler on ISO 15926)
For critical equipment a spare can be purchased at the same time, or later, against the same
specification. This spare unit can be put in the warehouse or can be installed as an "installed spare", with
or without automatic switch-over (below the resulting numbering with A and B will be addressed). If, for
some reason, the supplier cannot deliver, e.g. because of bankruptcy, another MaterializedPhysical
Object is purchased from another supplier against the same specification of the class P101.
In case an installed spare pump is required, we usually number them with A and B, here: P101A and
P101B. That means that there are two classes that happen to have the same class definition, except for
their service description. That spare pump did not come into existence for process technical reasons, but
for business reasons (we want a maximum uptime of the plant).
Another case of A and B we may find in certain control valve configurations. For the process engineer
there may be, at a particular point in the plant design, just one control valve, say FV5. Based on the heat
and material balance he then may define a minimum and maximum flow that are far apart from each
other, i.e. a large rangeability is required, larger than any single control valve can possibly deliver
because of leakage. The control systems engineer (I used to be one for many years) then specifies two
control valves, one with linear and one with equal percentage characteristics, and with split-range
positioners.
What does that mean? From a process design point of view (i.e. the activity model shown on the Process
Flow Diagram) we have the instance of ClassOfFunctionalObject ("Functional Unit") named FV5. The
class definition of FV5 is mainly in terms of process data. The control systems engineer then designs a
"Technical Solution" for FV5, here consisting of a set of interconnected things. This technical solution in its
entirety still is a class, and is shown on a P&ID. This technical solution class is a subclass of FV5, it
inherits the class definition of the latter.
In that technical solution we find two control valves, say FV101A and FV101B. Unlike the P101 example
these two valves are completely different from each other, and are specified on two different
specifications/data sheets. Without the process and control interconnections those two valves would not
be able to do what FV5 requires. That is why I said that the class definition of any plant item must include
data about its place and role in the plant. That sets these classes apart from those defined by standard-
ization bodies and suppliers, because these are only focussing on the object itself, detached from any
plant context (they may use a hypothetical set of "standard" process conditions for their class definition).
A peculiar example of my thesis, that tag numbers are for classes, is the pressure gauge. There are plant
owners that want them to be tagged like any other instrument item, such as PG-101, PG-102, etc, but
there are also plant owners that want ALL gauges with the same range tagged with that range, e.g. all
pressure gauges with a range of 0-10 barg are to be tagged PG10. They are then considered to be
interchangeable commodity items. For special gauges, like ones with a diaphragm seal, a special
variation on that numbering system is prescribed
FEED, Front End Engineering and Design and Functional Engineering

Total Project coverage from Front End Engineering and Design (FEED) through Detailed Design through
Start-Up and Commissioning. Projects include both grassroots and revamps.
Provide front end engineering design (FEED) definition and advanced procurement services for
ConocoPhillips-operated Jasmine Area Development project (Jasmine) in the North Sea. The contract
also includes an option for the detailed engineering.
Functional Engineering is not the same as FEED, but forms, or can form the initial part of the Feed
A PFD, a thing, type of document or drawing that we all recognize is a functional document anyhow.. But
not in detail, as unfortunately the PFD’s are not well defined in the Process Industry because different
slang in contents and symbols, this regardless the new standards as there are:
- ISO 14618.Symbols of chemical apparatus and equipments
- ISO/DIS 10628-2 Diagrams for the chemical and petrochemical industry -- Part 2: Graphical symbols
- ISO/WD 15519-2 Specifications for diagrams for process industry -- Part 2: Measurement and control
- ISO/CD 14084-1 Process diagrams for power plants -- Part 1: Specification for diagrams
- ISO/WD 14084-2 Process diagrams for power plants -- Part 2: Graphical symbols do not improve yet)
- ISO/IEC 81346 series: Industrial systems, installations and equipment and industrial products - Structuring
- principles and reference designation,: IEC 81346-1 Part 1: Basic rules, and IEC 81346-2 Part 2: Classification
- of objects and codes for classes.
To many standards, the precursors are still valid and used, as well as multiplied by their all the
dialects. The heat and material balance goes together with the PFD and is regarded to be a functional
document as no brands makes and types are part of heat and material balance, the H&M B
PFD - Process Flow Diagram
The next step in detailing the engineering work, results in, amongst others producing the P&ID’s, (no
brands makes and types are indicated) so this seems to be a functional document.
Piping and Instrumentation Diagram - a family of functional one-line diagrams showing hull, mechanical
and electrical (HM&E) systems like piping, Equipment Data sheets, EDS
The Functional Logic Diagrams the FLD’s in short, that makes use some of elementary Function Blocks
are over the past 30 years as indicated from a simple symbol on the P&ID have slowly moved to separate
documents. Because safety regulations, but also the more complex process operation due to demand for
higher production and the limitations we got from the environmental regulations, the complexity has
increased dramatically.
See logsim.cadview.nl/downloads/Product_Presentation_auto.pps
In parallel we see in an other aspect of Process Automation (also referred to as I&C, Process Control or
Instruments)we have Control diagramming, but in this Control series it also should start far from concepts
with a performer information (independent solutions brands makes and types are indicated so this seems
to be a functional document).
So we have Functional Control Diagrams (FCD’s) that makes use of a larger set of elementary Function
Blocks also specified in a number of standards, some public but many supplier standards.
Also here safety regulations, but also the more complex process operation due to demand for higher
production and the limitations we got from the environmental regulations, the complexity has increased
dramatically. SAMA DIAGRAMS FOR BOILER CONTROLS
The (FSFC) Functional Sequence Flow Chart, the standard known as IEC 60848: GRAFCET
Specification Language for Sequential Function Charts describes the functional design of Batch
processes or sequences (automatic or not) for start up, product change over, regeneration and
shut down.
Intelligent planning of Grafcet charts Next generation of industrial automation
Functional Mechanical Engineering ) Functions and Functional drawings do exist, no

Functional Electrical Engineering ) descriptions of work or contents
Functional Civil and Structural Steel Engineering) Functional engineering documents to be added
Others ??????
4 Functional engineering for all engineering disciplines in more detail
In this chapter we will discuss the records of the work, the functional engineering documents, for all
engineering disciplines involved in more detail by giving examples from different standardization bodies.
4.1 The Process Flow Diagram - PFD, a schematic illustration of the system
A Process Flow Diagram - PFD - (or System Flow Diagram - SFD) shows the relationships between the
major components in the system. PFD also tabulate process design values for the components in different
operating modes, typical minimum, normal and maximum. A PFD does not show minor components, piping
systems, piping ratings and designations.
A PFD should include:
 Process Piping
 Major equipment symbols, names and identification numbers
 Control, valves and valves that affect operation of the system
 Interconnection with other systems
 Major bypass and recirculation lines
 System ratings and operational values as minimum, normal and maximum flow, temperature and pressure
 Composition of fluids
This figure depict a small and simplified PFD:
System Flow Diagrams should not include:

 pipe class
 pipe line numbers
 minor bypass lines
 isolation and shutoff valves
 maintenance vents and drains
 relief and safety valve
 code class information
 seismic class information
 Example - Process Flow Diagram

 Piping & Instrumentation Diagram - P&ID?
From Controls Wiki
Jump to: navigation, search
Piping and Instrumentation Diagrams (P&ID’s) use specific symbols to show the connectivity of equipment,
sensors, and valves in a control system. The following sections will outline general information about P&ID’s
that is necessary to know before trying to draw one.
P&ID vs. PFD

P&IDs may often be confused with PFD’s, or process flow diagram. P&ID’s and PFD’s generally utilize the
same notation for equipment. However, they serve different purposes and provide different information. The
purpose of a PFD is to show exactly what a process does during operation, and a P&ID shows all
controllers, valve types and the materials that are used in construction. A PFD shows the connectivity and
relationships between the major equipment and materials in a process. However, it also includes tabulated
design values such as normal, minimum, and maximum operating conditions that a P&ID does not contain.
A PFD does not include minor piping systems or other minor components that a P&ID typically includes.
The difference between P&ID’s and PFD’s is that P&ID’s typically include more information regarding piping
and safety relief valves than process flow diagrams. P&IDs do not contain operating specifications that
PFD’s contain, such as stream flows and compositions. It is important to note that differences between
PFD’s and P&ID’s will vary between institutions. Most corporations maintain designated standards to create
and modify the documents. Both PFD’s and P&ID’s are controlled documents and need to be maintained
with a document control procedure. To see an industrial example of PFD vs P&ID refer to,. PFD/PID
industry example Wiki Page are given below
From ControlsWiki
Written by: Matt Robinson, JT Rumble, Chris Larson
Process Flow Diagrams vs. Process and Instrumentation Diagrams
Process Description
This PFD/P&ID is taken from a brewery which is planned to produce 100,000 bottles a day of beer. This
section includes boiling and fermentation. The process starts by using steam to boil the beer in KB-301, which
sterilzes the beer. Next, the beer is pumped into a whirlpool filter where impurities are removed. The beer is
then cooled to 15 degrees C, using a heat exchanger E-306. Once the beer is cooled, it is sent to the
fermentation tank, TK-307. Here yeast is added, which meta blozies sugar in the beer into alcohol and carbon
dioxide. After a couple days, the beer is sent to a maturation tank, TK-314. The beer spends about 4 days in
this tank, before it is clarified and bottled.
PFD
A PFD for the process is here:
Image courtesy of John Trumble, University of Michigan
The PFD contains stream compositions on the border, instead of the equipment. The overall flow rates
through each stream can be seen on the PFD also.
Mass and energy balances
This document presents only the most relevant stream results. In ProSimPlus, mass and energy balances
are provided for every stream. Results are also available at the unit operation level (result tab in the
configuration window).
A process flow diagram (PFD) is a diagram commonly used in engineering to indicate the general flow of
plant processes and equipment. The PFD displays the relationship between major equipment of a plant
facility and does not show minor details such as piping details and designations. Another commonly-used
term for a PFD is a flowsheet. Typically, process flow diagrams of a single unit process will include the
following:
 Process piping
 Major bypass and recirculation lines
 Major equipment symbols, names and identification numbers
 Flow directions
 Control loops that affect operation of the system
 Interconnection with other systems
 System ratings and operational values as minimum, normal and maximum flow, temperature and
pressure
 Composition of fluids
Process flow diagrams generally do not include:

 Pipe classes or piping line numbers
 Process control instrumentation (sensors and final elements)
 Minor bypass lines
 Isolation and shutoff valves
 Maintenance vents and drains
 Relief and safety valves
 Flanges
Process flow diagrams of multiple process units within a large industrial plant will usually contain less detail
and may be called block flow diagrams or schematic flow diagrams.
Other items of interest
A PFD can be computer generated from process simulators (see List of Chemical Process Simulators),
CAD packages, or flow chart software using a library of chemical engineering symbols. Rules and symbols
are available from standardization organizations such as DIN, ISO or ANSI. Often PFDs are produced on
large sheets of paper. PFDs of many commercial processes can be found in the literature, specifically in
encyclopedias of chemical technology, although some might be outdated. To find recent ones, patent
databases such as those available from the United States Patent and Trademark Office can be useful
4.2 P&ID General Information
A P&ID for the process is here:
Image courtesy of John Trumble, University of Michigan
The first difference to notice on the P&ID from a PFD is the border template. Instead of stream compositions
being listed, there is a list of the equipment, along with a key for abbreviations used on the diagram. On the
diagram itself, there are valves and controllers which are not present on a PFD. For example, V-5 is the valve
right before the boiler or the pressure controller PC 1, which is represented by a circle located on the boiler.
These devices are also not on the PFD.
Retrieved from "http://controls.engin.umich.edu/wiki/index.php/PFD/PID_industry_example_Wiki_Page"
Nuclear industry: The leadership and significant elements of this team will be based in London to ensure all
necessary close coordination with EDF organizations. The PMO will include a multi-disciplinary technical
team, providing a range of design services to the new Nuclear Power Stations, in particular ‘Balance of Plant
related systems. The Process, Mechanical, Electrical & Civil Structural Discipline Leads will be responsible for
developing a consistent approach across the various offices for all tasks undertaken for the Project. These
tasks include the production of Level 2 (or ‘Functional’) design information including the preparation of a
‘System manual’ (which includes development of P&ID’s, e.g., process descriptions, control philosophy and
basis of design information), plant/ equipment data sheets and schedules associated technical enquiry
specifications (to be issued by the client) for the development of the detailed engineering designs by the
supply chain, evaluations of tenders and provide support to the Client in the review, checking and approval of
sub-contractor detailed manufacturing/constructional engineering designs, calculations, specifications and
drawings. In addition to technical support, the role will also involve assistance in the development of the team,
project and bid management as well as managing client relationships.
A P&ID to
Inhalt und Aufgabe des RI-Fließbilds
Das Grundfließbild ist das Hauptdokument für die Vorplanung (Basic Engineering) einer Anlage und legt die
Aufgabenstellung für die einzelnen Fachabteilungen fest. In der Entwurfphase werden Stoff- und/oder
Energiemengenbilanzen und Verfahrensfließbilder erstellt. Hieraus werden die RI-Fließbilder entwickelt.
Behälter, Apparate, Pumpen, Verdichter, Wärmetauscher usw. werden symbolisch (nicht maßstäblich)
dargestellt. Dann erfolgt die Verbindung mit den Rohrleitungen. Alle Linien, die eine Rohrleitung darstellen
sollen, werden gekennzeichnet mit Nennweite, Nenndruck, Medium, Rohrklasse und einer
Identifikationsnummer.
Ähnlich ist es für die Festlegung der Mess- und Regeltechnik. In genormten Symbolen (Kreise oder Ovale)
wird festgelegt, wo und was gemessen oder geregelt werden soll. Auch diese erhalten eine
Identifikationsnummer für die weitere Bearbeitung. Regelkreise werden mit Wirklinien dargestellt (vom
Einbauort der Messung bis zum Stellglied).
Das Diagramm enthält folgende Informationen:
 Art und Bezeichnung der Apparate und/ oder Maschinen

 Rohrleitungen, Armaturen mit Nennweiten, Druckstufen, Werkstoffen
 Antriebe
 Aufgaben der Einrichtungen zum Messen, Steuern, Regeln
Zusatzinformationen können angegeben werden, z. B. Höhenlagen der Apparate, weitere Werkstoffe,

weitere Bezeichnungen (z. B. von Armaturen).
Nach der Genehmigung der RI-Fließbilder durch den Kunden (und gegebenenfalls auch durch Behörden)
beginnt die Detailplanung (Detail Engineering).
RI-Fließbild nach ISO Standard (R+I Schema)
In Deutschland werden RI-Fließbilder nach DIN EN ISO 10628 dargestellt. Weitere Rohrleitungssymbole
können der DIN 2429 entnommen werden. Wirklinien von Steuer- und Regelungsorganen werden nach EN
62424 bzw. ISO 3511 dargestellt.
Kennbuchstaben und Kennzeichnung
Für die Kennzeichnung von Mess- und Regelstellen werden die Normen EN 62424/ISO 3511 bzw. ISA S5.1
angewendet.
Die umfassende Kennzeichnung aller Apparate, Rohrleitungen und Instrumente in industriellen Systemen
wird in der EN 61346 (Industrielle Systeme, Anlagen und Ausrüstungen und Industrieprodukte –
Strukturierungsprinzipien und Referenzkennzeichnung) bzw. in der nationalen Norm DIN 6779
(Kennzeichensystematik für technische Produkte und technische Produktdokumentationen) beschrieben.
Dort sind alle Mess- und Regelstellen der Hauptgruppe B zugeordnet. Für die Untergruppen werden auch
die Kennbuchstaben nach ISO 14617-6 verwendet.
Im Bereich des Kraftwerksbaus werden die Bauteile (Apparate, Rohrleitungen und Instrumente) nach dem
Kraftwerk-Kennzeichensystem (KKS) bzw. nach dem neuen System zur Kennzeichnung (Codierung) von
Kraftwerks-Komponenten (RDS-PP) gekennzeichnet.
Mess- und Regelstellen
Die Mess- und Regelstellen werden nach ISO 3511 dargestellt. Von ISO 3511 existiert keine deutsche
Übersetzung. Die früher gültige DIN 19227-1 wurde im Januar 2010 durch die Europäische Norm EN 62424
ersetzt.
Beschreibung der Kürzel
Messstellen wurden nach DIN 19227-1 mit einem Kürzel bezeichnet, das aus einem oder mehreren
Buchstaben sowie einer Kennzeichnung (üblicherweise einer Ziffernfolge) besteht. Die Buchstabenfolge
gibt Auskunft über die Funktion und Aufgabe der Messstelle und besteht aus einem Erstbuchstaben,
möglicherweise einem Ergänzungsbuchstaben und möglicherweise einem oder mehreren
Folgebuchstaben.
EN 62424 verwendet statt „Erstbuchstabe“ den Begriff „PCE-Kategorie“, Ergänzungs- und Folgebuchstaben
(die ohnehin keine Überschneidung aufweisen) gehen in der sogenannten „PCE-Verarbeitungsfunktion“ auf
(PCE = Process Control Engineering). Die aktuelle Norm übernimmt zwar den Großteil der
Buchstabenbedeutungen, fügt jedoch auch neue hinzu und definiert einige bestehende um.
Man kann und will mit diesem Bezeichnungssystem nicht alle Details festlegen. Zusammen mit der
Identifikationsnummer ist eine Referenz zum Instrumentdatenblatt gegeben. Dort kann man Messbereich,
Höhe der Grenzwerte, Details zum Einbau und vieles mehr genau nachlesen.
Erstbuchstabe
 D Dichte (Density)
 E elektrische Größen (Electricity)
 F Durchfluss (Flow)
 H Handeingabe oder Handeingriff (Hand)
 K Zeit (Schedule)
 L Füllstand (Level)
 M Feuchte (Moisture)
 P Druck (Pressure)
 Q Qualität (im Sinne von Eigenschaft eines Stoffes) (Quality)
 R Strahlung (Radiation)
 S Geschwindigkeit oder Drehzahl (Speed)
 T Temperatur (Temperature)
 V Viskosität (Viscosity)
 W Masse (Weight)
Ergänzungsbuchstabe
 D Differenz (Difference)
 F Verhältnis (Fraction)
 Q laufende Summe/ Integral (z.B. bei Gesamtdurchfluss) (Quantity)
Folgebuchstabe
 A Alarm (Alarming)
 C Regelung/Steuerung (Controlling)
 I Anzeige (Indicating)
 R Speicherung/Aufzeichnung (Recording)
 S Schaltung (Switching)
 Z Noteingriff (Emergency)
 + oder H Obergrenze (High)
 - oder L Untergrenze (Low)
Beispiele
 PI512: Druckanzeige
 PD512: Druckdifferenzanzeige
 PICA+512: Regelung des Drucks mit Alarm bei Überschreitung eines Grenzwerts
 F100: aktueller Durchfluss
 FQ100: durchgeflossene Gesamtmenge
 TIRCSHAHL618: Temperaturregelung mit Anzeige, Speicherung, Schaltung bei Erreichen des
oberen Grenzwertes und Alarm bei Erreichen des oberen und unteren Grenzwertes
Programme zur RI-Fließbild-Erstellung
Für die Erstellung von R&I-Fließbildern im Anlagenbau werden zunehmend Programme aus dem Bereich
des computer-aided engineering (CAE deutsch: Computerunterstützte Planung) eingesetzt. Die
Applikationen stellen die Fließbildsymbole in genormter Größe und Strichstärke zur Verfügung und
unterstützen bei deren Platzierung. Bei der Kennzeichnung werden Listen bereitgestellt und es wird
sichergestellt, dass das richtige Kennzeichenformat eingehalten wird (besonders wichtig bei KKS). Die
Daten werden meist zentral in Datenbanken gespeichert. Dadurch ist eine spätere Auswertung der Daten
möglich.
Übersicht anzuwendender Normen
Stand: Februar 2010
 EN ISO 7200 (alt DIN 6771-1) Dokumentenschriftfeld

 EN ISO 10628 (alt DIN 28004) Fließschemata für verfahrenstechnische Anlagen - Allgemeine
Regeln
 EN 60617 (alt DIN 40900) Graphische Symbole für Schaltpläne
 EN 62424 (alt DIN 19227-1) Darstellung von Aufgaben der Prozessleittechnik - Fließbilder und
Datenaustausch zwischen EDV-Werkzeugen zur Fließbilderstellung und CAE-Systemen
 ISO/TS 16952-1 (alt DIN 6779) Technische Produktdokumentation - Referenzkennzeichensystem -
Teil 1: Allgemeine Anwendungsregeln
 ISO 3511 Messen, Steuern, Regeln in der Verfahrenstechnik
 DIN 2429-1 Graphische Symbole für technische Zeichnungen; Rohrleitungen; Allgemeines
 DIN 2429-2 Graphische Symbole für technische Zeichnungen; Rohrleitungen; Funktionelle
Darstellung
 DIN 2481 Wärmekraftanlagen; Graphische Symbole
 DIN 19227-2 Leittechnik; Graphische Symbole und Kennbuchstaben für die Prozeßleittechnik;
Darstellung von Einzelheiten
R&I-Fließbilder nach amerikanischem Standard
RI-Fließbild nach amerikanischem Standard
Unterschiede zur DIN
In den Vereinigten Staaten basieren R&I-Fließbilder auf dem Angloamerikanischen Maßsystem. Symbole
werden nach dem amerikanischer Standard ISA dargestellt.
Diese Norm weist keine so strenge Systematik auf wie DIN EN ISO 10628. Symbole für Apparate und
Ausrüstung werden eher nach ihrem eigentlichen Aussehen dargestellt. Dies führt unter anderem dazu,
dass die Symbole für Kreiselpumpe und Radialgebläse sich sehr ähneln. Durchgangsarmaturen werden
ähnlich wie in der ISO-Norm nach ihrem Funktionsprinzip explizit dargestellt, bei Eckarmaturen und
Mehrwegearmaturen wird jedoch auf eine genaue Spezifizierung verzichtet (keine Symbole für Eckhahn,
Eckventil).
Instrumente werden nicht zusammengefasst dargestellt, sondern explizit nach Einzelfunktionen

aufgesplittet.
Beispiel für eine Durchflussmessung mit Anzeige, Regelung und Aufzeichnung:
 ISO: FIRC
 ISA: FT-FI-FR-FC
In technischen Zeichnungen internationaler Projekten kommt es oft zu vermischten Kennzeichnungen.
Kennzeichen-Aufbau nach ISA 5.1
Erster Buchstabe
 A- Analyse
 F- Durchfluss (flow)
 P- Druck (pressure)
 T- Temperatur
 Z- Position
Zweiter Buchstabe
 T- Übertragung (transmitter)
 R- Aufzeichnung (recorder)
 I- Anzeige (indikator)
Beispiel
Durchfluss-Übertragung von Regelkreis 1000A
Funktions-Identifizierung
 Erster Buchstabe F
 Zweiter Buchstabe T
Regelkreis-Identifizierung
 Regelkreis Nummer 1000

 Suffix A
FT 1000A
Weitere Beispiele
 PT 1000A Druckübertragung 1000A

 PI 1000A Druck Anzeiger
 PIC 1000A Druckregler mit Anzeige PID Regelkreis
 PIRC 1000A Druckregler mit Aufzeichnung und Anzeige
Information Incorporated in P&ID’s
The following information is given on a P&ID that is not explicit on a PFD:
 ALL valves and valve types

 Controllers present
 Controller architectures
 Pipe diameters, materials of construction, and insulation properties (including minor piping systems)
 Equipment materials of construction
Uses of P&ID’s
 Develop operational methodology

 Develop safety philosophy and safeguards
 Develop control philosophy
 Serve as a basis for control programming
 Serve as a communication document for how the process works
 Serve as a basis for equipment design, pipe design, estimating cost, purchasing
 Use for evaluation of construction process
 Train employees
 Serve as a conceptual layout of a chemical plant
 Provide a common language for discussing plant operations
Characteristics of P&ID’s
 Grouped by specific section of plant

 Show the connections between all the sensors and actuators
 A general schematic - NOT a layout and NOT to scale. It should be noted that P&IDs do not
specifically imply the following: same elevation of equipment, relative sizes, where valves are located
on the equipment, how close equipment is to each other, and impeller types/location. They are also
not the same as control or incidence diagrams. This type of information can be seen in either a plant
layout drawing (can be either satellite view, showing distance between units, or a slice of building,
showing height of units) or construction drawings, such as plant blueprints.
 Must be clear and uncluttered
 Must be systematic and uniform. P&IDs are used extensively in industry to document plant
information. These documents need to be easily read by anyone working within the company, and
easily explained to anyone else. OSHA audits can occur anytime and it is imperative that operational
information can be provided to the auditor when requested. Without standard notation, it would be
very difficult to go from plant to plant within your company and understand the P&IDs.
 Are generally highly confidential and have restricted access, as they can be used to replicate a
process
What A P&ID Is Not
 Not an architectural diagram of a process (should show the flow of material across the plant floor
 sensors and actuators, not necessarily corresponding to a 3D location)
 Does not need to be drawn perfectly to scale
 Does not imply any relative elevations
 Do not need manual switches
 No actual temperature, pressure, or flow data
 Leave out any extensive explanations
What A P&ID should include
 Instrumentation and designations
 Mechanical equipment with names and numbers, and their specifications such as material, insulation,
maximum flow rate, working pressure and temperature, maximum power etc.
 All valves and their identifications
 Process piping, sizes and identification
 Miscellaneous - vents, drains, special fittings, sampling lines, reducers, increasers and swagers
 Permanent start-up and flush lines
 Flow directions
 Interconnections references
 Control inputs and outputs
 Interfaces for class changes
 Vendor and contractor interfaces
 Identification of components and subsystems delivered by others
 Intended physical sequence of the equipment
P&ID Revisions
 Revisions should be clearly identified

 Regularly issued to all related employees at each significant change to the process, as well as at
 benchmark points
 If small changes are made that don't warrant a completely new revision, "red pencil" additions are
 generally accepted between issues
 15-20 revisions are typical during process design
 All revisions need to be communicated to EVERYONE so that only the latest revision is used. This is
critical in order to avoid serious (not to mention expensive) construction mistakes. (Typically outdated P&ID
is discarded to avoid confusion)
How do you generate a P&ID?
P&IDs can be created by hand or computer. Common programs, for both PC and Mac, that create P&IDs
include Microsoft Visio (PC) and OmniGraffle (Mac). For creating a P&ID by hand or on a computer, please
refer to the P&ID Standard Notation Wiki Page for standard equipment notation as well as computer
templates.
[Needs link to other page]
Retrieved from "http://controls.engin.umich.edu/wiki/index.php/PIDGeneralInformation"
4.3.Functional Equipment Data Sheet (Process and mechanical to complete)
HEAT EXCHANGER DATA SHEET

CLIENT: DATA SHEET NO.
JOB NO.: REVISION:
LOCATION.: DATE:
SPECIFICATION NO.: ENGINEER:
P.R. NO.:
Service: Equipment No.:
Manufacturer: No. Required:
Supplier: Applicable to: Model No.:
TYPE OF EXCHANGER
FLUID 1 FLUID 2
FLUID CIRCULATED
VAPOR (LB/HR)
LIQUID (LB/HR)
VAPOR CONDENSED (LB/HR)
LIQUID VAPORIZED (LB/HR)
LIQUID SPECIFIC GRAVITY
VAPOR MOLECULAR WEIGHT
VISCOSITY (cP)
SPECIFIC HEAT (BTU/LB F)
THERMAL CONDUCTIVITY (BTU/HR FT F)
LATENT HEAT (BTU/LB)
TEMPERTURE (F)
In: Out: In: Out:
OPERATING PRESSURE (PSIG):
PRESSURE DROP ALLOWABLE (PSI):
FOULING RESISTANCE (SQ.FT HR F/BTU):
HEAT TRANSFERRED (BTU/HR)
CONSTRUCTION:
TEMA CLASS:
SHELL AND TUBE CONFIGURATION:
FRONT END HEAD TYPE:
SHELL TYPE:
REAR END HEAD TYPE:
DESIGN PRESSURE (PSIG):
DESIGN TEMPERATURE (F):
TUBE MATERIAL:
SHELL MATERIAL:
CORROSION ALLOWANCE (IN):
CODE REQUIREMENTS:
NOTES:
4.4.Functional documents for Process Control
A.2 2.0 A 0.1 Introduction
The existing engineering for Instrument and Control is nowadays concentrated in three parts; first things
that are indicated on P&ID's, secondly the engineering of the process automation systems and third the field
instrumentation including the connections to the control systems and the process.
One of the major burdens in our I&C trade is in the life cycle of the Process and Power Plants mastering the
configuration (the application or software engineering) of the Process Automation Systems as the DCS,
PLC and web-structures as they are emerging these days
A.2.2.0 A .3 Functional Control Diagramming

A.2.2.0.a 3.1 Introduction
The design, recording of the design, the possibility of object oriented simulation of a functional design, the
object-oriented configuration control equipment (DCS, PLC, field bus equipment) and the documentation of
the different steps is an activity requiring new attention.
Within the process industry and her engineering environment many different work processes are common
to us. In many cases they are not clearly defined for the people involved, on the contrary implicit it is taken
for granted that in the end the problems disappear.
A.2.2.0 A 3.2 Analysis

Contrary to logic diagramming, as mainly established by the use of IEC 61131-3, ways to uniform similar
control diagramming hardly exists. The acceptance and the use of this of functional control diagrams is
lower as to the Logic Diagramming methods.
The object oriented graphical configuration as given by the new generation DCS's however, open
possibilities to follow similar working methods as discussed for logic diagrams before.
So it seems indeed possible to introduce a wider automation degree in the design and configuration
processes. The objects as defined in the IEC 61131-3 are the same as to be used for logic diagramming in
the process and power industry according to IEC 60617-12. The IEC 61131-3 includes most of the Function
Blocks for computing purposes as defined in the ISA S5.1.
Therefore also the applicable tooling is not directly available as we mentioned before.
The use of the VDI/VDE 3696 as a standard for neutral configuration offers a possibility.
The objects as defined in the IEC 61131-3 are the same as to be used for logic diagramming in the process
and power industry according to IEC 60617-12.
The reason to automate this process is similar as to the reasons mentioned before.
At the moment we observe lack of information reflecting the in and outs why a certain control architecture is
chosen. To recover the intended control architecture from the documentation of earlier DCS projects as
done in the past 20 years is usually a very difficult task. Mainly because the self-documentation capabilities
of these systems where very weak.
So also for improvement of back documentation the use of Functional Control Diagrams is useful.
A.2.2.0 A 3.3 Objective

The design, recording of the design, simulation of the design, the rule-based translation of the functional
design (as recorded in functional logic diagrams) to system logic diagrams as they are running on the
performers (as there are the configurable PLC and DCS) and the applicable documentation needs to be a
more fluent activity.
At the same time the diagrams as generated in the logic solver should look the same as the basic diagrams
they are extracted from, being the functional logic diagrams
A.2.2.0 A 3.4 The current situation

As a spin-off from the STEP tool for FL&CD we at DSM have developed in co-operation with designer of the
STEP FL&CD tool Roel Murris of the MI2 company a tool that assist us in drawing the functional control
diagrams.
From the STEP library the function blocks are generated in a Visio format, actually it results in a special
Visio stencil for this purpose. In a later stage we think to complete the tool so we can transfer the control
architecture automatically to the target systems using the STEP technology.
A.2.2.0 A 3.5 Current actions
The function blocks are in ISO 15926, the in/and outputs of the function blocks are waiting for approval via
the maintenance team and the signals between the connections that are allowed (no binary connected to a
analog) to be made, are in some trouble because the difference in the model ECM3 we started with and the
model of ISO 15926 part 4, so we have a problem with the model and have find a workaround
From A.4.2-2.1 p1 Produce and record the control architecture (FCD)
INPUT Process OUTPU

T
technology
4.2-1.2 p2
contr architec
INPUT Produce OUTPU

DESIGN
RULES T
FCD
4.2-2.1 p2
DESIGN
RULES
Different methods are used to record the required or functional control architecture.
1. Minutes of P&ID discussions

One of the ways is to record this in the minutes of P&ID discussions in addition to proper indication of the
required control architecture on the P&ID.
2. Narratives / Control notes
Narratives sometimes as textual note for each control application are usually not sufficient to define the
architecture.
Narrative as a document that records all information (including the graphical representation) of a control
loop or system may fulfill the requirements.
Such a document may contain the purpose of such control, the functional or block diagram, the settings of
limits, selectors, switches and setpoints.
3. System control diagrams

Some control systems are able to generate to control architecture of their own environment. Usually vendor
specific information is added to the diagrams, so the diagrams can only be red by process control engineers
who are familiar with such specific control system.
4. System control language

For some process control systems the control language is readable for non specialist, at the same time we
observe also vendor specific information so in general they are not very well suited to others than the
process control engineers of the plant system involved
5. Functional Control diagrams

Functional control diagrams reflecting only the needed information to understand as the word says the
function of the control loop or collection of loops are a good means of communication.
4 EXAMPLEFL&CD(IEC61131-3 / 61499 / /61804)
23
2 FT2
IN_A
SIGID QPV
SIGTYP ENO
SIGMIN
SIGMAX
CJCOR
LINTYP
PVMIN
PVMAX
PVUNIT
EN
<tekst>
FFC2 FV2
FT1 FFX1 C OUT_A
IN_A MUL PV QMV MV ENO
SPINT E MVMIN
SIGID QPV U1 QV SPEXT SP MVMAX
SIGTYP ENO U2 ENO SPEXTON QSPINT MVUNIT
SIGMIN U3 SPTRON QMVMAN REVERSE
SIGMAX U4 SPLL QMVEXT SIGID
CJCOR U5 SPHL QSPLL SIGTYP
LINTYP U6 SPDRON QSPHL SIGMIN
PVMIN U7 SPURON QMVLL SIGMAX
PVMAX U8 SPDR QMVHL EN
PVUNIT EN SPUR ENO
EN DEADZ <tekst>
<tekst> REVERSE
<tekst> DMODE
IRESET
PON
ION
DON
KP
TI
FFY1 TD
T1TOTD
CONST MVMANON
MVMANFC
QV MVEXTON
MVTRON
<tekst> MVMAN
MVEXT
MVLL
MVHL
MVDRON
MVDR
MVUR
ZON
Z
EN
<tekst>
DSMCorporate Safety, Health, Environment &Manufacturing
Global ManufacturingCompetence Center - Process Control- Hindrik Koning
“Harmonizing standardizationonData Integrationinthe life cycle of the Process andPower plants.”
Date2005-09-21
From A.4.2-3.2 p 3 Functional Logic Diagramming
INPUT Process OUTPU

T
technology
4.2-1.2 p2
contr architec
INPUT Produce FLD’s OUTPU

DESIGN
RULES T
4.2-3.2 p 3
DESIGN
RULES
A.2.0 A 5.1 Introduction
The design, recording of the design, the possibility of object oriented simulation of a functional design, the
object-oriented configuration of logic solvers (DCS, PLC, relays, solid state) and the documentation of the
different steps is an activity requiring new attention.
Within the process industry and her engineering environment many different work processes are common
to us. In many cases they are not clearly defined for the people involved, on the contrary implicit it is taken
for granted that in the end the problems disappear.
Binary logic diagrams are made on one hand to record the functional safety aspects of a design as given in
the applicable standards: IEC 61508 and IEC 61511.
On the other hand also non-safety related logical control are to be addressed.
Functional Logic Diagramming is a good means of communication between all of the people involved in the
entire life cycle of process plants, as there are chemical or process engineers, process operators and
supervisors, but also for maintenance engineers and technicians. But also in the designing, implementation
and test phases it helps in communication with suppliers and system integrators.
A.2.0 A 5.2 Analysis

In the recent years we can observe a growing similarity between the functional logic diagrams and the
graphical configuration possibilities for PLC's and nowadays also for DCS's. So it seems possible to
introduce a wider automation degree in the design and configuration processes. The objects as defined in
the IEC 61131-3 are the same as to be used for logic diagramming in the process and power industry
according to IEC 60617-12
This automation process is required because the amount and the complexity of logic design per plant are
increasing and at the same time the lead-time for project execution is reduced. The specialists required to
design functional logic diagrams are hard to find these days.
A.2.0 A 5.3 Objective
The design, recording of the design, simulation of the design, the rule-based translation of the functional
design (as recorded in functional logic diagrams) to system logic diagrams as they are running on the
performers (as there are the configurable PLC and DCS) and the applicable documentation needs to be a
more fluent activity.
At the same time the diagrams as generated in the logic solver should look the same as the basic diagrams
they are extracted from, being the functional logic diagrams
A.2.0 A 5.4 The current situation

Within DSM we started with Logsim in order to have ha tool that could simulate our functional logic
diagrams. There are many packages on the market that simulate the applicable PLC configuration part of
the functional logic diagrams. But part of the logical behavior is outside the PLC. It may be in the field, MCC
or other configurable systems. The maker of Logsim (Peter Schermann of Process Control Consultants)
was prepared to create, in addition to the objects required for PLC configuration as per given in IEC 61131-
3, the needed objects that define logic behavior outside the PLC as there are the sensors and actors we
know of.
This approach proved to beneficial. For the most difficult parts the simulation is presented on a beamer to
the audience. The people with different background that have to check the logic diagrams can easily follow
the conditions, the logical consequences of changes and follow in time the plant conditions . As from that
the design can be adapted, mistakes corrected, even before the design is handed over for the PLC and or
DCS configuration.
A.2.0 A 5.5 Current actions

Together with our partners we are working toward solutions to further engineering automation.
From a pure functional diagram, the control engineer decides where the logic has to run. From that a rule-
based translation to the target systems is required.
Focusing on the new performers of the control functions, as there are in remote I/O and the Field bus
applications, this approach seems tot be necessary.
In the mean time we at DSM modified the drawing methods for the functional control diagrams. We adapted
to symbology as per IEC 617-2, at the same time the drawings as made by hand or as produced by the
Logsim package are drawn in the same way as indicated on the engineering stations of our suppliers.
These are safety related PLC of HIMA, the DCS's of Fisher Rosemount Delta V control studio, and the
Honeywell Plantscape control builder. But also we take some actions to the control PLC’s of Siemens and
Modicon.
A.4.2.0 A Methods for recording binary logic for safety and non safety purposes
We zien om ons heen verschillende methoden om overzicht te behouden over de logica (Binary control of
interlocking voor niet veiligheids relevante toepassigen) en ESD logica voor de veiligheids relevante zaken.
1 Naratives
These global descriptions of a functional design are in many cases made by and issued by the process
departments of the plantowners, licensors and contractors. In some cases the switching point and tag-
nummers are storded in a database application. The transformation of this information to configuration of
the logic solvers is done by an other dicipline and the common communication is some proza. To solve the
communicationproblems scketches, thruth tablels or some cause and effect diagrams are added to the
narative.
2 Cause and effect diagrams

This is a kind of matrix with sensors in a (left) vertical column and the actors on the bottom row, this is a
very old method, > 50 yearsThe advantage is they look simple are quickly made and the sky is bleu.The
paper version (although electronically made) can not contain al the important information as it gives only the
relation between the cause (high pressure) and the required effect (close supply and open (a valve) to the
vent system Time aspects, start conditions, internal interlocks and time sequence can not be indicated. For
testing the logic/interlocking the Cause and effect diagrams are not suitable. But the lack of clear
understanding of or - and functions and the use of memory function blocks (internationally not always used
in logic diagramming) was felt a problem.
Analysis with a little dynamics had to eliminate the absence Delay Initiation of output (aanspreek-
vertragingen) Delay Termination of output (afval- vertragingen) and Pulse output (wispulsen0.
3 Uitvoeringsschema’s gemaakt met de PLC engineering stations
In the recent years vendors are referring to a type of logic diagrams that are not the functional logic
diagrams since only part of the circuit is show, only the PLC of DCS part With different kind of textual notes
one tries to incorporate the missing piece of as in the field or switch room. Or to hide it is not really correct,
finished or indicated Sometimes database generated drawings are used and some notes added by hand,
this will not improve the data base. The required data consistency is hampered in the beginning of the life
cycle of the process installation. De beoogde data consistencies wordt hiermee aan het begin van de
levenscyclus van het proces installatie al geweld aangedaan.
4 Pure Functional Logic Diagrams)
We have more drawing standards for this method. This is not about the symbols be used, But the way the
object are connected to reach a certain goal. Functional logic diagrams present an overview about all
relations from and to the chemical / physical process It contains the pure functional part of a chain 1
measuring (sensor), 2 solving the logic (logic solvers) and 3 correcting devices (the actors) Only the method
that clearly can indicate the cause to the effect (not the cause and effect diagram) no optimization of the
functional circuits is to be used. The pure logic diagram is not to show any indication of type of logic solvers
(as relays, In a pure logic diagram is no relation with the kind and type of intended logic solver, nor on way
will they be used
Theorem
None of these solutions is as good and clear as the functional logic diagram. Unfortunately not very many
people know how a clear functional logic diagram is about.
We notice in the work process from concept to implementation many nasty mistakes occur, mistakes that
have to do with the transformations based on fixed rules (out to be), where there is insufficient knowledge
with this rules. In one aspect these rules need to see our imagination
From the other side we need exclude these mistakes by smart rule based automation.
In the time frame after fixing the design up to and including the implementation and handover of the
installation can be shortened. This only can be reached if the time consuming working stroke by humans
is eliminated.
2.4.2.3 (Functional) Sequential Flow Charts and Batch
INPUT Process OUTPU

T
technology
4.2-1.2 p2
contr architec
INPUT Produce OUTPU
DESIGN
RULES Functional T
SFC’s
4.2-3.2
DESIGN
RULES
As it comes to Batch processes, we see proper definitions and engineering guides as given in the ANSI/ISA
S84.01-1995 . This ANSI/ISA standard did help us a lot in vocabulary, definitions and terminology for Batch
Processes and Equipment, the Batch Concepts and the Batch Control Activities and functions.
Formal recording of the Batch processes and the other time and or event driven designs is given in the IEC
60848 and used in the IEC 61131-3.p3/4/5 The spread of this recording method is however still limited as
well in functional engineering as well in the systems that are used as performers of the required functions.
Mainly because the process control systems as developed in the USA had hardly any graphical
programming capabilities. With the current system this is changed. All the major vendors for PLC and DCS
now support Sequential Flow Charts. Even the difference between the functional sequential flow charts and
the system sequential flow charts is less than the difference we observe between functional logic diagrams,
the functional control diagrams and the system logic and control diagrams. This has obviously to do with the
fact that the batch process runs in one environment.
2.4.2.3. Methods for recording Sequences.

2.4.2.3. IEC 61512, ISA 88 method and the Graphset Sequential Flow Chart as per IEC 60848
2.4.2.3. CAE tools for configuration of Batch en Sequential control in in PLC’s, DCS’es (and maybe in SIS’es
2.4.2.3.. Analysis/ Background
IEC 61512, ISA 88 method and the Graphset Sequential Flow Chart as per IEC 60848
2.4.2.3. The relation between ANSI/ISA S88-01-95 and IEC 60844.
In ANSI/ISA S88-01-95; Batch Control Part 1: Models and Terminology is referenced to IEC60848 Ed. 2;
Specification language GRAFCET for sequential function charts. Specific the term PHASE is mentioned a
PHASE can be subdivided in small PHASES. The steps and phases can be detailed in accordance with the
IEC 60848. A PHASE in accordance with ANSI/ISA S88-01-95 definined as the smallest element 0f
procedural control that a process oriented order can fulfill. (ANSI/ISA S88-01-95 chapter 5.1.2.4 Phase)
S88, shorthand for ANSI/ISA-88, is a standard addressing batch process control. It is a design philosophy
for describing equipment, and procedures. It is not a standard for software; it is applicable to manual
processes. It was approved by the ISA in 1995. It was adopted as an international standard by the IEC in
1997 as IEC 61512-1.
The current parts of the S88 standard include:
 IEC 61512-1.ANSI/ISA-84.01-1995 Batch Control Part 1: Models and terminology
Section 4 is entitled Batch Processes and Equipment. The intent of this section is to discuss
batch processing and the batch manufacturing plant. Things that are involved in batch
manufacturing (e.g., batch process classification, equipment, and processes) are described in
this section. The models and terminology defined in this section provide a foundation for understanding
the application of batch control to the batch manufacturing plant in Sections 5 and 4.
Section 5 is entitled Batch Control Concepts. The intent of this section is to discuss key aspects of batch
processing and batch manufacturing plants. This is where control is finally introduced to physical
equipment, and the concept of equipment entities is introduced. Recipes are introduced in Section 5. The
concepts of Allocation and Arbitration, Modes and States, and Exception Handling are introduced in this
section so that they can be applied to the discussions in Section 4.
Section 6 is entitled Batch Control Activities and Functions. The intent of the models and
terminology introduced in this section is to establish the necessary control activities that are
needed to address the diverse control requirements of batch manufacturing. The concept of a
Control Activity Model is introduced in this section. Each control activity from the Control Activity Model is
discussed in terms of the individual control functions that are needed to address the batch processing,
manufacturing, and control requirements of the previous two sections.
 IEC 61512-2 ANSI/ISA-84.00.02-2001 Batch Control Part 2: Data structures and guidelines for
languages
 IEC 61512-3 ANSI/ISA-84.00.03-2003 Batch Control Part 3: General and site recipe models and
representation
 IEC 61512-4.ANSI/ISA -84.00.04-2006 Batch Control Part 4: Batch Production Records
The standard is in use for quite some time at different end-users, system integrators and suppliers all over
the whole world. The use is experienced as appropriate in simple and complex batch processes, but also
for continuous processes in different modes. The application list independent of the degree of automation.
S88 provides a consistent set of standards and terminology for batch control and defines the physical
model, procedures, and recipes. The standard sought to address the following problems: lack of a universal
model for batch control, difficulty in communicating user requirement, integration among batch automation
suppliers, difficulty in batch control configuration.
The standard defines a process model which consists of a process which consists of an ordered set of
process stages which consists of an ordered set of process operations which consists of an ordered set of
process actions. The physical model begins with the enterprise which must contain a site which may
contain areas which may contain process cells which must contain a unit which may contain equipment
modules which may contain control modules. Some of these levels may be excluded, but not the Unit.
The procedural control model consists of recipe procedures which consist of an ordered set of unit
procedures which consists of an ordered set of operations which consist of an ordered set of phases. Some
of these levels may be excluded. Recipes can have the following types: general, site, master, control. The
contents of the recipe include: header, formula, equipment requirements, procedure, and other information
required to make the recipe
As well as for the PLC's as DCS-es and other control equipment applies the same graphical method for
engineering is used on the HMI of the operator workplace. At the same time malfunction can be seen from
the engineering / maintenance console, observing the same sequence. The question to what extent all the
details about the status of the batch process should be exposed to the operator and consequently be
interpreted is something to be considered per project.
IEC 61512 is in first instance developed for batch processes. Later on it appeared it also useful applicable
in discrete and continuous production processes requiring a certain level of flexibility in the use of
equipment (e.g. storage bins and piping for raw material or finished product).
IEC 62264 was not mending especially for batch processes, but for manufacturing in general. It does not
matter whether these companies are involved in batch processes, discrete processes or continuous
processes.
1 The functional specification language GRAFCET
The real advantage is in modular or object thinking. Control of the recipes equipment is structured to a
hierarchy in independent modules. Once a module is designed it cab be reused many times for similar
purposes For the configuration of process control systems DCS or control PLC in batch applications the
IEC 60848 is used, the standard addressing 'Sequential Flow Charts (Graphset)'
For clear communication between the parties involved is in addition to the standard for batch control as
given in ISA SP88, a formal diagramming method required. This is found in the IEC 60848 for the
completion of sequential program parts.
This International Standard defines the GRAFCET1) specification language for the functional description
of the behavior of the sequential part of a control system. This standard specifies the symbols and the rules
for the graphical representation of this language, as well as for its interpretation. This standard has been
prepared for automated production systems of industrial applications. However no particular area of
application is excluded. Methods of development of a specification that makes use of GRAFCET are
beyond the scope of this standard. One method is for example the "SFC language" specified in IEC 61131-
3, which defines a set of programming languages for programmable controllers NOTE See annex C for
further information on the relations between IEC 60848 and implementation languages such as the SFC of
IEC 61131-3.p3/4/5
The in the recent years developed alignment between the configuration in this generation (control) PLC’s
and DCS’es and the functional diagrams it seems appropriate to take the road of further engineering
automation The objects as specified in IEC61131-3 are the s amen as drawn on the sequential flow charts
according IEC 60 844. The DCS control PLC suppliers do support this workflow.
In general are the configuration languages DCS’s ( ) and PLC’s (IEC 61131-3) over the whole line
but also within the program of a single supplier different. The use of the function blocks and the
object oriented approach are the same.
Example
V1 T1
R1 R1 R1 R1
A B C D
R2 R2
A B
V5
Reactor R1 empty V1 filled & Pipe free
Charge from V1
Reactor R1 filled
T1 filled & pipe free Reaction 1
First inhibitor charged
2,5 % inhibitor charged
Reaction 2
Second inhibitor charge
7,5 % inhibitor charged
Reactor R 2 empty Agitation & wait
Discharge
Reactor R1 empty
Wait
Third inhibitor charge
90 % inhibitor charged
Agitation
20 min. passed
Discharge
Reactor empty
Cleaning
30 min. passed
Functional Design in the Process Industry, rev 1.1 24.03.2019 Hiroshi Okada & Hindrik Koning, printed 24-03-19, page
40/173
41/173
4.4.2. The impact of IEC 61131 OVERVIEW
IEC 61131-3
The Fast Guide to Open Control Software
Introduction
IEC 61131-3 is the first vendor-independent standardized programming language for industrial
automation. The language was established by the International Electro-technical Commission (IEC), a
worldwide standard organization founded in 1906 and recognized worldwide for standards in the
controls industry by over 50 countries. The standard is already well established in Europe and is
rapidly gaining popularity in North America and Asia as the programming standard for industrial and
process control.The adoption of IEC 61131-3 by the industry is driven by the increasing software
complexity of control and automation requirements. The creation time, labor cost, and maintenance of
control software has a major impact on control projects that can be improved using the IEC 61131-3
vendor-independent programming language standard. Applying a standard programming language
has a positive impact on the software life-cycle that includes requirements analysis, design,
construction, testing (validation), installation, operation, and maintenance. The impact on
maintenance is important since control software maintenance, including upgrades, is generally two to
four times the labor of initial programming.
The IEC 61131-3 standard, combined with powerful new Free scale chip architectures, enables an
entire controller to be delivered in an embedded device. Control programs can run distributed and
independently rather than concentrated in large controllers. No longer are thousands of lines of
control programs required to run in one controller for complex automation applications. This increases
performance, improves reliability, and simplifies programs. IEC 61131-3 provides multiple language
support within a control program. The control program developer can select the language that is best
suited to a particular task, greatly increasing their productivity. Plus, with a standardized programming
interface that is completely independent of the hardware platform, users can greatly reduce the cost
of program maintenance and training across company wide automation applications.
IEC 61131-3 is hardware-independent. The ability to transport automation solutions to other platforms
is vastly improved Over PLC applications, offering users and System Integrators a level of reusability
never before available. IEC 61131-3 Also increases the efficiency and speed of implementing new
automation solutions by using readily available control components developed on other projects and
by outside developers.
Companies that have chosen to implement IEC 61131-3 find that they reduce human resource costs
in training, debugging, and maintenance and improve productivity due to the higher reusability.
The International Electro technical

Commission regulates
the IEC 61131 standard.
Technology Overview
IEC 61131-3 is the international standard for programmable controller programming languages. As
such, it specifies the syntax, semantics, and display for the following suite of PLC programming
languages:
♦ Ladder diagram (LD)
♦ Sequential Function Charts (SFC)
♦ Function Block Diagram (FBD)
♦ Structured Text (ST)
♦ Instruction List (IL)
IEC 61131-3 is the third component (Part 3) of the IEC 61131 family that consists of:
♦ Part 1 General Overview
♦ Part 2 Hardware
♦ Part 3 Programming Languages
♦ Part 4 User Guidelines
♦ Part 5 Communication
The easiest way to view the standard is to split it into two parts, Common Elements and Programming
Languages.
Common Elements
The first portion of IEC 61131-3 is comprised of some common elements.
42/173
Data Typing
Data Typing is a common element of the standard that prevents errors early in development. It
defines the type of parameters that will be used and attempts to avoid errors like dividing a Date by
an Integer. The different type of data supported are Boolean, Integer, Real, Byte, Word, Date, Time-
of-Day, and String. The Standard also allows users to define their own variables.
These are known as derived data types. Using derived data types, an engineer would be able to
define an analog input channel as a data type and re-use it repeatedly.
Variables
Variables are assigned only to explicit hardware addresses or explicit inputs and outputs. These can
be assigned in custom configurations and programs. An IEC 61131 system is highly independent and
able to function with little to no messaging from an external network.
The Scope of the variable is limited to the organization unit in which they are declared. The great
benefit of this feature is that variable names can be reused in other parts without any conflict,
eliminating another source of errors. If the variables have Global Scope they must be declared global.
Parameters can be assigned for their initial values at start up and restart.
Configuration, Resources, and Tasks

At the highest level, the software required to solve a particular control problem can be formulated as a
Configuration. A Configuration is specific to a particular type of control system and includes the
arrangement of the hardware (processing resources, memory addresses for I/O channels, and
system capabilities).
Within a configuration, one can define resources. A resource can be thought of as a processing
facility that is able to execute IEC programs. Within a resource, one or more Tasks can be defined.
Tasks control the execution of a set of programs and/or function blocks. These can either be executed
periodically or upon occurrence of a specified trigger.
For instance, in an IEC 61131 enabled drive, a trigger could be set when Ram’s fall below a
predefined value. The trigger Could start a task to increase speed. These results are instant and
come directly from the drive. There is no lag or handshaking by an external PLC. This means that
there is virtually no risk of losing a message or miscommunication. Feedback
is nearly instantaneous compared to a Programmable Controller with an I/O and Program Scan time.
Programs are built from a number of different software elements written in any of the IEC defined
languages; Ladder diagrams, Sequential Function Charts, Function Block Diagrams, Structured Text
or Instruction List. It is typical for a program to consist of a series of high level function blocks written
in one or more of these languages.
Program Organization Units

Within IEC 61131-3, the programs, function blocks, and functions are called program organization
units, or POUs. IEC 61131-3 includes defined standard function instances, including ADD, ABS,
SQRT, SIN, and COS. The user can also create a custom function block and use that function block
multiple times. Function blocks are software objects that represent a level of more detailed control.
They can contain data as well as an algorithm. As software objects, they have a well-defined interface
and hidden internals. This creates a clear line between the different levels of the programs. With
these characteristics, functions and function blocks reflect best practices as embraced by object-
oriented programming principles.
Function blocks can be written in any of the IEC languages and, in most cases, even C using basic
building blocks. Sequential Function Charts, or Sac’s, are used to control the sequential behavior of a
control program and support synchronization and concurrency.
Programming Languages
In IEC 61131-3, five standard programming languages, including syntax and semantics, are defined,
leaving no room for dialects. Once you have learned the five languages, you can use a wide variety of
systems based on the standard.
The end user is able to choose a programming language based on their knowledge, the problem at
hand, external components, interfaces, or simple preference. All languages are linked and provided a
common suite, with a link to existing experience. In this way, they also provide a communication tool,
combining people of different backgrounds. Because of the standards structure built on functions and
function blocks, users are able to adopt either a top-down or bottom-up strategy to develop their
programs.
43/173
TECHNOLOGY OVERVIEW
IEC 61131-3 is the international standard for programmable controller programming languages. As
such, it specifies the syntax, semantics and display for the following suite of PLC programming
languages:
 Ladder diagram (LD)
 Sequential Function Charts (SFC)
 Function Block Diagram (FBD)
 Structured Text (ST)
 Instruction List (IL)
IEC 61131-3 is the third component (Part 3) of IEC 61231 family that consists of
 Part 1 General Overview
 Part 2 Hardware
 Part 3 Programming Languages
 Part 4 User Guidelines
 Part 5 Communication
The easiest way to view the standard is to split it into two parts, Common Elements and Programming
Languages.
COMMON ELEMENTS
Data Typing
Data Typing is a common element of the standard with the purpose to prevent errors early on in
development. It defines the type of parameters that will be used, and attempts to avoid errors like
dividing a Date by an Integer. The different type of data supported are Boolean, Integer, Real, Byte,
Word, Date, Time-of-Day and String. The Standard also allows users to define their own variables.
These are known as derived data types. In this way an engineer would be able to define an analog
input channel as a data type and re-use it over and over again.
Variables are assigned only to explicit hardware addresses or explicit inputs and outputs. These can
be assigned in custom configurations and programs. An IEC 61231 system is highly independent and
able to function with little to no messaging from an external network.
The Scope of the variable is limited to the organization unit in which they are declared. The great
benefit of this feature is that their names can be reused in other parts without any conflict, elimination
of another source of errors. If the variables have Global Scope they can be declared as global.
Parameters can be assigned their initial value at start up and restart.
Configuration, Resources, and Tasks

At the highest level, the entire software required to solve a particular control problem can be
formulated as a Configuration. A Configuration is specific to a particular type of control system,
including the arrangement of the hardware, i.e. processing resources, memory addresses for I/O
channels, and system capabilities.
Within a configuration one can define resources. A resource can be thought of as a processing facility
that is able to execute IEC programs. Within a resource, one or more Tasks can be defined. Tasks
control the execution of a set of programs and/or function blocks. These can either be executed
periodically or upon occurrence of a specified trigger.
For instance, in an IEC 61231 enabled drive, a trigger could be set when RPM's fall below a
predefined value. The trigger could start a task to increase speed. These results are instant and come
directly from the drive. There is no lag or handshaking by an external PLC. This means that there is
virtually no risk of losing a message or miscommunication. Feedback is nearly instantaneous
compared to a Programmable Controller with an I/O and Program Scan time.
Programs are built from a number of different software elements written in any of the IEC defined
languages; Ladder Diagrams, Sequential Function Charts, Function Block Diagrams, Structured Text
44/173
or Instruction List. It is typical for a program to consist of a series of high level functions blocks written
in one or more of these languages.
Program Organizations Units

Within IEC 61231-3, the programs, function blocks, and functions are called program organization
units, or POU's.
IEC 61231-3 includes defined standard functions instances, ADD, ABS, SQRT, SIN, and COS. Or the
user can create a custom function block and use that function block multiple times.
Function blocks are software objects that represent a level of more detailed control. They can contain
data as well as an algorithm. As software objects they have a well-defined interface and hidden
internals. This creates a clear line between the different levels of the programs. With these
characteristics, functions, and function blocks reflects best practices as embraced by object oriented
programming principles
Function blocks can be written in any of the IEC languages in most cased even “C". Programs can be
written using the any of the above mentioned basic building blocks.
Sequential Function Charts or SFC's are used to control the sequential behavior of a control program
and support synchronization and concurrency.
PROGRAMMING LANGUAGES
Within IEC 61231-3, the syntax and semantics are defined for five standard programming languages,
leaving no room for dialects. Once you have learned them, you can use a wide variety of systems
based on this standard.
The end user is able to choose a programming language based on their knowledge, the problem at
hand, external components, interfaces, or simple preference. All languages are linked and provided a
common suite, with a link to existing experience. In this way they also provide a communication tool,
combining people of different backgrounds. Because of the standards structure built on functions and
function blocks users are able to adopt either a top-down or bottom-up strategy to develop their
programs.
The five languages:
Ladder Diagram is most popular in the US2.3.p3/4/5 it is based on the graphical presentation of
Relay Ladder Logic. Most non-IEC61231-3 compliant PLC's only support ladder logic.
Instruction List is the European counterpart to Ladder. As a textual language, it resembles assembly
code.
45/173
Function Block Diagram expresses the behavior of functions, function blocks and programs as a set
of interconnected graphical blocks, like in electronic circuit diagrams.
Structured Text is a very powerful high-level language with its roots in Ada, Pascal and “C”. It can be
used for the definition of complex function blocks, which can be used within any of the other
languages.
Sequential Function Chart (SFC) is a powerful graphical technique for describing the sequential
behavior of a control program
So which one should you choose? The choice of programming language is dependent upon the
following:
 The programmers’ background
 Are they better/faster at programming and debugging a particular language

 The end user’s preference
 As consultants, we often select a language based upon our customer's skill set. If they prefer
one language over another, we will use it even if it would not have been our first choice.
Code that is easy to maintain may be much better than code that was easy to write in the first place
 The task at hand

 Ladder, Instruction List, and Function Block Diagram are work well for bit logic.
 SFC is great for sequential operations.
 Structured Text is perfect for complex math functions, array operations, and string
operations.
 Instruction List is well suited for low level processor commands and PLC memory/register
access.
 The way in which the logic is defined
 If your pseudo code is written as a graphical flow chart, SFC is a good choice.
 If your logic is defined as a stateless system where the outputs and inputs are linked with
interlock logic, then Ladder is a good choice
46/173
If you are still unsure of which language to choose, here's a secret: YOU DON’T HAVE TO
CHOOSE! That’s right, the great thing about the IEC61231-3 standard is that you can structure your
project and mix and match programming languages.
If you structure your code properly and leverage the power and flexibility of function blocks (you do
use function blocks, don't you?), you can modularize your code into manageable blocks. Each block
can be written in a different language. You can choose which one is most suitable for each section of
the project. For example: Basic I/O logic could be written in Ladder, main control and sequential
operations in SFC, and data processing in ST. This way you can maximize the benefits of each
language without having to choose one over another
CoDeSys (www.3s-software.com)
CoDeSys is one of the most powerful IEC 61231-3 programming tools for controllers. CoDeSys
supports all five programming languages of the standard combining the power of advanced
programming languages such as C or Pascal with the easy handling and operational functions of PLC
programming systems.
Unlike some competitive IEC 61231-3 offerings, CoDeSys produces native machine code for a large
number of common processors. Native machine code is inherently faster and more reliable than
interpreted solutions.
The entire programming kit including a manual and online assistance is available in German, English
or French. Parts of the tool, e.g. the online help are available in other languages like Russian,
Chinese or Spanish.
CoDeSys provides competitive advantages:

Fast Customization
3S is able to perform a complete test adaptation (including online functionality) on any standard
processor hardware within two days’ time. CoDeSys has ready backends for all current processors. In
order to keep customization time and resulting expenses to a minimum the run time system,
programming system and code generation are perfectly coordinated, thus saving your time and
ensuring your products reach the marketplace swiftly.
A Practical, Easy-to-Use Approach

Functions such as Auto declare, Auto format and a context-sensitive input assistance greatly simplify
the use of CoDeSys. All functions are accessible by use of the keyboard. What additionally ensures
fast and efficient work is the exceptionally low number of resources CoDeSys requires.
High Performance
Native code generators for all common processors guarantee the optimal use of your control system.
Due to intelligent algorithms such as 'incremental compile' large projects with thousands of global
variables and hundreds of components can be realized in surprisingly short compiling time spans.
CoDeSys supplies users with a broad range of high-performance program development
functionalities, e.g. almost all data types specified in the IEC 61231-3, offline simulation as well as
powerful online functions such as breakpoints, single stepping, power flow, sampling trace and online
change.
5 Functional Design Specification
47/173
The stage at which the supplier, in conjunction with the user, develops the Functional Specification,
showing what functions are to be provided to meet the user's requirements, stating what resources will
be required, and providing the agreed basis of the system design.
A Functional Design Specification (FDS) details the solution to be provided to meet the Users
Requirements and Functional Requirements. It should be approved by the User and should form the
basis of the design for both Hardware and Software. All the functions, operator interactions control and
sequencing associated for the process automation should be clearly detailed. This allows the User to
confirm, before the system is developed that the proposed solution fully meets the requirements.
The FDS provides the basis of the design of the system and is used to verify and validate the system
during the testing, ensuring all the required functions are present and that that they operate correctly.
The FDS should cover
Control Modules such as PID Loops, Indicators etc
HMI Graphic displays
Equipment Basic Control
Phase Logic
Operations
Unit Procedures
Recipes
The Inputs and Outputs of the systems with cards and channels assigned to them.
Much of the FDS may be references to standard system objects.

But beware, sometimes what are supposed to be standard turn out otherwise, and some 'standard
modules' turn out to be not what you really wanted.
Functional Design Specification

Large software developments follow a particular path, from the initial meeting right up to when the
product is handed over. The precise path followed depends on the nature of the job and the techniques
in use at the developer; however, all developments must start with a description of what the system is to
do. This is the most crucial item in the whole project, and is often called the Functional Design
Specification, or FDS.
The functional design spec. Functional Specification Standard
By Dino Fancellu
Published at: http://www.softwarereality.com/lifecycle/functionalspec.jsp
Introduction
In general terms, the functional specification states what the proposed system is to do, whereas design
is how the system is to be constructed to meet the functional specification. However in writing it, some
consideration of design issues must take place, to ensure a realistic system is specified.
The functional specification should be clear, consistent, precise and unambiguous. The user
requirement may mean that the user interface should be included in this document for some projects,
whereas for others this will be done at the design stage either within a document or developed via a
prototype.
It is important that there is a draft functional specification before the design stage on any project is
started and that the functional specification is agreed and issued normally within a week of the final
quality review. There must be a milestone on the project plan for the issue of the functional
specification. The functional specification must be kept up-to-date, as this is the communication with the
world outside the development staff.
The following should be used as a standard for a functional specification with some mandatory sections.
The layout itself is at the discretion of the author except for Chapter 1. The document should have a
standard front page, document authorisation page containing the title, issue, author and quality
controller and contents page. Use diagrams where appropriate.
48/173
Do not be afraid of examples! Use them copiously throughout, as a brief, concrete example often
illustrates a point much more succinctly than a normative explanation. Also remember to keep the
examples interesting, as this is a useful way of keeping the reader’s interest – this is just as important in
a functional specification as in any other type of document.
1. Introduction
An introductory sentence or two about the project as this is probably the first document written on the
project.
1.1. Summary
A few sentences summarizing the project: what it is, who it is for (customer or internal), is it a bespoke
project, a product, a demo.
1.2. Requirements
This section should state the requirements the functional specification is attempting to fulfil. This may be
an understanding of a customer’s requirement or a statement given as an internal starting point, e.g.
produce a comprehensive mail tool in minimum time. Normally requirements are by their nature
unstructured with high and low level statements intermingled. This section should refer to a separate
requirements document if it exists. If there is anything else clarifying the requirement such as faxes
these should also be referred to and probably a copy put into an Appendix.
1.3. Numbers
This section should detail the number of users expected to use the system, how often, expected
number of transactions (per minute/hour/day), peak usage times etc.
The question that should be asked of project stakeholders up-front is: "What numbers are we looking
at?"
Capacity/response time needs have to be outlined so that we don't come up with a slow/tiny system, or
don't totally over-do it and come up with a n-tier EJB solution costing £500k, when the system will only
ever have 20 simultaneous users.
Such information will make a big difference to the architecture, i.e. the eventual design specification.
This is why it is vital to establish these figures early in the project.
These figures are such an overarching issue that they do not belong in any one section. In fact the
issue is expanded upon in several sections, such as User Community, Performance and Expandability.
1.4. Existing System

This section should include an explanation of the system we are replacing, even if it’s an old manual
system.
What problems does the current system have? Which of these problems do we solve?
What useful functions of the current system will we not provide (Constraints)?
Depending on the depth of analysis required, this section may also describe the root causes of each
problem. “Root cause” analysis is a systematic way of uncovering the underlying cause of an identified
problem:
“It’s amazing how much people do know about the problem behind the problem; it’s just that no-one –
by which we usually mean management – had taken the time to ask them before. So, ask them and
then ask them again.”
Source: Managing Software Requirements: A Unified Approach by Dean Leffingwell, Don Widrig –
Chapter 4, “The Five Steps in Problem Analysis”
49/173
1.5. Terminology
This section should contain all words or phrases having a special meaning for this project with a clear,
concise, unambiguous statement on their meaning.
1.6. References
List any document references with numbers, remembering to include issue numbers and/or dates so
that the actual version is identified and refer to them as ref[n] in the rest of the document.
2. Functional Description
The rest of the document may be divided into individual sections or chapters depending on the size and
complexity of the system. Avoid forward references as the flow of the document is lost; consider re-
ordering of the document in such circumstances.
Whereas requirements tend to be unstructured, the functions provided to fulfil the requirements must be
structured. All statements as to functionality, should be written clearly using consistent terminology such
that a test could be written to ensure the final system, performs as described and also that a design
should fall naturally with no interpretation being necessary. It should be possible to draw up a table of
functions within full system and product tests and incorporate a test for each function. To this end all
functional statements should be numbered.
It may be that basic functionality could be identified such that some items are mandatory whereas some
are highly desirable which should be clear from the requirements. If this is so, then identify these in this
specification.
The functions should be grouped where possible under sub-headings to make an easily readable and
understandable system.
All the following underlined headings must be included somewhere in the document, not necessarily in
the order given here. If it is not relevant or we are not addressing it for this system, then say so.
Use Cases
Most likely these will be kept in a separate document or CASE tool, referenced from the functional
specification. Development of the use cases and functional specification should happen in parallel,
where information from one feeds the other incrementally.
Always avoid repetition. The amount of detail in the rest of the functional specification will depend on
the number of use cases that have been written.
Although important, use cases do not capture all functional requirements: this is why we need an
encompassing functional specification. The availability of a separate document also discourages use
case authors from putting too much detail in the use case (e.g. functional requirements instead of usage
scenario text) or the wrong detail (e.g. boundary conditions), which are both common mistakes.
(Note this is a similar approach to the Unified Process “Supplementary Spec” which captures additional
detail that should be kept separate from the use case).
Where the functional specification references a use case, always use the unique use case name (e.g.
“Perform Order Entry”). Depending on the size of the system being modelled, you might also need to
include the package name.
Similarly, if the use case references an item in the functional spec, always use the section and number
of the functional item (e.g. “User Community, item 1.2.3.4”). If possible (given the constraints of the
word processor or CASE tool being used) provide a hyperlink that takes the reader directly to the
referenced item.
User Community
Identification of who the system is aimed at. There may be more than one group of people and each
group may have slightly different requirements. Are we providing different functions to fulfil these or not?
These groups of people are normally identified as use case roles (i.e. actors), and the functions
assigned to each role as individual use cases. Where this information does not fit into the use case
50/173
model, it should be captured in the main functional specification instead.
Administration Functions
How will the system be administered? Are there separate functions for an administrator? Is there any
security built in to stop others using administrative functions? Passwords?
Error Handling
How errors should be handled should be stated. Identify the different types and reasons for the
classification.
Security
Security considerations are an important part of any project. This section should detail possibilities of
abuse of the system.
Along with error handling, the specification has to handle “the negative path”. There is no point in
having a system that does lots of good things if it also does lots of bad things.
Help
What type of help is to be provided?
Printing
Ensure any printing to be provided is stated.
Interfaces
User
This could be a chapter in its own right if it is a full definition. If it is deferred to the design specification
stage, this should be stated.
Software
We may be interfacing to existing software. This should be stated, e.g. toolkits, back ends of existing
packages. State versions. Do interface documents exist?
Boundary Conditions
It should be clear what are the extremes to be taken into consideration. These items may have come
up. This will vary with different systems but it could be items such as number of users, size of forms,
number of forms.
Constraints
All other constraints not specified under particular headings. For example: economic, political, technical,
system, environmental, scheduling constraints.
Platforms
We should list which platforms we will be supporting. Name a reference platform or platforms plus
appropriate operating system versions.
Internationalization
Is this to be included in the product now or in the future?
Performance
Capacity
Response times
51/173
Portability
Although we may only be supporting one platform initially, we almost certainly will want to be able to
port developments to other platforms. This should be stated here.
Expandability
State the likely expansion requirements. Some of the items may have been considered earlier in the
document. These should be referred to from this section and any additional items put in.
Customization
Are we allowing the user to customize the system? If so, what are we going to provide?
Support & Maintenance

Are any functions to be included to make maintenance and support easier, e.g. internal monitoring of
traffic flows.
Configuration Management
How are we proposing to manage the various software versions?
Documentation
List the documents that will be produced. This could refer to the project plan if that exists and contains
such a list, otherwise it should be stated here.
To the ICE Web user: following is a paper which I produced a number of years ago which is still very
relevant today. I have edited a few references to make it more up to date. If you are undertaking a
project and follow the guidelines contained within it your job will, in my opinion, stand a greater chance
of being a success. Finally I am very interested in your opinion of my site, please feedback so that I can
improve it!
Jim Russell
52/173
6 Coding and break down structures
5.7 Plant Numbering Systems ISO, ISA, KKS, AKZ, PNS
5.7.1 Coding systems, numbering systems and their relation

.
5.7.1.1 Introduction.
further from the truth, as will appear. We have all Instrumentation & Control is now a functional
component / function code data (see Section 6.1.2, there were various schemes and there are more).
If more than one item with the same functional code, think of a row of flow regulators, often referred to
as FIC, then this mechanism is already fixed. Then there must be meaningful and coding or
numbering systems are. Over the past several trade disciplines coordination is also needed in the
regular history we found that three different objects of the same factory and had a similar code. At the
same occupation and maintenance operations team who also probably had different names than one
mistake is not likely. This is something different, a little less permanent occupation, it gives
communication through only the codes (my own experience in the commissioning of about 20 plants)
most likely errors (MS for motor switch or manual switch within the IT discipline or S-106 to a
separator and a switch S106 are easily made.
We also need in addition to the draft rule also consider operations and maintenance. Indeed, it often
happens that a team operator operates several factories. The operator in the control room would be
so again by the same function code and similar numbers in different plants may get confused.
Maintenance is now often done by hiring staff, because this, awareness of the physical location of the
equipment tends to be far lower. Was the previous well to process units to be distinguished, it is now
a must to avoid the first one day should be sought to repair item (pump, tank or transmitter) or worse,
to the equipment of a commissioning being unit (the wrong equipment) will be working .. The
relationship with the subject Plant Break down structure is soon produced.
5.7.1.2. Loop identification to ISA (American use)
5.7.1.2.1 Composition of the loop identification
The course consists of identifying a first letter (first letter) and a number (number). Each tool within a
course is mapped to the same course number and, in the case of parallel numbering, the same first-
letter. Each course has a unique instrument identification. A tool common to two or more loops to
perform the identification of the course which dominates considered
5.7.1.2.2 Running parallel or serial numbers can be applied.

- Parallel numbering starting a numerical sequence for every new first-letter, for example, TIC-100,
FRC-100, LIC-100, AI-100, etc.
- Serial numbers going through a sequence of numbers for a project or for large parts of one project,
independently of the first letter of the loop itself, for example, TIC-100, FRC-101, LIC-102, Al-103, etc.
A loop sequence may begin with a number or any other suitable number, such as 001, 301 or 1201.
5.7.1.2.3. If a loop contains more than one instrument with the same functional identification, it can be
a suffix added to the loop number, for example, FV-2A, 2B-FP, FP-2C, etc., or A-25-1, TE 25-2, etc. It
can be more convenient or logical in a given case to a "couple" of flow channels contamination, such
as FT-2 and FT-3 instead of FT and FT-2A-2B.
5.7.1.2.8.1 Function Code Part

In addition, other objects (mechanical, electrical, telecom, etc.) also have a functional code, and if
they have they same reason as above are also at least one number is required. But we have our ISA
S88 and ISA S95 also already committed one. Not functional code instrumentation equipment. And
others as discussed in batch systems.
Which numbering / coding systems are alike?
Systems Standard Institutes
Contractor systems
Provider systems (DCS around or package units etc)
53/173
End-user systems
The above appears on a remote display or a alegaartje, take only one and it is certainly not good for a
colleague and can not argue about taste.
The bottom six of the "Standard Institutes' get more attention.
KKS from the World of German power stations (to be redeemed)

AKS German industry need process used
PNS is a relatively new system
ISO 3511 for process (cramped and aging)
IEC for electrical installation
ISA S5.1 intensive (as derivatives) commissioning
We will briefly in Section 6.1.8.2 and next, in that order processing, first we follow the numerical code.
5.7.1.2.8.2 The numeric code section (a serial number)

The serial number should obviously be unique within a group with the same measurement function,
simply to prevent us from walking level circuits (loops) with each change. Otherwise, mechanical and
other equipment the same reasoning.
Shell DEP 32.10.03.10-Gen

Serial numbers must be unique in each group of instruments with the same combination of process
unit identification ('a') and the measured variable code ('b'). Serial numbers will start with 001 and
must be arranged so that the expected future extensions can be accepted. Some numbers must
remain unused for the unexpected future extensions to cope.
Example: Flow tools in the process unit 1100 encoded 110FICA-001, 110FG-002, 110FP-003,
110FIZA-005. In this example, section 110-004 intentionally not been used for unanticipated future
expansion.
Note.:
1, the practice of allocating the number of separate series for the items quality test (QPS), restriction
orifices / flow measurement points (RO / FPs), flow glasses (FGS), gauges / test points (PGS / PP)
and temperature gauges / elements / test points (TG / TF / TP's) are no longer used. This practice
may still be desired for a particular project to maintain consistency with existing facilities or where the
available number of non-series is suitable for all instrument functions
.
2. Notwithstanding the above tag numbering scheme may be required in certain cases, for which the
contractor submits an alternative arrangement to the client for approval.
3. If a process unit consists of process lines / trains of identical pieces of equipment, then the
assignment of serial number 'y' should be selected for a logical and recognizable relationship
numbering features. Example: 1100 Process Unit consists of two identical compressor sets and a
future third compressor is projected. Blocks of serial numbers instrument could be allocated as
follows: 001-099 for the common upstream process, 100-199 for a compressor, compressor 200 and
299 for two, three compressor reserved for 300-399 and 401 or higher for the downstream
processes . The pressure controllers for compressors 1, 2 and 3 could be tagged as DEP
32.10.03.10-Gen.
- Mostly parallel numbering is used in DSM, it concerns the start of a numerical sequence for every
new first-letter, for example, TIC-100, FRC-100, LIC-100, AI-100 and then on the following P & ID re-
TIC- 200, FRC-200 LIC-200, AI-200 etc
The prefixes, such as Shell who used the unit (Section / Unit) e.g. 1100aangeven and encoded as
110FICA-001, 110FG DSM-002 are not actively used, in part, this is included in the Tags. See above.
This will be achieved by plant

Similar instrument 100 functions by P & ID TIC 110 to 199 TIC
10 P & IDs per Unit
Process part of Unit 1-8 (utilities 9) 10000 equal instrument functions
Equipment similar equipment numbering 10 per P & ID

10 P & IDs per Unit
54/173
Process part of Unit 1-8 (utilities) 1000 similar equipment functions
PI & D's 10 per unit * 10 units = 100 P & IDs
In several plants of the same species, the Tags with one digit is extended and the Tags Plant 1: 1110
through 1199 and TIC Plant 2: 2110 through 2199 TIC.
The equipment follows this pattern, but the P & ID numbering goes along.
If multiple process steps over a P & ID parallel (section) is helpful to these sections for an extra digit
to use, it will be because the logic of numbering the whole plant than extra digit.
.7.1.3. The KKS Power Plant Classification System (German Power World)
This is a standardized system for classifying the power stations. The support during the engineering,
construction, operation and maintenance of plant identification and classification of the equipment.
The system is known in short PPS is an abbreviation of the German term Kraftwerk-
Kennzeichensystem. This system is around VGB itself long ago, there was by and for the energy
industry experience gained quite a bit. The codes are a key project under the standard and with the
other power stations in this area issued by a competent and careful person.
It's also good to use in the process industry, the coal gasification project in 1995 Buggenum is a good
example. The culture, processes and methods, but especially the communication are then very
different. Precisely because the standard for the power industry has made, means the use of
chemicals or the use of many non-standard solutions, there are also shortcuts to help the process of
the KKS unit in the jacket mold. Otherwise, there is now a new standard that covers a broader
spectrum see later. The equipment code is thus resolved, the numbers (to avoid duplicate numbers is
still the biggest problem.
Structure and Format
PPS has three different types of codes:
• A process oriented code (functional code) for identification of systems and equipment according to
their functions in the power process.
• The installation code for identification of points of installation of electrical, instrumentation and
control equipment
• The code of the place, to identify the locations of materials and structures
This method has never (except the process of coal gasification, Buggenum) applied in the process
industry for the following reasons:
Lack of a code for process plants
2 very time when the establishment is not popular with contractors
3 is a control human-body codes needed to issue and controlee
55/173
Breakdown level 0 1
Data character G F0 F1 F2 F3
Process-related identification = Total plant System code
Data type * = (A or N) (N) A A A
Point of installation
+ Total plant Installation unit code
identification
Data type * + (A or N) (N) A A A
Location identification + Total plant Structure code
Data type * + (A or N) (N) A A A
*) Data types are Alpha and Numeric. Alpha contains only main characters except I and O, but also
some special characters. As a point between hook states then it may be omitted if the code is unique.
Here with to the wishes of all concerned adapted. But this is very great identification plates
Field description on Process-Related Identification
Fields Content
F1, F2, F3 System and plant classification
A1, A2 Mechanical, electrical, control and instrumentation equipment classification
B1, B2 Component, signals and signal applications classification
Examples of codes
Break down of =10LBA10BR001
56/173
Total plant System Equipment code Component code
unit 1 Main steam piping system 1 0 pipe 001
=1 0LBA10 BR001
Break down of =00LAC10AP001KP01

Total plant System Equipment code Component code
unit 0 Feedwater pump system 10 pump unit 001 pump 01
=0 0LAC10 AP001 KP01
Break down of +G0BFA20·C2

Total plant Installation unit code Installation space code
Low-voltage main
unit G floor, location 2
distribution board
+G 0BFA20 · C2
Break down of +L0UMA10R01

Total plant Structure identification Room identification
unit L Steam turbine building Room 01
+L 0UMA10 R01
Function Key, Main Groups

With the KKS system the main systems of a power station are identified by using a function
key.
Function
Main Groups
Key
A Grid and distribution systems
B Power transmission and auxiliary power supply
C Instrumentation and control equipment
E Conventional fuel supply and residues disposal
F Handling of nuclear equipment
G Water supply and disposal
H Conventional heat generation
J Nuclear heat generation
K Reactor auxiliary systems
L Steam, water, gas cycles
M Main machine sets
N Process energy supply for external users
P Cooling water system
Q Auxiliary systems
R Gas generation and treatment
S Ancillary systems
U Structures
W Renewable energy plants
57/173
X Heavy machinery (not main machine sets)
Z Workshop and office equipment
Equipment unit code, main group

A Mechanical equipment, example AA - valves
B Mechanical equipment, example BQ - hangers
C Direct measuring circuits, example CP - pressure measuring
D Closed loop control, example DF - flow, rate
E Analog and binary signal conditioning, example ER - reactor protection
F Indirect measuring circuits, example FD - density measuring
G Electrical equipment, example GQ - power sockets
Subassemblies of main and heavy machinery, example HD - bearing
H
assembly
J Nuclear assemblies, example JN - neutron sources
Component code, main group
K Mechanical components, example KC - heat exchangers
M Mechanical components, example MT - turbines
Q Instrumental and control components, example QR - instrument piping
- Electrical components, example -M - motors
X Signal origin
Y Signal application
Z Gated signals
Function Key, Main Groups and Subgroups
Examples for Main Groups and Sub groups:
B Power transmission and auxiliary power supply

BA Power transmission
BAA Generator leads
BAB Foundation cabinets
Generator circuit breaker, also commutating pole circuit breaker, including
BAC
cooling system
BAT Generator transformers, including cooling system
BA...
BB Medium voltage distribution boards and transformers, normal system
BBA - BBS MV distribution boards
BBT MV auxiliary power transformers
BB...
E Conventional fuel supply and residues disposal

EA Unloading and storage of solid fuels
58/173
EAA Ship unloading system
EAB Rail wagon and truck unloading bay
EAC Transport system
EAD Stacking system
EA...
ET Ash and slag removal system
ETA Wet ash conveying system
ETB Storage or settling pond for wet ash
ETC Wet ash dregger
ETD Conveying system for granulate
ETE Storage system for granulate
ETG Conveying system for dry ash
ETH Storage system for dry ash
ET...
H Conventional heat generation

HA Pressure system
HAA LP part-flow feed heating system (flue gas heated)
HAB HP part-flow feed heating system (flue gas heated)
HAC Economizer system
HAD Evaporator system
HA...
HF Bunker, feeder and pulverizing system
HFA Bunker for pulverizing system
HFB Feeder system
HFC pulverizing system (incl. classifier)
HF...
HL Combustion air system (primary air, secondary air)
HLA Ducting system
HLB Fan system, forced draught fan system
HLC External air heating system (not flue gas heated)
HLD Air heating system (flue gas heated)
HL...
HN Flue gas exhaust (without flue gas treatment)
HNA Ducting system
HNC induced draught fan system
HNE Smoke stack system (chimney)
HNF Flue gas recirculation system
HN...
L Steam, water, gas cycles
59/173
LA Feedwater system
LAA Storage, deaeration (incl. feed water tank)
LAB Feedwater piping system (excl. feedwater pump and feedwater heating system)
LAC Feedwater pump system
LAD HP feedwater heating system
LAE HP desuperheating spray system
LA...
LB Steam system
LBA Main steam piping system
LBB Hot reheat piping system
LBC Cold reheat piping system
LBD Extraction piping system
LB...
LC Condensate system
LCA Main condensate piping system
LCB Main condensate pump system
LCC LP feedwater heating system
LC...
M Main machine sets

MA Steam turbine plant
MAA HP turbine
MAB IP turbine
MAC LP turbine
MAD Bearings
MAG Condensing system
MA...
MB Gas turbine plant
UH Structures for conventional heat generation

U Structures
UHA Steam generator enclosure, steam generator building (boiler house)
UHF Bunker bay
UH...
UM Structures for main machine sets
UMA Steam turbine building
UMB Gas tubine building
UMC Gas and steam turbine building
UM...
5.7.1.4 The AKS either AKZ Anlagenkennzeichnungssystem
The facility identification (AKS or EAC) is the cross-industry body, with a foothold in the German
process industry. In the electricity sector (PPP), the power is the identification system (PPS) is used
as we have seen in the previous section. DIN 6779, with several folders and several industry-specific
expression of descriptions (power, chemicals, ships), an exhaustive universal, all forms of labeling.
This standard is also used for process plants, the PPP has given space. Both are specified in DIN
60/173
6779-1, inter alia, stating that labeling for all phases of the project plans the construction, operation is
necessary, through demolition and that they are functional, space and / or product-related award and
a hierarchical structure. The issue of facility identification is in some sectors defined in great detail.
Example: If a central cooling water pipe joints in a pipe, each bolt a flange connection with a separate
identification increased. In the next section, Section 6.1.8.2 and newer standards, we will encounter in
this area, given the life of our facilities, estimated at 25 years of PPP and 30-40 for the Process
Industry, we all certainly 50 years older methods encounter.
61/173
62/173
5.7.1.5. PNS (Plant Numbering System)
http://www.innovatic.dk/plantsys.htm[12/28/2008 6:53:33 PM]
Naast KKS en AKZ kennen we ook het hieronder beschreven PNS, dit is voor een deel wel op het
KKS gebaseerd. Deze pagina werd bijgewerkt 22 Augustus 2008. Het is slechts beschikbaar in het
Engels (hier door uw auteur vertaald).
Notice of use and Disclaimer

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS PROVIDED ON AN “AS
IS” BASIS AND IS SUBJECT TO CHANGE WITHOUT NOTICE. THE PROVISION OF
INFORMATION TO YOU DOES NOT PROVIDE YOU WITH ANY LICENSE, EXPRESS OR IMPLIED,
BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS.
INNOVATIC AND MAX-I ASSOCIATION DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING WITHOUT LIMITATION, BUT NOT LIMITED TO:
 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OF THIRD PARTIES INCLUDING ANY INTELLECTUAL PROPERTY
RIGHTS INCLUDING PATENT, COPYRIGHT OR TRADEMARK RIGHTS. SUCH A THIRD PARTY
MAY OR MAY NOT BE A MEMBER OF MAX-I ASSOCIATION.
 ANY WARRANTIES OF MERCHANTABILITY, NONINFRINGEMENT, ACCURACY,
COMPLETENESS OR FITNESS FOR ANY PARTICULAR PUEPOSE.
IN NO EVENT WILL INNOVATIC, MAX-I ASSOCIATION, ITS OFFICERS, DIRECTORS,
EMPLOYEES OR AFFILIATES BE LIABLE FOR ANY LOSS OF PROFITS, LOSS OF BUSINESS,
DEVELOPMENT EXPENSES, INTERRUPTION OF BUSINESS, OR FOR ANY OTHER DIRECT,
INDIRECT, SPECIAL OR EXEMPLARY, INCIDENTIAL, PUNITIVE OR CONSEQUENTIAL
DAMAGES OF ANY KIND, IN CONTRACT OR IN TORT, IN CONNECTION WITH THIS
DOCUMENT, THE INFORMATION CONTAINED HEREIN OR ANY CHANGES MADE, EVEN IF
ADVISED OF THE POSSIBILITY OF SUCH LOSS OR DAMAGE.
YOU AGREE TO INDEMNIFY, PROTECT, DEFEND AND HOLD HARMLESS INNOVATIC,
MAX-I ASSOCIATION, ITS OFFICERS, DIRECTORS, EMPLOYEES AND AFFILIATES
(COLLECTIVELY, "INDEMNITEES") FROM AND AGAINST ANY AND ALL CLAIMS, DEMANDS,
OBLIGATIONS, LIABILITIES, FINES, LOSSES, DAMAGES AND EXPENSES (INCLUDING
REASONABLE ATTORNEYS', ACCOUNTANTS' AND OTHER PROFESSIONAL FEES, COSTS
AND EXPENSES) ANY INDEMNITEE MAY SUFFER AS A RESULT OF YOUR USE OF ANY
INFORMATION IN THIS DOCUMENT.
ELEMENTS OF THIS DOCUMENT INCLUDING COMPANY, BRAND AND PRODUCT NAMES
MAY BE SUBJECT TO THIRD PARTY INTELLECTUAL PROPERTY RIGHTS, INCLUDING
WITHOUT LIMITATION, PATENT, COPYRIGHT OR TRADEMARK RIGHTS. INNOVATIC AND
MAX-I ASSOCIATION ARE NOT RESPONSIBLE AND SHALL NOT BE HELD RESPONSIBLE
IN ANY MANNER FOR IDENTIFYING OR
FAILING TO IDENTIFY ANY OR ALL SUCH THIRD PARTY INTELLECTUAL PROPERTY RIGHTS.
This page with the above notices and this paragraph shall be included on all copies of this document
that are made.
Max-i Association
c/o Innovatic
Boegebakken 3
Gjessoe
DK-8600 Silkeborg
Denmark
Glossary and Word Definitions

The following definitions apply to all parts of the specification:
The word shall indicate a mandatory requirement to be strictly followed in order to conform to
the standard.
Shall equals is required to.
The word should indicate that, among several possibilities, one is recommended as being particularly
suitable, mentioning or excluding others; that a certain course of action is preferred, but not
63/173
necessarily required; or, that in the negative form (should not) a certain course of action is
deprecated, but not prohibited.
Should equals is recommended that.
The word may indicate a suggestion, a possibility or a permissible action within the limits of the
standard.
May equals is permitted to.
The word combination must only is similar to shall only. Must only equals is only allowed to.
Acronyms and Abbreviations

BCD Binary Coded Digit
BOM Bill of Material
CAN Controller Area Network
COM Component Object Model
DCOM Distributed COM
DEP Design and Engineering Practice
DSP Digital Signal Processor
EIS Equipment Identification System
EEP Enterprise Resource Planning
HMI Human Machine Interface
HTML Hyper Text Markup Language
IDE Identifier Extension
IPv4 Internet Protocol Version 4
KKS Kraftwerk Kennzeichen System
MAC Multiply and Accumulate
Max-i Multiple Access Cross-coupled Interface
MES Management Executing System
MIS Management Information System
NORSOK The competitive standing of the Norwegian offshore sector.
OLE Object Linking and Embedding
OPC OLE for Process Control
OPC DA OPC Data Access
OPC DX OPC Data Exchange
PCS Process Control System
PLC Programmable Logic Controller
PNS Plant Numbering System
RB0 Reserved Bit 0
RB1 Reserved Bit 1
RTR Remote Transmission Request
SCADA Supervisory, Control And Data Acquisition
SMS Short Message Service
VBA Visual Basic for Applications
XML Extensible Markup Language
5.7.1.5.1 Introduction
64/173
1.1 Basic Idea
PNS is a new numbering system for process plants. There are more basic ideas of PNS:
 To create a numbering system where the machine numbers themselves contain enough
information to enable communication with the various devices by means of field bus systems and
especially the field bus system Max-i. It shall not be necessary with separate field bus
addresses, cross-reference tables etc.
 To be able to number the various measurement types like temperature, pressure, level,
flow etc. as properties of the equipment to with they belong like tank level and temperature, pump
pressure, pipe flow etc. instead of using gauge names. This makes it much easier to overlook
the process control system. For example, production line PP2 may contain a tank - T9 (PP2T9) -
with two level switches, which controls pump PP2P1. In a traditional instrumentation drawing,
the two level switches will be named as level switches like for example PP2LG1 (level gauge 1)
and PP2LG2, but in this way, it is
only possible to tell that two level switches are controlling a pump. However, with PNS it is also
possible to use function codes like for example PP2T9L1 and PP2T9L2. Now it is obvious, that two
levels - L1 and L2 - of tank PP2T9 are controlling the pump. In the same way, the various gauges on
a pipe or a tank may also be named as properties of the pipe or the tank like for example PP2WL3F2
(water pipe 3 flow 2) and PP2WL3T1 (temperature 1).
 To be able to number all parts of the plant including spare parts with the same numbering
system. It shall not be necessary with separate numbering systems for machinery, instrumentation,
pipes etc.
 To be able to exchange data with all other systems.
 To make it possible to get a record of all components for example for flow gauge
A1FG2 just by searching the documentation for this name (without the function code), so that it
is not necessary to specify the use of a gauge. In for example numbering systems like DEP,
which uses the ISO 3511 standard, the use of a gauge is specified by means of letters
following for example F for flow, P for pressure, L for level, T for temperature and Q for any quality
parameter like pH, density, power etc. (not
specified). For example, the ISO number #FITBRQCSZA# means a flow indicator (I) and transmitter
(T) with a status display (B), a recorder (R) and a totalizer (Q), which is used for control (C),
switching (S), trip initiation (Z) and for an alarm (A). It is obvious that this number requires quite a
number of bits and a great symbol on the drawing, and if just a small thing is changed like
removing the alarm, all documentation, which contains this part, must be rewritten and
redrawn. With the ISO standard, it is hopeless (with a normal search program) to search the
documentation for equipment and components if the use is not known, because there are so many
possibilities.
NOTE! This specification is only a first draft. Everybody is very welcome to send any
comments and suggestions. The specification is primary based on experiences from feed mills and
heating and power stations so there are without doubt many equipment types missing for other types
of plants. We are also very interested in other existing number systems (other than EIS, DEP, KKS
and NORSOK).
Please send a mail or e-mail to Max-i Association. The address is:
Max-i Association
c/o Innovatic
Boegebakken 3, Gjessoe (From Denmark: B.gebakken 3, Gjess.)
DK-8600 Silkeborg
Denmark
Phone: (+45) 86 84 72 92
E-mail: mail@innovatic.dk
Background
2.1 Other Standards
Among other things PNS it is based on the following standards:
65/173
 S88.01 (ANSI/ISA-88.01) Batch Control standard (IEC 61512-1). This standard is used for
batch
production in for example the medical and the chemical industry.
 S95.01 (ANSI/ISA-95.00.01) Enterprise/Control System Integration standard. This standard
is an extension of the S88 standard.
 ISO 3511 (ISA-S5.1 and DIN 19227, part 1). This standard is widely used for instrumentation.
 EIS. This standard is for example used on many breweries. It is partly based on the ISO 3511
standard.
 DEP. This standard is used in oil refineries, chemical and gas plants, exploration and
production facilities etc. It is partly based on the ISO 3511 standard.
 KKS. This standard is for example used on all newer Danish and German power stations
and many power stations in the rest of the world.
 NORSOK. This standard is used by the offshore oil industry.
The hierarchical structure of the various standards is shown below:
Fig. 2.1
NO
NORSOK is divided into systems and equipments like KKS. It also has an Area specification
corresponding to the Plant specification of KKS, but it is not a part of the tag code.
Note, that the designations of the S88 and S95 standards depend on the way of operation - batch,
continuous or discrete. For example, a beverage manufacturer may have an area with a production
unit for continuous mixing that feeds a process cell for batch processing that feeds a
production line for discrete bottling process.
However, for a numbering system it is of course very impractical to use different designations in the
same plant.
In fact, the only difference between batch, continuous and discrete operation is that the batch
size of a continuous process is infinite and the batch size of a discrete process is fixed. If for
example the last stage of a batch process has a shutter (slide gate), which makes it possible to put
the material in bags instead of a silo, it is in fact impossible to tell whether the process should be
called a process cell or a production line because it
66/173
depends on the position of the shutter. In the same way, if a hopper scale (batch) in for example a
feed-mill is replaced by a continuous belt weight, it is no longer a process cell, but a production unit
and the unit term no longer exist so all equipment has to be renumbered. Therefore, the designations
of PNS are a general useable mix between the three operation modes of S95 and all the other
standards.
Terms and Designations
Site. A geographical production site. The site specification is typical a shortening of the geographical
location like for example AV for Aved.re. Site is another name for Plant.
Enterprise. A collection of one or more sites. The enterprise level is responsible for determining the
products to be manufactured, on which sites they will be manufactured, and in general, how they will
be manufactured. The enterprise is a part of the S95 standard, but it is not used in PNS. An enterprise
specification has no meaning for a numbering system like PNS because there is only one enterprise.
Area. An area of a site like a block on a power station. The area specification is typical a number.
Process Cell. A logical grouping of equipment, which contains all physical entities required to make a
certain product or one or more batches. A process cell may run one or more batches simultaneously.
Process cells are defined at operational boundaries in the plant, for example, where a batch loses its
identity because it is mixed with another material or batches or is used in further production.
Production Unit. The same as a process cell, but used in S95 for a continuous production.
Production Line. The same as a process cell, but used in S95 for a discrete production like a bottling
process. Two of the biggest disadvantages of S95 are the many different terms for the same level and
that a unit is not the same as a production unit, which is very confusing.
In PNS, production line is used as a common term for process cell, production unit and production
line.
Train. An individual part of a process cell needed to make one or more parts of a batch. A process cell
may have more than one train, and the order of equipment used to make a particular batch is called a
Path.
Unit. A logical part of a train. A unit is typically centered on a major piece of processing equipment,
such as a generator, a boiler, a mixing tank, a reactor, a mill, a pellet press, a silo group etc. In for
example a feed mill, there may be six units - intake of raw material, weighing and dosing, milling,
mixing, pellet pressing and delivery. The unit's primary defining requirement is that it can operate
only on a single batch at a time. This does not mean that a batch must be in a single unit. In
fact, during material transfers, a batch must be contained in at least two units. The last part of a unit is
normally a storage element like a silo, a vessel or a tank, and in many cases, they are controlled by
their own field bus so that an error on one bus does not affect the operation of other units. The
units provide the major partitioning of the train equipment. They also are the major structuring
elements used in recipes, because the major elements of master and control recipes in the S88
standard are organized as unit procedures. A good way of spotting a unit is by determining if a part of
equipment must run a recipe or needs some information like the silo number in order to operate. If so,
it is a unit. If not, it is equipment used by a unit.
Working Cell. The same as a unit, but used in S95 for a discrete production.
System. The same as a unit. Used in KKS and NORSOK. An example of a KKS system is HFE,
which stands for "Air system for solid fuel boiler".
Line. A single conveying, processing, or driving line or chain within a unit like for example:
 A row of silos.
 A chain conveyor with shutters and two-way valves.
 A pipeline.
 A big equipment unit with its driving line likes for example a diesel engine, a turbine, a gearbox, a
brake etc.
 An equipment module likes for example a filter with cleaning equipment and aspiration.
Equipment. A single process equipment within a line like a weight, a conveyor, a valve, a pump, a
tank, a pipe etc.
Final Control Element. Used in S88 for those types of equipments, which are used to control the
process like actuators, sensors, valves, pumps etc. In PNS and most other numbering systems, a
final control element is regarded as the same as an equipment.
Control Module. A collection of final control elements, which acts as a single entity from a control
standpoint like for example a control loop that operates via the set point. A control module has a direct
connection to the various actuators and sensors. An example of a control module is a pump with flow
control. Even though the control module exists in the S88 physical model, not all elements
67/173
need be physical. For example, the PID controller can be a PLC instruction or DCS object and
not a stand-alone device that physically links the flow gauge to the pump.
Equipment Module. A collection of control modules, which can carry out a finite number of minor
processing , i.e., phases. An equipment module is able to receive high level phase commands
like for example Circulate, Pump-to-Process, Stop, Shutdown etc. and generate high level
status messages like Circulating, Pumping-to-Process, Stopped, Shutdown etc. An equipment
module runs the same commands regardless of the product. The equipment module is a part of the
S88 standard.
Function. A single equipment function like a motor current, a tank temperature, a pump pressure, a
pipe flow, a start/stop function, the operation status, the operation mode
(automatic/semiautomatic/manual) etc.
Component. A physical device, which is able to perform one I/O function like a pushbutton with lamp
for the start/stop function or a rotary gauge for the operation status.
Attribute. A data storage location within a component, which is able to hold one value like
configuration and calibration parameters, error word, vendor ID, type number and serial number etc
Exchange of Data
4.1 Tiers
One of the most important properties of a modern process control system is the ability to exchange
information between different systems and equipment from different manufacturers. This is for
example one of the main reasons for using field bus systems.
A modern automation system may consist of three tiers:
1 EEP
Sales and Distribution
E-Business
Supplier and Supply Chain Management
Customer Management
Finance and Book-keeping
Prognosis and Budgets
Assets and Liabilities
Cash Flow
Human Resources and Salary
Resource Planning
BOM
Production Schedule
Time horizon: Months, weeks, days
2 MIS and MES
Warehouse Management
Batch Management
Tracking and Traceability
Production Management
Production Codes and Lot Numbering
Production Analysis and Quality Control
Production Reporting, Yield
Data Historian
Time horizon: Hours
3 PCS
Material Managing
Batch Execution
Process Visualization / SCADA system
Process Control / PLC's
Actuator and Sensor Interface
Time horizon: Minutes, seconds, milliseconds
Fig. 4.1
There are two standard ways of exchanging information between the different tiers - the old Microsoft
way and the heterogeneous way. The old Microsoft way is based on the object oriented programming
68/173
model COM, which is the core of DCOM, ActiveX, VBA, OLE, OPC, OPC DA and OPC DX. However,
these technologies are only usable on Microsoft
platforms and they suffer from fairly high complexity and great difficulties with different software
versions. With COM, all pieces of an application has to be deployed at once, so it is not possible to
link in new applications dynamically.
The heterogeneous way, which is also used on newer Microsoft systems, is based on the Internet
standards HTML and XML. HTML is the standard language for displaying information for human
consumption. XML is the standard language for exchanging information for automated consumption.
The benefit of HTML and XML is that these languages are very simple text based languages, which
may be used on many different platforms and generated very easily. Unlike traditional method
based systems, XML is self-describing with a name and description for each value and meta
data telling how the telegram should be interpreted. It is therefore not necessary to have an
exact number of arguments and to supply them in a precise order, so the various
applications may be much looser coupled than with for example DCOM. Because each value has a
name, XML fits perfectly together with field bus systems using the very efficient
producer/consumer model like Max-i and
CAN. On the other hand, all this extra information makes XML extremely inefficient. XML is hopeless
to use directly on for example a field bus system. Therefore, one of the primary goals of PNS is to
make a system, which will enable an unambiguous and loss less conversion between XML and an
efficient field bus protocol.
4.2 XML Data Identification
A typical XML telegram for starting a fan for a solid fuel boiler and reading the hour counter of the fan
may for example look like this (without any header and meta data):
This telegram fills 292 bytes plus any header and meta data just for transmitting one Boolean value
and asking for one analog values. In a very fast high level Ethernet or FireWire (IEEE 1394)
system or internal in a computer this may not be a problem; but for a field bus, it is of course much
too inefficient although the telegram length may be reduced to almost the half by removing most
of the space characters. Therefore, a loss less compression algorithm must be found. The
first step has already been taken in the above example by combining the Site and Area
specification (site Area).
What the first part of the telegram actually does is to transmit the Boolean value 10B to the function:
Avedoere / Area (block) 3 / Solid fuel boiler line 1 / Fan 101 / Command 1
If the possibility in XML for using nested sites, areas, production lines, equipments and functions is
not utilized, this information may be removed and added later on. This creates a fixed hierarchical
structure of:
This may seem as a limitation, but practical experiences with for example DEP and KKS, which are
based on a similar fixed structure has shown that this works very well in practice. Complex
equipment like a filter may contain several smaller equipments like an air lock, a fan, a cleaning
system etc., which could indicate the need for nested equipment, but in such cases, various
equipments may just be grouped together by means of a common line number. Some
numbering systems like KKS and DEP has a limited possibility for nesting, which makes it possible to
number for example a motor, a diesel engine or a pump within an equipment. However, if an
equipment is so big that it is important to number the various sub-equipments, it is usually also
important to communicate with this equipment for example for reading the motor current or the
pump pressure, but this possibility usually does not exist. It is only possible to access data and
69/173
signals from the main equipment. If attributes are needed for general data for the production
line, the SCADA system must build a "soft"
equipment and a "soft" function to hold these "soft" attributes, as it is not allowed to place a function
directly under a production line. The name of the soft equipment should be the same as the
production line (instead of for example Conveyor, Pump etc.).
By removing the nesting possibility the following general XML telegram structure is generated:
Parameters in () are optional. For example, value (and time) is only specified if a value or
attribute is broadcasted – not if it is polled. Attribute and global-attribute is used to read or write
configuration or calibration parameter (global-attribute is write-only). If none of these is specified,
the telegram contains a process value (default).Unfortunately, XML is case sensitive, so that for
example site Area, Site Area, site area and SITEAREA are not
the same. In PNS, it has therefore been defined that all names shall start with a capital letter and all
parameter designations like site Area shall start with a lower case letter. The following letters
shall be lower case letters except for the first letter in each part. The various parts should not be
separated by means of signs like "-" or
"_".
4.3 Standard Names
The next step in the compression process is to replace the names for the site, production line,
equipment and function with codes exactly in the same way as it is done in most numbering systems.
For example, in KKS the long system name "Air system for solid fuel boiler" is replaced with
the much shorter "HFE", the equipment name "Fan" is replaced with "AN" and the component
name "Pump motor" is replaced with KP. This standardization has the further advantage that it
makes any language conversion very easy. If for example a
system is delivered to Russia and is described with Russian letters in a non-ASCII text
string it would be extremely difficult to debug for western personal, but with standard name
codes it is possible to select any language without making any changes.
In PNS (and most other numbering systems), all codes consist of English Latin capital letters, that is,
the letters A-Z.
4.3.1 Site, Area and Production Line
The site and area is specified by means of two letters for the site followed by a number in the range
1-8 for the area like AV3. The two-letter code is just a user-defined shortening of the site location like
for example AV for Aved.re. If PNS is going to be used on a single area, the site and area
specification may be omitted. The production line code is a three-letter user-defined code for the
name of the production line followed by a number in the range 1-99 like PP1 for pellet press line 1.
This is the same as the KKS system code (described later), so that this code may be used.
4.3.2 Equipment Codes
70/173
Group I and U are used for user-defined equipment. The user should define the meaning of the first
letter. If the plant is not a nuclear power plant, group N is also free for user-defined equipment. Note
that in the following a single letter equipment code refers to this second letter of the two-letter
equipment code.
The codes for the first letter should have the definitions shown in the following. Note that
while the second letter is a mandatory requirement of the standard, the first letter is only a
recommendation and may be changed according to the present needs! Because group O is not used,
the binary code for this is instead used to specify a one-letter code, which only consists of the
previously defined second letter. This group always has the name of the main group like F for filters, P
for Pumps, T for Tanks etc. It may be used if it is not necessary with a more detailed specification or
in case of the Q code, which has no first letter. Any unused codes may be used for user-defined
equipment.
71/173
7.9.6 ISO/TC 10, from DIN-9776 to the harmonised ISO/IEC 81346
5.10.2.1 ISO / TS 16952 with the following basic standards such as DIN
5.10.2.1.1 Structuring for managing complexity

As information regarding technical properties, especially in larger installations or complex
products are now often stored in large databases,
and through a systematic approach and retrieve the information.
This systematic approach is based on generally accepted principles that ensure that the
structuring of a comprehensive harmonized approach to this task.
The international standard IEC 61346 series offers such as structuring principles and basic
rules for the coded description of the structures mentioned reference manual.
However, it was within the ISO / TC 10 recognizes that an efficient, ergonomic, economical and
large scale industrial application of unified reference designation can not get through the
principles and general rules only.
A reference to a system of industry-specific needs related to compliance with a generally
applicable concept is the internationally agreed solution. Therefore, the development of a user,
instruction-for-like use Designation Reference System (RDS) was launched at the ISO
(International Organization for Standardization) platform.
As a technical specification ISO / TS 16952 series, this multipart standard to ensure a uniform
unambiguous description of technical objects in all technical fields.
The following DIN standards have such a model for the development or ongoing development
of the ISO / TS 16952 series
DIN 6779-1 Grundlagen
DIN 6779-2 Kennbuchstaben; Haupt und Unter Classes Classes Zweck oder für ufgabe
von Objects
DIN 6779-10 Kraftwerke
DIN 6779-11 Schiffe und Meerestechnik
DIN 6779-12 Bauwerke und technical Gebäudeausrüstung
DIN 6779-13 Chemieanlagen
ISO / TS 16952-1:2006
ISO / TS 16952-1:2006 provides detailed and practical principles and rules governing the
appointment of the technical objects within a system, and for the identification of compounds,
signs and documents in conformity with the fundamental principles of the standards ISO / The
TS 16952-1:2006 is applicable to all technical areas for all industries and can be applied at all
stages of the lifecycle of a technical object. ISO / TS 16952-1:2006 is the basis for sector-
specific parts of ISO / TS 16952 and thus form the connecting link between them and the basic
IEC 61346 series. The designation of species, individuals, cost centers, projects, etc. not
covered by ISO / TS 16952-1:2006.
The following figure, the now successful harmonization of standards in a number of rules for
the designation, the functional code .. Note that the ISA (yet) know the same codes, but other
IEC work is still not in step.
5.10.2.2. Harmonization of rules for the designation, the functional code ...
.
72/173
ISO/TS 16952- deel 10 :2008 de opvolger van het KKS deel,specifiek in deel 10
ISO/TS 16952-1:2006 establishes comprehensive and practice-oriented principles and rules for
the designation of technical objects within a system, as well as for the designation of connections,
signals and documents in accordance with the corresponding basic standards.
The principles of ISO/TS 16952-1:2006 apply to all technical fields for all industries and can be
applied in all phases of the life cycle of a technical object.
ISO/TS 16952-1:2006 serves as the basis for sector-specific parts of ISO/TS 16952 and thus
forms the connecting element between them and the basic IEC 61346 series.
The designation of types, individuals, cost-centers, projects, etc. is not covered by ISO/TS 16952-
1:2006.
ISO/TS 16952-10:2008 contains sector-specific stipulations for structuring principles and

reference designation rules on technical products and technical product documentation of power
plants.
It applies in combination with ISO/TS 16952-1, IEC/PAS 62400 and VGB B 101 for the
classification of systems and objects, and for function-, product- and location-specific designation
of technical products and their documentation for power plants.
It specifies the designation blocks for the clear identification and localization of the technical
products, which are used for their labeling in the plant, for their designation in technical
documents and for the designation of the technical documents as well.
73/173
ISO/TS 16952-10:2008 encompasses the process of energy conversion. The specifications in
ISO/TS 16952-10:2008 apply for the power plant process, for the primary energy supply and final
products distribution, as well as for auxiliary media and auxiliary energy supply, waste materials
and waste energy disposal.
ISO/TS 16952-10:2008 is not applicable to recovery of the primary energy and the media for
supplying the process, nor to the processing of residues from process disposal (e.g. gypsum, slag
products, waste water, etc.).
IEC 61346 is an electrical standard entitled "Industrial systems, installations and equipment and
industrial products - Structuring Principles and Reference Designations. It sets voluntary standards on
how the structure and systems generate reference designations. It has the following contents.
Part 1: Basic rules (IEC 61346-1:1996)
Part 2: Classification of objects and codes for classes (IEC 61346-2:2000)
Part 3: Application guidelines (IEC / TR 61346-3:2001)
Part 4: Discussion of concepts (IEC 61346-4:1998)
Retrieved from "http://en.wikipedia.org/wiki/IEC_61346"
Future Standards IEC / ISO 81346

Future developments of the standards designations will be made in cooperation between the IEC and
the ISO and published as IEC / ISO 81346. This must all stand arden exchange, see the rightmost
74/173
block in the figure above, harmonization of rules for the dessignation, the functional code (standards
developed in cooperation between IEC and ISO 80000 are now numbers in the series)
Ongoing maintenance and new projects in the standards (2009-05)
IEC 81346-2 Ed. 1 is under review. IEC 81346-1 was published. The work is performed by the
Maintenance Team TC3/MT18 with the participation of ISO TC10. The revised publication is intended
to be published under number IEC 81346, stating that a joint IEC / ISO range of publications aimed at
taking parts of both organizations.
The content of IEC 61346-4 IEC 81346-1 is bound (and -2).

A committee Guided Design, document 3/842/CD, was circulated for comment with a deadline for the
end of June 2008. The comments were handled by the MT at a meeting in early September 2007,
and the spread of an ISA, 3/889/CDV document, took place in January 2008 with a closing date
28/06/2008. Delyed circulation by the end result was not available until 2008. The outcome of the vote
was available in 3/889/RVC document: the document was approved with one negative vote.
The FDIS is based on the observations and document 3/947/FDIS circulated for final vote (in both
IEC TC3 and ISO/TC10), closing 07/18/2009.
A Guided Design Committee for Part 2, 3/844/CD document based on IEC 61346-2 Ed.1 and IEC /
PAS 62400 Ed. 1, was circulated for comment, with a deadline for the end of July 2008. The
comments on the CD were treated at the meetings of MT18 in September 2007 and February 2008.
3/904/CDV was circulated in the outcome of the vote in the 3/941/RVC document: the document was
approved with one negative vote. The FDIS is based on the observations and document 3/945/FDIS
circulated for final vote (in both IEC TC3 and ISO/TC10), closing 07/10/2009.
A New Work Item Proposal: 3/810/NP Rules Identifiable systems, was circulated for approval within
ISO and IEC TC10 TC3. The project was approved as IEC 62507 Ed. 1 in TC3 and TC3/PT 39 was
established. 3/836/RVN document details the results and comments. As a result of the work in PT 39
3/908/CD IEC 62507 Ed.1 document: Requirements for identification systems enabling unambiguous
information exchange - Part 1: Principles and Methods, was circulated for comment, the ditch
26/09/2008 . The comments were discussed during a meeting with the PT and document 3/946/CDV
(same title) was prepared. It is ready for use with a French version in July 2009.
RDS-PP – Transition from the KKS to an international standard
Dipl.-Ing. Harry Königstein (Steag-SaarEnergie, Saarbrücken), Ing. grad. Heinz Müller (Siemens
Power Generation, Erlangen), Dipl.-Ing. Jörg Kaiser (VGB-office, Essen)
Abstract:
New and withdrawn standards and the revised EU Directives relating to reference
designation and plant documentation also have a significant impact also on the KKS power plants
reference designation system run by VGB PowerTech.
To gain acceptance on the international markets, to ensure compliance with valid standards in
conjunction with conformity declarations and to satisfy safety provisions in plants, both manufacturers
and operators needed to adopt the KKS to current rules and regulations. The work was carried out in
the VGB "Reference Designation and Plant Documentation" Working Panel and resulted in a
technical standard for reference designation in power plants and a key for power plant systems - the
"system key". Experience and known potentials for improvement in the use of KKS complete the
adoption and creation of the KKS replacement system. The new standardized reference designation
system is called
Reference Designation System for Power Plants RDS-PP
The technical standard is based on the basic principles of international standards and takes into
account nearly all the KKS structures. Around 90% of the code letters in the KKS function key were
transferred to the new system key. KKS aggregate and equipment key will be replaced in the new
reference designation system by a standard in which the code letters are standardized globally for
specialist areas and sectors. These code letters do not unfortunately always match the KKS-
specifications.
There are tools available for comparing RDS-PP to KKS and for performing the required
conversion from KKS to RDS-PP. These tools support the transfer of the KKS function key to the
RDS-PP system key and from the aggregate and equipment key to the code letters in the
international standard.
75/173
The article depicts the development of the new reference designation system from the point of view of
standardization, describes the main features, mentions offers of support by the VGB “Reference
designation and plant documentation” working panel and provides recommendations for future use.
1. General
The KKS Identification System for Power Stations has been successfully used worldwide since the
early nineteen seventies for the designation of plants, technical equipment and components in power
plants.
The issuing of international basic standards on reference designation in the year 1996 and the
quoting of such standards in European directives and harmonized standards called for an adjustment
of the KKS to such specifications.
The main motivation for this was for the manufacturers to assert themselves in the European and
worldwide markets by ensuring conformity with the standards and for the power plant operators to avail
themselves of a standardized equipment designation basis for their work.
The basic principles necessary for such adjustment and certain amendments of the KKS were developed
in the VGB Working Panel "Reference Designation and Plant
Documentation" jointly by manufacturers and operators and contributed to the national and international
standardizing activities. The main objective was to arrive at a sector-specific standard for power plants. The
result is now available:
In April 2007, the Joint Committee for Reference Designation Systems (GAKS) at the DIN published the
national standard DIN 6779-10 "Structuring principles for technical products and technical product
documentation – Part 10: Power plants".
The reference to the basic standard IEC 61346-1 bearing the subtitle "Structuring principles and Reference
designation" then gave the name for the KKS successor system: Reference Designation for Power
Plants – RDS-PP.
2. History
In March 1969, three manufacturing companies published in the technical journal
"Elektrizitätswirtschaft", an article entitled "System zur Kennzeichnung von Geräten und Anlagen in
Wärmekraftwerken" (System for the designation of components and plant equipment in thermal power
plants). The designation system referred to in this article was designed for the needs of planning,
constructing and operating mechanical and electrical systems and in application became known by the
name of "Anlagenkennzeichnungssystem" (Plant Designation System), in short "AKS" or "AKZ System".
The system used various code letters from other standards, e.g. the "device identifier" for electrical
components from DIN 40719, supplementary sheet 1.
In the early nineteen seventies, the experience gained in the application of the AKZ System resulted in the
further development of the system by the VGB Working Panel "Technical Classification Systems", in which
operators, experts, authorities and manufacturers were equally represented. The result, the "KKS
Identification System for Power Stations" was published by VGB as Guideline B105. The guideline was
complemented by so-called "Key Parts" (function,
equipment unit and component keys) and "Application Explanations". Apart from electrical
components, also equipment items of mechanical systems could be identified according to the KKS
specifications. Furthermore, the KKS was used as a basis for the designation of signals, connections
and documents.
76/173
The publication of IEC 61346-2 and DIN EN 61346-2 for the classification of technical objects across
all technical disciplines and the associated withdrawal of DIN 40719-2 in the year 2000 resulted in a
situation where KKS code letters are used that are not covered by a valid standard. International
specifications and requirements were thus no longer reflected in the KKS.
This was an urgent reason to revise the KKS and adjust it to the new requirements resulting from the
international codes. Taking into account DIN 6779-1, members of the VGB Working Panel "Reference
Designation and Plant Documentation" (successor panel of the Working Panel "Technical
Classification Systems") were instrumental in developing the sector-specific standard for power plants
DIN 6779-10 entitled " Structuring principles for technical products and technical product
documentation – Part 10: Power plants".
This national standard was submitted as a proposal to the ISO and accepted. It is currently
undergoing the consultation process and is expected to be published in early 2008 as an international
standard under the number ISO TS 16952-10. IEC and ISO have agreed to publish the various
standards relating to reference designation resulting from the ongoing revision work under a common
series of standards with the number 81346.
3. Characteristic features
The Reference Designation System for Power Plants – in short RDS-PP – results from the consistent
further development of the successful KKS Identification System for Power Plants. It has thus the
characteristic features of a proven identification system:
_ applicability to all power plant types,
_ consistency throughout the entire life cycle,
_ identity in sense for all technical disciplines,
_ language independence.
The RDS-PP expands the KKS by the designation blocks
_ "Conjoint designation" for the designation of plant sites and plant complexes, and
_ "Functional allocation" for the designation of dynamic processes.
The RDS-PP is based on structuring principles, designation rules and letter codes specified in
international standards published by IEC and ISO and fulfill the prerequisites for
_ finding worldwide acceptance, and
77/173
_ application of the same, standardized code letters.
The RDS fulfils the requirements of European Directives in terms of
_ operational safety,
_ ergonomics,
_ procurement, and
_ declaration of conformity.
The RDS-PP is in full agreement with the national/international sector-specific standards for power
plants DIN 6779-10:2007-04 and ISO/TS 16952-10 and thus complies with the mentioned
international standard for reference designation systems. The RDS-PP can thus be considered to be
a standard-conforming designation system.
4. Codes of practice
The Reference Designation System for Power Plants RDS-PP consists of the following standards,
guidelines and application explanations:
_ Sector-specific standards DIN 6779-10 and ISO TS 16952-10,
_ Guideline VGB B101d and B101e for power plant systems (System key)
_ Basic standards DIN 6779-2 and IEC PAS 62400
_ Discipline-specific and power plant-specific application explanations.
Figure 2 gives an overview of the codes of practice, including the basic standards
4.1 Sector-specific standard

The sector-specific standard DIN 6779-10 is based on the general basic standards (see Fig.2) and
contains sector-specific specifications and rules relating to designation tasks, code structure and
code representation as well as examples of use. The appendix (informative) offers a check list for the
definitions between the project-taken part as well as application examples.
The sector-specific standard is comparable with VGB guidelines B105 for the KKS.
Hereinafter, the main focuses of the sector-specific standard are described, pointing out differences
from the KKS.
The general code structure consists of a maximum of three parts that can be combined according to
defined rules:
78/173
The sector-specific standard fully satisfies the basic principles of structuring which can be done under
various aspects. The power plant is broken down according to the aspects "Function", "Product" and
"Location". The Function aspect views an object by its functionality, the Product aspect by its physical
composition. The Location aspect describes which locations are made available by the same object
for other objects. For each view/aspect, a tree structure can be developed in which the rules of
partitive relation prevail ("consists of"/"is part of"), the relations between the trees are so-called role
relations (dashed lines in Fig. 3).
The designation for various aspects or tasks is done in designation blocks with a fixed structure. The
general structure consists of a prefix followed by a designation code consisting of letters and
numbers. Letters are used for the classification of technical objects, using code letters from the VGB
System Key and DIN 6779-2 and IEC PAS 62400, respectively; numbers are used to distinguish
between objects designated by the same code letter.
79/173
Hereinafter, the designation blocks according to RDS-PP are described.
Designation block "C o n j o i n t d e s i g n a t i o n"
This designation block can be used for identifying sites, plants, power plant units and has to be
agreed between the parties involved in the project. It represents none of the three basic aspects;
application of this designation block is optional.
This designation block is a new feature. It includes the structural level GS0 of the KKS.
The following figure shows several sites, hydroelectric power plants and control stations in the upper
Danube area.
Designation Block "F u n c t i o n"
80/173
This designation block is used for function-oriented designation, from the view of task and purpose of
the technical object. It corresponds to the breakdown levels 1 and 2 of the KKS process-oriented
identification code, but without the prefix number of the system code and the additional equipment
unit code (see also 4.2.3).
A novelty compared to the KKS is the change of breakdown level 0. If necessary, several systems can
be combined here.
The following figure illustrates this option, using the example of a gas and steam turbine combined
cycle plant.
It is not possible to define universally valid coding letters for the breakdown level 0. For the specific
application case, the coding letters have to be agreed between the parties involved in the project. The
letters used in the following figure were chosen arbitrarily.
Designation block "F u n c t i o n a l a l l o c a t i o n"

This designation block is used for function-oriented designation under the aspect of
interaction of technical objects. It differentiates between group level and individual level. This
designation block is new. It governs the uniform designation of processes and the allocation of control
tasks, which used to be done differently in the KKS.
The basic flow diagram in Fig. 7 shows the process of a thermal power plant, identifying the
uppermost structural levels, the functional areas.
81/173
Designation block "P r o d u c t"
This designation block is used for product-oriented designation of electrical and mechanical objects
and together with the designation block "Function" forms the unambiguous component designation
code.
Designation block "E q u i p m e n t"

This designation block is used for unambiguous identification of technical objects. It makes use of the
possibility to consider objects following in succession according to different aspects and allocate
different prefixes to them. For power plants, the transition from function to product aspect is used.
This designation block corresponds to the "process-oriented identification" used in the KKS.
Among other things, the equipment unit code is used as an identifier for plant data
82/173
management systems and can be related to equipment items and/or product types and their data.
The following figure shows the basic principle.
Designation block "P o i n t o f i n s t a l l a t i o n"

This designation block is used for designating the points of installation of technical objects. In addition
to the hitherto existing possibility to identify electrical and I&C installation units, designation masks
were created for the location-oriented designation of mechanical equipment. This permits, for
instance, accurately locating the sampling point for a measured value on a pump set by using the
component code under the location aspect.
Designation block "L o c a t i o n"

This designation block is used for designating locations, such as structures, areas etc.
Signaldesignation
The unambiguous designation of signals is achieved by combining the reference
designations and the signal name according to the following structure:
Ranges of numbers were defined for the signal sections (2nd letter of the signal name) "B =
single control", "G = binary process signals" and "H = limit signals", e.g. XB01 for check-back
signal ON/OPEN, XB02 for check-back signal OFF/CLOSED.
Terminaldesignation
The unambiguous designation of terminals on electrical or mechanical equipments is
83/173
accomplished by combining reference designations and terminal designations according to the
following structure.
Documentdesignation
Non-manufacturer-specific, object-related designation of documents is achieved by
combining the object designation with the document type class key according to the following
structure:
As object designation, primarily the reference designation should be used, but other
classification systems may also be used depending on the application case, e.g. type
designation for the dimension drawing of a series product.
The structure of the document type classification code DCC with counting number and the code
letters are fully in accordance with DIN EN 61355.
4.2. Guideline and standard for letter codes

The sector-specific standard allocates tables from two different codes of practice to alpha digits of the
individual designation blocks.
4.2.1 VGB Guideline B101 "Letter code for power plant systems (system key)"
For breakdown level 1 of the designation block "Function" and the designation blocks based
thereupon for "Point of installation" and "Location" as well as "Functional allocation", VGB. Guideline
B101, "Letter code for power plant systems (system key)" is applicable. Guideline VGB B101 was
developed by the VGB Working Panel "Reference Designation and
Plant Documentation" and is the binding letter code for power plant systems. Due to the reference
contained in the sector-specific standard, this guideline gets normative
significance. B101 is based on the basic standard DIN EN 61346-2 which in table 2 provides a
framework for a classification model for so-called infrastructure objects. In this table, the letters A, V
to Z are generally specified, whereas the letter range from B to U is available for sector-specific
specifications.
84/173
This free range from B to U was used to incorporate - almost without changes – the function key of
the KKS. However, the following changes were unavoidable:
The system key replaces the KKS function key.

As in the KKS, the system key uses a three-digit letter code and defines the limits for certain systems.
With regards the designations, some adjustments were made to reflect the terminology currently
used, e.g. in VDE 0100-200.
Fig. 11 – Except from the "VGB System Key" B101
The system key is constantly updated by the VGB Working Panel "Reference Designation and Plant
Documentation".
85/173
4.2.2 Basic standard DIN 6779-2 and IEC PAS 62400
For breakdown level 2 of the designation block "Function" and the designation blocks based
thereupon for "Point of installation" and "location" as well as "Functional allocation", and for the
breakdown levels of the designation block "Product", DIN 6779-2 is applicable on the national level
and its English version IEC PAS 62400 on the international level. The basic standard DIN EN 61346-2
classifies technical objects according to their purpose or task and in table 1 specifies code letters for
the main classes. DIN 6779-2 and IEC PAS 62400, respectively, expand these main classes with
subclasses with a second code letter. These specifications are generally applicable to all disciplines,
such as civil, process, mechanical and electrical engineering, across all industries. This basic
standard replaces the KKS equipment unit key and the KKS component key and is thus a significant
deviation from past designation practice. The following table shows some examples to illustrate the
differences in code letters and designations.
The following figure shows an except from Table 3 of IEC PAS 62400, including the
subdivision by technical disciplines:
CA – CE Storage of electric energy
CF – CK Storage of information
CL – CY Storage of materials, thermal and mechanic energy
86/173
4.2.3 Comparison of designating letters as per KKS and RDS-PP
The following figure is to clarify the codes of practice applicable to code letters by way of comparison
of KKS vs. RDS-PP.
87/173
4.3 Application explanations
Standards provide general rules and specifications. In order to facilitate efficient
implementation in practice, application explanations have been developed by the VGB Working Panel
"Reference Designation and Plant Documentation". They provide detailed guidance, starting with a
cross-discipline Part A and then addressing the specific engineering disciplines of mechanical
engineering, civil engineering, electrical and I&C engineering, and I&C functions in process systems
(Parts B1 to B4). The application explanations contain examples from practice and have also been
conceived for training measures.\
5. Consequences
Frequently asked questions in connection with the introduction of the RDS-PP include:
_ What does this now mean for
- my existing plant,
- my plant which is currently in the pipeline, or
- a new plant I will set up in future?
_ From when on do I have to use the RDS-PP?
_ Will the KKS then be no longer valid?
_ …..
Unfortunately no simple "Yes/No" answers or binding deadlines can be given to answer these very
important and specific questions.
88/173
In general it has to be said that standards are not binding laws, their application has to be agreed
between the parties to the contract. An obligation to apply a standard can result from legal or
administrative regulations or from contracts or other legal grounds.
Furthermore, if assessing an order of priority among various requirements, an international standard
will have priority over a VGB guideline, even though the latter via the VGB's status as an international
trade organization enjoys international recognition. Standards always become a matter of particular
interest if no amicable solution between contracting parties is found or if man or equipment suffers
damage. In these cases, the basic principle is applicable that the requirements can be deemed
fulfilled if the state of the art (which is normally reflected in standards) has been adhered to. That may
be the requirements of a specification in the bidding process, but that may also be the requirements
for the safety of man and equipment. If no valid standards are used, the party concerned will have to
prove – if necessary with the assistance of third parties – that the solution chosen by such party
likewise meets the requirements. These explanations do certainly not provide a concrete answer to
the questions asked above and do not nearly fully cover the complex of tendering procedures,
product safety, industrial safety etc.; they are merely meant to outline the complexity of the issue.
Nevertheless the following facts can be summed up and should be considered in making a decision
on the designation system to be used:
The KKS is an (international) "house standard" of VGB, which in absence of normative standards
reflected the state of the art until international standards were published.
The KKS partly refers to withdrawn standards. The problem can not be solved with the structure
and the known KKS keys.
To date little or no experience has been gained in the application of RDS-PP; on the
basis of past experience, initial pilot applications can be expected to be somewhat
rocky and need special care and assistance.
Possible problems or additional expenses may result for the operator if different
designation systems are used at the same site; these problems may concern the safety of plant and
persons but also the operation and maintenance management systems.
The RDS-PP is (after official publication of the ISO/TS 16952-10) a designation which is supported
by international standards.
The RDS-PP integrates systematic structures and letter codes which are applicable to all
industries, which in the medium term will result in an easier integration of "standard components" into
the power plant process.
Suppliers of "standard components" can not decline the request for designation
according to RDS by just alluding to standards that are applicable in other industries or
to their house standards. This makes it easier to make also such suppliers adhere to
the RDS-PP; this will relieve planners and operators of time consuming and costly
reworking.
Once RDS-PP has gained the acceptance of planners and manufacturers, the tools will also be
changed correspondingly. Designation according to KKS will then be available only at extra cost, e.g.
for CCS (carbon dioxide capture and storage) retrofit projects.
Successful implementation of the RDS-PP within a limited time frame will be possible if the
operators require designation according to RDS-PP in their specifications; this will trigger the swift
development/adjustment of tools at planners and suppliers.
Due to the international set-up of many planners and manufacturers, the economic
interest for a system will prevail which goes beyond the "VGB scope".
KKS and RDS-PP will coexist for many years and will also have to be cared for. The
know-how for servicing the KKS will diminish step by step.
Plant operators, too, must develop in-house know-how for RDS-PP; the VGB training
centre for power plant operating staff will support this process with suitable training
courses.
However, the authors do not want to get around concrete recommendations:
Existing plants:
_ currently, there is no need for action,
decisions should be made in the individual instance, on occasion of substantial plant
modifications or retrofit projects
Plant retrofit or modernization projects:
_ existing projects or projects that are in the pipeline should be continued as planned;
Possible problems or additional expenses may result for the operator if different
89/173
designation systems are used at the same site; these problems may concern the safety
of plant and persons but also the operation and maintenance management systems.
The RDS-PP is (after official publication of the ISO/TS 16952-10) a designation which is supported
by international standards.
The RDS-PP integrates systematic structures and letter codes which are applicable to all
industries, which in the medium term will result in an easier integration of "standard components" into
the power plant process.
Suppliers of "standard components" can not decline the request for designation
according to RDS by just alluding to standards that are applicable in other industries or
to their house standards. This makes it easier to make also such suppliers adhere to
the RDS-PP; this will relieve planners and operators of time consuming and costly
reworking.
Once RDS-PP has gained the acceptance of planners and manufacturers, the tools will also be
changed correspondingly. Designation according to KKS will then be available only at extra cost, e.g.
for CCS (carbon dioxide capture and storage) retrofit projects.
Successful implementation of the RDS-PP within a limited time frame will be possible if the
operators require designation according to RDS-PP in their specifications; this will trigger the swift
development/adjustment of tools at planners and suppliers.
Due to the international set-up of many planners and manufacturers, the economic
interest for a system will prevail which goes beyond the "VGB scope".
KKS and RDS-PP will coexist for many years and will also have to be cared for. The
know-how for servicing the KKS will diminish step by step.
Plant operators, too, must develop in-house know-how for RDS-PP; the VGB training
centre for power plant operating staff will support this process with suitable training
courses.
However, the authors do not want to get around concrete recommendations:
Existing plants:
_ currently, there is no need for action,
Plant retrofit or modernization projects:
_ existing projects or projects that are in the pipeline should be continued as planned;
6 Documentation
As already explained in the chapters above, the RDS-PP consists of several components which are
summed up again below, along with information on their status and the respective reference
documents:
DIN 6779-10 Structuring principles for technical products and technical product
documentation - Part 10: Power plants
- most important national standard, replaces KKS guideline
(Beuth-Verlag)
ISO/TS 16952-10 Technical product documentation – Reference
designation system – Part 10: Power Plants
- most important international standard, replaces KKS guideline, to be published in Q1/2008
(Beuth-Verlag)
DIN ISO/TS 16952-10 Kennzeichnungssystematik für technische Produkte und technische
Produktdokumentation – Teil 10: Kraftwerke
- German version of ISO/TS 16952-10
to be published in Q1/2008, replaces DIN 6779-10 (Beuth-Verlag)
DIN 6779-2 Structuring principles for technical products and technical product
documentation - Part 2: Lettre codes - Main classes and sub classes
of objects according to their purpose or task
(Beuth-Verlag)
IEC/PAS 62400: Structuring principles for technical products and technical product
Documentation - Letter codes - Main classes and subclasses of objects according to their purpose
and task (Beuth-Verlag)
VGB-B 101 RDS-PP Reference Designation System for Power Plants (system
key), English version to be published in November 2007 (VGB PowerTech Service GmbH)
90/173
VGB-B 116 RDS-PP Reference Designation System for Power Plants, Application
explanations, to be published in December 2007 (German version) and April 2008
(English version) (VGB PowerTech Service GmbH)
Software-Tool Supplementary information and an efficient way of experiencing the
RDS-PP and the interrelations in designation and documentation by
selected examples, to be published in April 2008 (VGB PowerTech Service GmbH)
7 Maintenance of the RDS-PP and application support

The Working Panel "Reference Designation and Plant Documentation" as a collaborator in
standardization and author of the VGB guidelines relating to RDS-PP is well aware that suitable
assistance will be needed to support the introduction of the RDS-PP.
Questions should be addressed directly to the VGB office (barbara.bochynski@vgb.org). The
persons interested in RDS-PP will be registered and supplied with information about current
developments. Current information will also be provided on the VGB website
(www.vgb.org/db_rds.html).
For specific technical questions, issue-specific teams will be formed within the Working Panel which
to a certain depth will address the issues raised free of cost. In addition, the teams will be pleased to
provide proposals for engineering services to be rendered against a fee or to facilitate contacts with
service providers.
The VGB training centre for power plant operating staff, which is likewise a member of the Working
Panel "Reference Designation and Plant Documentation", will provide training courses and seminars
on RDS-PP if need arises.
Literature
EU Directives
DIRECTIVE 2004/17/EC OF THE EUROPEAN PARLIAMENT AND OF THECOUNCIL
of 31 March 2004 coordinating the procurement procedures of entities operating in the water, energy,
transport and postal services sectors
DIRECTIVE 2004/18/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 31 March
2004 on the coordination of procedures for the award of public works contracts, public supply
contracts and public service contracts
DIRECTIVE 2006/42/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 17 May 2006 on machinery, and amending Directive 95/16/EC (recast)
DIRECTIVE 2001/95/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL
of 3 December2001 on general product safety
91/173
View • Attachments (1) • Info
Metadata Registries - ISO IEC 11179
Name and version: ISO/IEC 11179

Alternative name: Metadata registries (MDR)
Valid: From 2005 (edition 2)
Description: This is a standard for describing and managing the meaning and representation of
data. The basic semantic unit is a concept. The standard is written in 6 parts, and the 2nd edition is
the current version for each Their ISO number, name, and publication date are as follows::
Part 1 - ISO/IEC 11179-1 Framework 2004
Part 2 - ISO/IEC 11179-2 Classification 2005
Part 3 - ISO/IEC 11179-3 Metamodel and basic attributes 2003
Part 4 - ISO/IEC 11179-4 Formulation of data definitions 2004
Part 5 - ISO/IEC 11179-5 Naming and identification principles 2005
Part 6 - ISO/IEC 11179-6 Registration 2005
The framework of attributes for describing the meaning and representaiton is contained in Part 3. The
management of these descriptions is done through a registry. The procedure for which is in Part 6,
and the attributes are again in Part 3. ISO/IEC 11179 has an additional framework for attaching
meaning, and that is through the use of classification. The attributes for describing the associations
between a classification scheme and data descriptions are in Part2 and again in Part 3. Parts 4 and
5 give rules, guidelines, and principles for naiming, identification, and forming definitions. Finally, Part
1 is an overall description and justification of the other parts.
An edition 3 is planned. A publication date for all the parts is not yet set. Part 3 edtion 3 is expected
to be published near the end of 2010. Significant additions are expected.
Intended use: ISO/IEC 11179 is intended to be used to manage the meaning and representation of
data. It is not intended to be used solely to capture the structure of a database. It can be used alone
or within a larger system. Other standards make use of it as well.
Maintenance organization: ISO/IEC/JTC1/SC32
(International Organization for Standardization / International Electrotechnical Commission / Joint
Technical Committee 1 - Information technology / Sub-Committee 32 - Data managment and
interchange)
ISO Standard Number: ISO/IEC 11179
References: The ISO/IEC 11179 family of standards is freely and publically available at
http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html
92/173
7.8.2. ISO/IEC 11179 Information technology — Metadata registries (MDR) —
Part 1:
Framework
Contents Page
Foreword.
Introduction
1 Scope
2 Normative references 3 Terms and definitions
3.1 Definitions of modeling constructs
3.2 General terms used in this part of ISO/IEC 11179
3.3 Alphabetical list of terms used in the met model
3.4 Specific terms used in this part of ISO/IEC 11179
4 Abbreviations and acronyms
5 Theory of terminology
6 Metadata
6.1 Concepts
6.2 Fundamental model of data elements
6.3 Data elements in data management and interchange
6.4 Fundamental model of value domains
6.5 Fundamentals of classification schemes
7 Metadata registries
7.1 General
7.2 Overview model for an ISO/IEC 11179 MDR
7.3 Fundamentals of registration
8 Overview of ISO/IEC 11179
8.1 Introduction of parts
8.2 Basic principles for applying ISO/IEC 11179
9 Conformances
Bibliography
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electro technical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work. In the field of information technology, ISO and IEC have established a joint technical committee,
ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC
Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for
voting. Publication as an International Standard requires approval by at least 75 % of the national
bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document
may be the subject of patent rights. ISO and IEC shall not be held responsible for identifying any or all
such patent rights. ISO/IEC 11179-1 was prepared by Technical Committee ISO/IEC JTC 1,
Information technology, Subcommittee SC 32, Data management and interchange. This second
edition cancels and replaces the first edition (ISO/IEC 11179-1:1999), which has been technically
revised. SO/IEC 11179 consists of the following parts, under the general title Information technology
— Metadata registries (MDR):
 Part 1: Framework
 Part 2: Classification
 Part 3: Registry met model and basic attributes
 Part 4: Formulation of data definitions
 Part 5: Naming and identification principles
 Part 6: Registration
Introduction
93/173
ISO/IEC 11179 - Metadata registries (MDR), addresses the semantics of data, the representation of
data, and the registration of the descriptions of that data. It is through these descriptions that an
accurate understanding of the semantics and a useful depiction of the data are found. The purposes
of ISO/IEC 11179 are to promote the following:
 Standard description of data
 Common understanding of data across organizational elements and between organizations
 Re-use and standardization of data over time, space, and applications
 Harmonization and standardization of data within an organization and across organizations
 Management of the components of data
 Re-use of the components of data
ISO/IEC 11179 is six part standard. Each part is devoted to addressing a different aspect of the needs
listed above. The parts and a short description follow:
 Part 1 – Framework – Contains an overview of the standard and describes the basic concepts
 Part 2 – Classification – Describes how to manage a classification scheme in a metadata registry
 Part 3 – Registry met model and basic attributes – Provides the basic conceptual model, including
the basic attributes and relationships, for a metadata registry
 Part 4 – Formulation of data definitions – Rules and guidelines for forming quality definitions for
data elements and their components
 Part 5 – Naming and identification principles – Describes how to form conventions for naming data
elements and their components
 Part 6 – Registration – Specifies the roles and requirements for the registration process in an
ISO/IEC 11179 metadata registry
Generally, descriptive data is known as metadata. That is, metadata is data that is used for describing
other data. As the use of the term has evolved, metadata now refers, generally, to data that is used
for describing some other objects. We limit the scope of the term as it is used here in ISO/IEC 11179
to descriptions of data - the more traditional use of the term.
An MDR is a database of metadata that supports the functionality of registration.
Registration accomplishes
Three main goals: identification, provenance, and monitoring quality. Identification is accomplished by
assigning a unique identifier (within the registry) to each object registered there. Provenance
addresses the source of the metadata and the object described. Monitoring quality ensures that the
metadata does the job it is designed to do.
An MDR manages the semantics of data. Understanding data is fundamental to its design,
harmonization, standardization, use, re-use, and interchange. The underlying model for an MDR is
designed to capture all the basic components of the semantics of data, independent of any
application or subject matter area.
MDR's are organized so that those designing applications can ascertain whether a suitable object
described in the MDR already exists. Where it is established that a new object is essential, its
derivation from an existing description with appropriate modifications is encouraged, thus avoiding
unnecessary variations in the way similar objects are described. Registration will also allow two or
more administered items describing identical objects to be identified, and more importantly, it will
identify situations where similar or identical names are in use for administered items that are
significantly different in one or more respects.
In ISO/IEC 11179 the basic container for data is called a data element. It may exist purely as an
abstraction or exist in some application system. In either case, the description of a data element is the
same in ISO/IEC 11179. Data element descriptions have both semantic and representational
components. The semantics are further divided into contextual and symbolic types.
The contextual semantics are described by the data element concept (DEC). The DEC describes the
kinds of objects for which data are collected and the particular characteristic of those objects being
measured. The symbolic semantics are described by the conceptual domain (CD). A CD is a set of
categories, not necessarily finite, where the categories represent the meaning of the permissible
values in a value domain - the allowed values for a data element. The names, definitions, data type,
and related objects that are associated with a particular object in an MDR give that object meaning.
The depth of this meaning is limited, because names and definitions convey limited information about
an object. The relationships that object has with semantically related objects in a registry provides
additional information, but the additional information is dependent on how many semantically related
objects there are.
94/173
The representational component is about the permitted values a data element may use. Each value
corresponds to one of the categories in the CD. The set of these permitted values is called a value
domain (VD). A VD specifies all the values that are allowed either through an enumeration, a rule, or
a combination of these. The computational model the values follow is given by their data type. The
semantic and representational components are described through attributes contained in the
conceptual model of a metadata registry as specified in ISO/IEC 11179-3. A metadata registry that
conforms to ISO/IEC 11179 can describe a wide variety of data. In fact, the attributes described in
ISO/IEC 11179-3 are data elements, and they can be registered in an ISO/IEC 11179 metadata
registry. Moreover, any set of descriptors or metadata attributes may be interpreted as data elements
and registered in the metadata registry.
There are two main consequences to this:
 The metadata registry can describe itself
 Metadata layers or levels are not defined in ISO/IEC 11179
As a result, ISO/IEC 11179 is a general description framework for data of any kind, in any
organization, and for any purpose. This standard does not address other data management needs,
such as data models, application specifications, programming code, program plans, business plans,
and business policies. These need to be addressed elsewhere.
The increased use of data processing and electronic data interchange heavily relies on accurate,
reliable, controllable, and verifiable data recorded in databases. One of the prerequisites for a correct
and proper use and interpretation of data is that both users and owners of data have a common
understanding of the meaning and descriptive characteristics (e.g., representation) of that data. To
guarantee this shared view, a number of basic attributes has to be defined.
The basic attributes specified are applicable for the definition and specification of the contents of data
dictionaries and interchanging or referencing among various collections of administered items. The
"basic" in basic attributes means that the attributes are commonly needed in specifying administered
items completely enough to ensure that they will be applicable for a variety of functions, such as
 design of information processing systems
 retrieval of data from databases
 design of EDI-messages for data interchange
 maintenance of metadata registries
 data management
 dictionary design
 dictionary control
 use of information processing systems
Basic also implies that they are independent of any

 application environment
 function of an object described by an administered item
 level of abstraction
 grouping of administered items
 method for designing information processing systems or data interchange messages
 MDR system
Basic does not imply that all attributes specified in ISO/IEC 11179-3 are required in all cases.
Distinction is made between those attributes that are mandatory, conditional, or optional.
Information technology — Metadata registries (MDR) —

Framework
1 Scope
ISO/IEC 11179 specifies the kind and quality of metadata necessary to describe data, and it specifies
the management and administration of that metadata in a metadata registry (MDR). It applies to the
formulation of data representations, concepts, meanings, and relationships between them to be
shared among people and machines, independent of the organization that produces the data. It does
not apply to the physical representation of data as bits and bytes at the machine level. In ISO/IEC
11179, metadata refers to descriptions of data. ISO/IEC 11179 does not contain a general treatment
of metadata. This part of ISO/IEC 11179 provides the means for understanding and associating the
individual parts and is the foundation for a conceptual understanding of metadata and metadata
registries.
95/173
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 704:2000, Terminology work — Principles and methods
ISO 1087-1:2000, Terminology work — Vocabulary — Part 1: Theory and application
ISO/IEC 11179 (all parts), Information technology — Metadata registries (MDR)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1 Definitions of modeling constructs
This sub-clause defines the modeling constructs used in this part of ISO/IEC 11179.
3.1.1
attribute
characteristic of an object or entity
3.1.2
class
description of a set of objects that share the same attributes, operations, methods, relationships,
and semantics [ISO/IEC 19501-1:2001, 2.5.2.9].
3.1.3
identifier (in Metadata Registry)
sequence of characters, capable of uniquely identifying that with which it is associated, within a
specified context
NOTE A name should be used as an identifier because it is not linguistically neutral.
3.1.4
relationship
connection among model elements [ISO/IEC 19501-1:2001, 2.5.2.36].
3.2 General terms used in this part of ISO/IEC 11179
This sub-clause defines terms that have general usage beyond the specific needs of this part of
ISO/IEC 11179, but are not modeling constructs defined in 3.1.
3.2.1
basic attribute
attribute of a metadata item commonly needed in its specification
3.2.2
characteristic
abstraction of a property of an object or of a set of objects
NOTE Characteristics are used for describing concepts. [ISO 1087-1:2000, 3.2.4].
3.2.3
concept
unit of knowledge created by a unique combination of characteristics
[ISO 1087-1:2000, 3.2.1].
3.2.4
concept system
set of concepts structured according to the relations among them
[ISO 1087-1:2000, 3.2.11]
3.2.5
conceptual data model
conceptual model
data model that represents an abstract view of the real world
NOTE A conceptual model represents the human understanding of a system.
3.2.6
data
re-interpretable representation of information in a formalized manner suitable for communication,
interpretation, or processing
NOTE Data can be processed by humans or by automatic means.
[ISO 2382-1:1993, 01.01.02].
3.2.7
data model
graphical and/or lexical representation of data, specifying their properties, structure and inter-
relationships
3.2.8
96/173
definition
representation of a concept by a descriptive statement which serves to differentiate it from related
concepts [ISO 1087-1:2000, 3.3.1].
3.2.9
designation
representation of a concept by a sign which denotes it
[ISO 1087-1:2000, 3.4.1].
3.2.10
entity
any concrete or abstract thing that exists, did exist, or might exist, including associations among
these things
EXAMPLE A person, object, event, idea, process, etc.
NOTE An entity exists whether data about it are available or not.
[ISO/IEC 2382-17:1999, 17.02.05].
3.2.11
essential characteristic
characteristic which is indispensable to understanding a concept
[ISO 1087-1:2000, 3.2.6].
3.2.12
extension
<terminology>
totality of objects to which a concept corresponds
[ISO 1087-1:2000, 3.2.8].
NOTE This term has a different meaning in ISO/IEC 11179-3.
3.2.13
general concept
concept which corresponds to two or more objects, which form a group by reason of common
properties
NOTE Examples of general concepts are 'planet', 'tower'.
[ISO 1087-1:2000, 3.2.3]
3.2.14
individual concept
concept which corresponds to only one object
NOTE Examples of individual concepts are: 'Saturn', 'the Eiffel Tower'.
[ISO 1087-1:2000, 3.2.2].
3.2.15
intension
<terminology>
set of characteristics which makes up the concept
[ISO 1087-1:2000, 3.2.9].
3.2.16
metadata
data that defines and describes other data
3.2.17
metadata item
instance of a metadata object
3.2.18
metadata object
object type defined by a met model
3.2.19
metadata registry
MDR
information system for registering metadata
3.2.20
Met model
data model that specifies one or more other data models
3.2.21
name
designation of an object by a linguistic expression
3.2.22
97/173
object
anything perceivable or conceivable
NOTE Objects may also be material (e.g. an engine, a sheet of paper, a diamond), immaterial (e.g. a
conversion ratio,
a project plan), or imagined (e.g. a unicorn).
[ISO 1087-1:2000, 3.1.1].
3.2.23
registry item
metadata item recorded in a metadata registry
3.2.24
registry met model
met model specifying a metadata registry
3.2.25
terminological system
concept system with designations for each concept
3.3 Alphabetical list of terms used in the met model
This sub-clause provides definitions for terms used in this part of ISO/IEC 11179, which are the
names of metadata objects in the met model specified in ISO/IEC 11179-3.
3.3.1
administered item
registry item for which administrative information is recorded in an administration record
3.3.2
administration record
collection of administrative information for an administered item
3.3.3
administrative status
designation of the status in the administrative process of a registration authority for handling
registration requests
NOTE The values and associated meanings of “administrative status” are determined by each
registration authority.
C.f. “registration status”.
3.3.4
classification scheme
descriptive information for an arrangement or division of objects into groups based on
characteristics, which
the objects have in common
3.3.5
classification scheme item
CSI
item of content in a classification scheme.
NOTE This may be a node in a taxonomy or ontology, a term in a thesaurus, etc.
3.3.6
conceptual domain
CD
set of valid value meanings
NOTE The value meanings in a conceptual domain may either be enumerated or expressed via a
description.
3.3.7
context
circumstance, purpose, and perspective under which an object is defined or used
NOTE This term has a different meaning in 11179-3.
3.3.8
data element
DE
unit of data for which the definition, identification, representation and permissible values are
specified by means of a set of attributes
3.3.9
data element concept
DEC
98/173
concept that can be represented in the form of a data element, described independently of any
particular representation
3.3.10
data identifier
DI unique identifier for an administered item within a registration authority
3.3.11
data type
set of distinct values, characterized by properties of those values and by operations on those values
[ISO/IEC 11404:1996, 4.11].
3.3.12
dimensionality
expression of measurement without units
NOTE A quantity is a value with an associated unit of measure. 32º Fahrenheit, 0º Celsius, $100
USD, and 10 reams (of paper) are quantities. Equivalence between two units of measure is
determined by the existence of a quantity preserving one-to-one correspondence between values
measured in one unit of measure and values measured in the other unit of measure, independent of
context, and where characterizing operations are the same. Equivalent units of measure in this sense
have the same dimensionality. The equivalence defined here forms an equivalence relation on the set
of all units of measure. Each equivalence class corresponds to a dimensionality. The units of measure
"temperature in degrees Fahrenheit" and "temperature in degrees Celsius" have the same
dimensionality, because for each value measured in degrees Fahrenheit there is a value measured in
degrees Celsius with the same quantity, and vice-versa. The same operations may be performed on
quantities in each unit of measure. Quantity preserving one-to-one
correspondences are the well-known equations Cº = (5/9)*(Fº - 32) and Fº = (9/5)*(Cº) +32.
3.3.13
enumerated conceptual domain
conceptual domain that is specified by a list of all its value meanings
3.3.14
enumerated value domain
value domain that is specified by a list of all its permissible values
3.3.15
international code designator
ICD
identifier of an organization identification scheme
NOTE Based on ISO/IEC 6523-1:1998, 3.8.
3.3.16
item identifier
identifier for an item
3.3.17
item registration authority identifier
identifier of the registration authority registering the item
3.3.18
non-enumerated conceptual domain
conceptual domain that is not specified by a list of all valid value meanings
3.3.19
non-enumerated conceptual domain description
description or specification of a rule, reference, or range for a set of all value meanings for the
conceptual domain
3.3.20
non-enumerated value domain
value domain that is specified by a description rather than a list of all permissible values
3.3.21
non-enumerated value domain description
description or specification of a rule, reference, or range for a set of all permissible values for the
value domain
3.3.22
object class
set of ideas, abstractions, or things in the real world that are identified with explicit boundaries and
meaning and whose properties and behavior follow the same rules
3.3.23
99/173
organization
unique framework of authority within which a person or persons act, or are designated to act, towards
some purpose [ISO/IEC 6523-1:1998, 3.1].
3.3.24
organization identifier
Identifier assigned to an organization within an organization identification scheme, and unique
within the scheme [ISO/IEC 6523-1:1998, 3.10].
3.3.25
Organization part
Any department, service, or other entity within an organization which needs to be identified for
information exchange [ISO/IEC 6523-1:1998, 3.2].
3.3.26
Organization part identifier
OPI
Identifier allocated to a particular organization part [ISO/IEC 6523-1:1998, 3.11].
3.3.27
Organization part identifier source
Source for the organization part identifier NOTE Based on ISO/IEC 6523-1:1998, 3.12.
3.3.28
Permissible value
Expression of a value meaning allowed in a specific value domain
3.3.29
Property
Characteristic common to all members of an object class
3.3.30
Registrar
Representative of a registration authority
3.3.31
Registration
Relationship between an administered item and the registration authority
3.3.32
Registration authority
RA
Organization responsible for maintaining a register
3.3.33
Registration authority identifier
Identifier assigned to a registration authority
3.3.34
Registration status
Designation of the status in the registration life-cycle of an administered item
3.3.35
Representation class
Classification of types of representations
3.3.36
Unit of measure
Actual units in which the associated values are measured
NOTE the dimensionality of the associated conceptual domain must be appropriate for the
specified unit of measure.
3.3.37
Value
Data value
3.3.38
Value domain
VD
Set of permissible values
3.3.39
Value meaning
Meaning or semantic content of a value
NOTE Given a permissible value, representation of its value meaning shall be independent of (and
shall not constrain) the representation of its corresponding value.
100/173
3.3.42
Value meaning description
Description of a value meaning
3.3.43
Version
Unique version identifier of the administered item
3.4 Specific terms used in this part of ISO/IEC 11179
This sub-clause defines terms that have specific usage in this part of ISO/IEC 11179 and are not used
in the other parts.
3.4.1
data construct
object a metadata item describes
NOTE Individual data elements, value domains, data element concepts, conceptual domains, object
classes, and
Properties are data constructs.
3.4.2
Quantity
Value associated with a unit of measure
4 Abbreviations and acronyms

NOTE some of the abbreviations or acronyms in this section represent terms defined in Clause 3.
CD -- Conceptual Domain
DE -- Data Element
DEC -- Data Element Concept
DI -- Data Identifier
EDI -- Electronic Data Interchange
IEC -- International Electro technical Commission
ICD -- International Code Designator
ISO -- International Organization for Standardization
JTC1 -- Joint Technical Committee 1
MDR -- Metadata Registry
OPI -- Organization Part Identifier
RA -- Registration Authority
SC32 -- ISO/IEC JTC1/Sub-committee 32
5 Theory of terminology
The concepts from the theory of terminology that are used in ISO/IEC 11179 shall be in conformity
with ISO 704 and ISO 1087-1. A short description of the necessary theory follows.
In the theory of terminology, an object is something conceivable or perceivable. Concepts are mental
constructs, units of thought, or unit of knowledge created by a unique combination of characteristics.
Concepts are organized or grouped by common elements, called characteristics. Essential
characteristics are indispensable to understanding a concept. Other characteristics are inessential.
The sum of characteristics that constitute a concept is called its intension. The set of objects a
concept refers to is its extension.
In natural language, concepts are expressed through definitions, which specify a unique intension
and extension.
A designation (term, appellation, or symbol) represents a concept.
A general concept has two or more objects that correspond to it. An individual concept has one
object that corresponds to it. That is, a general concept has two or more objects in its extension, and
an individual concept has one object in its extension.
A concept system is set of concepts structured according to the relations among them. A
terminological system is a concept system with designations for each concept.
6 Metadata
6.1 Concepts
For ISO/IEC 11179, metadata is defined to be data that defines and describes other data. This
means that metadata are data, and data become metadata when they are used in this way. This
happens under particular circumstances, for particular purposes, and with certain perspectives, as no
data are always metadata. The set of circumstances, purposes, or perspectives for which some data
are used as metadata is called the context. So, metadata are data about data in some context.
101/173
Since metadata are data, then metadata can be stored in a database and organized through the use
of a model. Some models are very application specific, and others are more general. The model
presented and described in ISO/IEC 11179-3 (Registry met model and basic attributes) is general. It
is a representation of the human understanding of the metadata needed to describe data constructs,
including the relationships that exist among that metadata, and not necessarily how the metadata will
be represented in an application of an MDR. A model of this kind is called a conceptual model.
Conceptual models are meant for people to read and understand.
Models that describe metadata are often referred to as met models. The conceptual model
presented in ISO/IEC 11179-3 is a met model in this sense.
6.2 Fundamental model of data elements
Figure 1 illustrates the ideas conveyed in this sub-clause. The figure itself is not normative, but it is
used to illustrate the basic ideas.
For the purposes of ISO/IEC 11179, a data element is composed of two parts:
 Data element concept – A DEC is concept that can be represented in the form of a data element,
described independently of any particular representation.
 Representation – The representation is composed of a value domain, data type, units of measure
(if necessary), and representation class (optionally).
From a data modeling perspective and for the purposes of ISO/IEC 11179, a data element concept
may be composed of two parts:
 The object class is a set of ideas, abstractions, or things in the real world that can be identified
with explicit boundaries and meaning and whose properties and behavior follow the same rules
 The property is a characteristic common to all members of an object class
Object classes are the things for which we wish to collect and store data. They are concepts, and they
correspond to the notions embodied in classes in object-oriented models and entities in entity-
relationship models. Examples are cars, persons, households, employees, and orders. Properties are
what humans use to distinguish or describe objects.
They are characteristics, not necessarily essential ones, of the object class and form its intension.
They are also concepts, and they correspond to the notions embodied in attributes (without
associated data types) in object-oriented or entity-relationship models. Examples of properties are
color, model, sex, age, income, address, or price.
An object class may be a general concept. This happens when the set of objects corresponding to
the object class has two or more members. The examples in the previous paragraph are of this type.
Record level data are described this way. On the other hand, an object class may be an individual
concept. This happens when the set of objects corresponding to the object class has one member.
Examples are concepts corresponding to single objects, such as "the set of persons in the US" or "the
set of service sector
establishments in Australia". Aggregate data are described this way. Examples of properties are
average income or total earnings.
It is important to distinguish an actual object class or property from its name. This is the distinction
between concepts and their designations. Object classes and properties are concepts; their names
are designations. Complications arise because people convey concepts through words
(designations), and it is easy to confuse a concept with the designation used to represent it. For
example, most people will read the word income and
be certain they have unambiguously interpreted it. But, the designation income may not convey the
same concept to all readers, and, more importantly, each instance of income may not designate the
same concept.
Not all ideas are simply expressed in a natural language, either. For example, "women between the
ages of 15 and 45 who have had at least one live birth in the last 12 months" is a valid object class
not easily named in English. Some ideas may be more easily expressed in one language than in
another. The German word Götterdämmerung has no simple English equivalent. A data element is
produced when a representation is associated with a data element concept. The representation
describes the form of the data, including a value domain, data type, representation class (optionally),
and, if necessary, a unit of measure. Value domains are sets of permissible values for data
elements. For example, the data element representing annual household income may have the set of
nonnegative
integers (with units of dollars) as a set of valid values. This is its value domain.
102/173
A data element concept may be associated with different value domains as needed to form
conceptually similar data elements. There are many ways to represent similar facts about the world,
but the concept for which the facts are examples is the same. Take the DEC country of person's birth
as an example.
ISO 3166-1 – Country Codes contains seven different representations for countries of the world. Each
one of these seven representations contains a set of values that may be used in the value domain
associated with the DEC. Each one of the seven associations is a data element. For each
representation of the data, the permissible values, the data type, the representation class, and
possibly the units of measure, are altered.
See ISO/IEC 20943-1:2003, Information technology — Procedures for achieving metadata registry
content consistency — Part 1: Data elements for details about the registration and management of
descriptions of data elements.
This figure is for informational purposes only. It is not normative.

Figure 1 — Fundamental model for data elements
6.3 Data elements in data management and interchange

Figure 2 provides a simplified picture to illustrate those situations in which data elements lie. Data
elements appear in databases, files, and transaction sets. Data elements are the fundamental units of
data an organization manages, therefore they must be part of the design of databases and files within
the organization and all transaction sets the organization builds to communicate data to other
organizations.
Within the organization, databases or files are composed of records, segments, topples, etc., which
are composed of data elements. The data elements themselves contain various kinds of data that
include characters, images, sound, etc. When the organization needs to transfer data to another
organization, data elements are the fundamental
Units that make up the transaction sets. Transactions occur primarily between databases or files, but
the structure (i.e. the records or tuples) of the files and databases don't have to be the same across
organizations. So, the common unit for transferring information (data plus understanding) is the data
element.
103/173
This figure is for informational purposes only. It is not normative.
Figure 2 — Data elements and other data concepts
6.4 Fundamental model of value domains

Figure 3 illustrates the ideas conveyed in this sub-clause. The figure itself is not normative, but it is
used to illustrate the basic ideas.
A value domain is a set of permissible values. A permissible value is a combination of some value
and the meaning for that value. The associated meaning is called the value meaning. A value
domain is the set of valid values for one or more data elements. It is used for validation of data in
information systems and in data exchange. It is also an integral part of the metadata needed to
describe a data element. In particular, a value
domain is a guide to the content, form, and structure of the data represented by a data element. Value
domains come in two (non-exclusive) sub-types:
 Enumerated value domain – A value domain specified as a list of permissible values (values and
their meanings)
 Non-enumerated value domain – A value domain specified by a description
An enumerated value domain contains a list of all its values and their associated meanings. Each
value and meaning pair is called a permissible value. The meaning for each value is called the
value meaning.
A non-enumerated value domain is specified by a description. The non-enumerated value domain
description describes precisely which permissible values belong and which do not belong to the
value domain. An example of a description is the phrase "Every real number greater than 0 and less
than 1".
Each value domain is a member of the extension of a concept, called the conceptual domain. A
conceptual domain is a set of value meanings. The intension of a conceptual domain is its value
meanings. Many value domains may be in the extension of the same conceptual domain, but a value
104/173
domain is associated with one conceptual domain. Conceptual domains may have relationships with
other conceptual domains, so it is
possible to create a concept system of conceptual domains. Value domains may have relationships
with other value domains, which provide the framework to capture the structure of sets of related
value domains and their associated concepts.
Conceptual domains, too, come in two (non-exclusive) sub-types:
 Enumerated conceptual domain – A conceptual domain specified as a list of value meanings
 Non-enumerated conceptual domain – A conceptual domain specified by a description
The value meanings for an enumerated conceptual domain are listed explicitly. This conceptual
domain type corresponds to the enumerated type for value domains. The value meanings for a non-
enumerated conceptual domain are expressed using a rule, called a non-enumerated conceptual
domain description.
Thus, the value meanings are listed implicitly. This rule describes the meaning of permissible values
in a none numerated value domain. This conceptual domain type corresponds to the non-enumerated
type for value domains. See ISO/IEC TR 20943-3, Information technology — Procedures for
achieving metadata registry content consistency — Part 3: Value domains for detailed examples.
A unit of measure is sometimes required to describe data. If temperature readings are recorded in a
database, then the temperature scale (e.g., Fahrenheit or Celsius) is necessary to understand the
meaning of the values. Another example is the mass of rocks found on Mars, measured in grams.
However, units of measure are not limited to physical quantities, as currencies (e.g., US dollars, Lire,
British pounds) and other socio-economic
measures are units of measure, too. Some units of measure are equivalent to each other in the
following sense: Any quantity in one unit of measure can be transformed to the same quantity in
another unit of measure. All equivalent units of measure are said to have the same dimensionality.
For example, currencies all have the same dimensionality.
Measures of speed, such as miles per hour or meters per second, have the same dimensionality. Two
units of measure that are often erroneously seen as having the same dimensionality are pounds (as
in weight) and grams. Pounds are a measure of force, and grams are a measure of mass.
A unit of measure is associated with a value domain, and the dimensionality is associated with the
conceptual domain.
Some value domains contain very similar values from one domain to another. Either the values
themselves are similar or the meanings of the values are the same. When these similarities occur, the
value domains may be in the extension of one conceptual domain. The following examples illustrate
this and the other ideas in this sub-clause:
105/173
Every value domain represents two kinds of concepts: data element concept (indirectly) and
conceptual domain (directly). The Data Element Concept is the concept associated with a data
element. The value domain is the representation for the data element, and, therefore, indirectly
represents the data element concept, too. However, the value domain is directly associated with a
conceptual domain, so represents that concept, independent of any data element.
See ISO/IEC TR 20943-3, Information technology — Procedures for achieving metadata registry
content consistency — Part 3: Value domains for detailed examples about the registration and
management of value domains.
106/173
6.5 Fundamentals of classification schemes
For the purposes of ISO/IEC 11179, a classification scheme is a concept system intended to
classify objects. It is organized in some specified structure, limited in content by a scope, and
designed for assigning objects to concepts defined within it. Concepts are assigned to an object, and
this process is called classification. The relationships linking concepts in the concept system link
objects that the related concepts classify. In general,
any concept system is a classification scheme if it is used for classifying objects.
The content scope of the classification scheme circumscribes the subject matter area covered by the
classification scheme. The scope of the classification scheme is the broadest concept contained in
the concept system of the scheme. It determines, theoretically, whether an object can be classified
within that scheme or not.
Concept systems, and classification schemes in particular, can be structured in many ways. The
structure defines the types of relationships that may exist between concepts, and each classification
scheme can be used for the purpose of linking concepts to objects. In a particular classification
scheme, the linked concepts together with the other concepts related to the linked concept in the
scheme provide a conceptual framework in which to understand the meaning of the object. The
framework is limited by the scope of the classification scheme.
A concept system may be represented by a terminological system. The designations are used to
represent each of the concepts in the system and are used as key words linked to objects for
searching, indexing, or other purposes. A special kind of concept system is a relationship system.
There, the concepts are relationship types. A relationship type has N arguments, and it is called an n-
ary relationship type. The statement "a set of N objects is classified by an n-ary relationship type"
means that the N objects have a relationship among them of the given relationship type.
7 Metadata registries
7.1 General
Metadata is also data, so metadata may be stored in a database. A database of metadata that
supports the functionality of registration is a metadata registry (MDR). A conceptual model of an
MDR for describing data is provided in ISO/IEC 11179-3. The requirements and procedures for the
ISO/IEC 11179 aspects of registration are described in ISO/IEC 11179-6. For actual metadata
registries, there may be additional requirements and procedures for registration, which are outside
107/173
the scope of ISO/IEC 11179. Rules and guidelines for providing good definitions and developing
naming conventions are described in ISO/IEC 11179- 4 and ISO/IEC 11179-5, respectively. The role
of classification is described in ISO/IEC 11179-2.
Recommendations and practices for registering data elements are described in ISO/IEC TR 20943-1.
Recommendations and practices for registering value domains are described in ISO/IEC TR 20943-3.
An MDR contains metadata describing data constructs. The attributes for describing a particular data
construct (e.g., data elements) are known, collectively, as a metadata object. When the attributes are
instantiated with the description of a particular data construct, they are known as a metadata item.
Registering the metadata item (i.e., entering the metadata into the MDR) makes it a registry item. If
the registry item is also subject to administration (as in the case of a data element), it is called an
administered item.
NOTE In common parlance, registering a metadata item describing a data construct is known as
registering that data construct. Actually, the data construct is not stored in the MDR, its description is.
This is analogous to the registries maintained by governments to keep track of motor vehicles. A
description of each motor vehicle is entered in the registry,
but not the vehicle itself. However, people say they have registered their motor vehicles, not the
descriptions.
7.2 Overview model for an ISO/IEC 11179 MDR

The conceptual model for an ISO/IEC 11179 MDR contains two main parts: the conceptual level and
the representational (or syntactical) level. The conceptual level contains the classes for the data
element concept and conceptual domain. Both classes represent concepts. The representational level
contains the classes for data element and value domain. Both classes represent containers for data
values. Clause 6 contains descriptions of each of the classes represented in Figure 4.
 A data element is an association of a data element concept and a representation (primarily a value
domain)
 Many data elements may share the same data element concept, which means a DEC may be
represented in many different ways
 Data elements may share the same representation, which means that a value domain can be
reused in other data elements
 Value domains do not have to be related to a data element and may be managed independently
 Value domains that share all the value meanings of their permissible values are conceptually
equivalent, so share the same conceptual domain
 Value domains that share some of the value meanings of their permissible values are conceptually
related, so share the same conceptual domain in the concept system of conceptual domains that
contain their respective conceptual domains
 Many value domains can share the same conceptual domain
108/173
 A data element concept is related to a single conceptual domain, so all the data elements sharing
the same data element concept share conceptually related representations
Many other facts are not illustrated in Figure 4, but some of these are described in Clause 6. Two
facts not described in Figure 4 are worth stating:
 Relationships among data element concepts may be maintained in an MDR, which implies that a
concept system of data element concepts may be maintained
 Relationships among conceptual domains may be maintained in an MDR, which implies that a
concept system of conceptual domains may be maintained
Some fundamental issues of registration and administration of metadata in an MDR are described
later in this clause.
7.3 Fundamentals of registration

The registration and administration functions specified in ISO/IEC 11179-6 are what separate an MDR
from a database of metadata. The means to accomplish these functions are a large part of the design
of the met model specified in ISO/IEC 11179-3. Registration is the set of rules, operations, and
procedures that apply to an MDR. A detailed description of registration as it applies in ISO/IEC 11179
is found in ISO/IEC 11179-6. The three most important outcomes of registration are the ability to
monitor the quality of metadata, provenance (the source of the metadata), and the assignment of an
identifier to each object described in an MDR. Registration also requires a set of procedures for
managing a registry, submitting metadata for registration of objects, and maintaining subject
matter responsibility for metadata already submitted. For actual implementations of a metadata
registry, there may be additional requirements, which are outside the scope of ISO/IEC 11179. Each
administered item is maintained in a uniform and prescribed manner. Identifiers, quality measures,
responsible organizations, names, and definitions are all part of the general metadata that falls under
administration. Registration is the process of creating or maintaining administrative and other detailed
metadata.
Metadata quality is monitored through the use of a registration status. The status records the level
of quality. Each level is specified in ISO/IEC 11179-6. Every administered item is assigned a
registration status, and this status may change over time. In addition, metadata quality is multi-
faceted. That is, there are several purposes to monitoring metadata quality. The main purposes are
 Monitoring adherence to rules for providing metadata for each attribute
 Monitoring adherence to conventions for forming definitions, creating names, and performing
classifications
 Determining whether an administered item still has relevance
 Determining the similarity of related administered items and harmonizing their differences
 Determining whether it is possible to ever get higher quality metadata for some administered items
The rules for creating and assigning identifiers are described in ISO/IEC 11179-6. Each administered
item within an MDR is assigned a unique identifier.
The registration authority is the organization responsible for setting the procedures, administering,
and maintaining an MDR. The submitting organization is responsible for requesting that a new
metadata item be registered in the registry. The steward is responsible for the subject matter content
of each registered item. Each of these roles is described in ISO/IEC 11179-6.
8 Overview of ISO/IEC 11179
8.1 Introduction of parts

This sub-clause introduces each part of the multi-part standard ISO/IEC 11179. It summarizes the
main points and discusses the importance of each.
8.1.1 Part 1
ISO/IEC 11179-1, Framework, introduces and discusses fundamental ideas of data elements, value
domains, data element concepts, conceptual domains, and classification schemes essential to the
understanding of this set of standards and provides the context for associating the individual parts of
ISO/IEC 11179.
8.1.2 Part 2
ISO/IEC 11179-2, Classification, provides a conceptual model for managing concept systems used as
classification schemes. Concepts from these schemes are associated with administered items
through the process of classification. Librarians, terminologists, linguists, and computer scientists are
perfecting the classification process, so it is not described here. The additional semantic content
109/173
derived from classification, is the important point. Associating an object with one or more concepts
from one or more classification schemes provides
 Additional understanding of the object
 Comparative information across similar objects
 Understanding of an object within the context of a subject matter field (defined by the scope of a
classification scheme)
 Ability to determine slight differences of meaning between similar objects
Therefore, managing classification schemes is an important part of maximizing the information
potential within an MDR. ISO/IEC 11179-2 provides the framework for this.
8.1.3 Part 3
ISO/IEC 11179-3, Registry met model and basic attributes, specifies a conceptual model for an MDR.
It is limited to a set of basic attributes for data elements, data element concepts, value domains,
conceptual domains, classification schemes, and other related classes. The basic attributes specified
for data elements in ISO/IEC 11179-3:1994 are included in this revision.
The registry met model is expressed in the Unified Modeling Language. It is divided into six regions
for readability. All the provisions represented in the model are described in the text. Several provisions
represented in comment boxes in the diagrams are described in the text. The document contains a
dictionary of all the modeling constructs (classes, attributes, and relationships) used in the model.
These collections of attributes are known as the "basic attributes". All the attributes described in Parts
2, 4, 5, and 6 are contained in the registry met model.
The registry met model is not a complete description of all the metadata an organization may wish to
record. So, the model is designed to be extended if required. However, extensions are, by their
nature, not part of the standard.
A clause describing conformance criteria is provided. Conformance is described as either strictly
conforming (all provisions met) or conforming (all provisions met, but additional provisions may exist).
8.1.4 Part 4
ISO/IEC 11179-4, Formulation of data definitions, provides guidance on how to develop unambiguous
data definitions. A number of rules and guidelines are presented in ISO/IEC 11179-4 that specifies
exactly how a data definition should be formed. A precise, well-formed definition is one of the most
critical requirements for shared understanding of data; well-formed definitions are imperative for the
exchange of information. Only if every user has a common and exact understanding of the data can it
be exchanged trouble-free. The usefulness of definitions is one aspect of metadata quality. Following
the rules and guidelines provided in Part 4 helps establish this usefulness.
8.1.5 Part 5
ISO/IEC 11179-5, Naming and identification principles, provides guidance for the designation of
administered items. Designation is a broad term for naming or identifying a particular data construct.
Names are applied to data constructs through the use of a naming convention. Naming conventions
are algorithms for generating names within a particular context. There are semantic, syntactic, and
lexical rules used to form a naming convention. Names are a simple means to provide some
semantics about data constructs, however the semantics are not complete. Syntactic and lexical rules
address the constituents (e.g., allowable characters), format, and other considerations.
Data constructs may be assigned multiple names, and one may be identified as preferred. Usually,
each assigned name is used within the context for which it was created. Identifiers are designations
meant for dereferencing data constructs for metadata management and exchange. An RA assigns a
unique identifier for each data construct, unique within the context of the registry. Thus, identifiers are
assigned to data constructs for use in unambiguously locating data constructs.
8.1.6 Part 6
ISO/IEC 11179-6, Registration, provides instruction on how a registration applicant may register a
data construct with an RA and the assignment of unique identifiers for each data construct.
Maintenance of administered items already registered is also specified in this document. Registration
mainly addresses identification, quality, and provenance of metadata in an MDR.
An administered item identifier is formed by the combination of the RA Identifier, the unique identifier
assigned to the administered item within an RA, and the version. Each registry is maintained by an
RA, to which data constructs logically and functionally belong. For example, data constructs related to
chemical matter would likely be registered under a Chemical Manufacturer Registration Authority
110/173
Registration is more complex than a simple indication whether a metadata item is either registered or
not. Although it is tempting to insist that only "good" metadata may be registered, that is not practical.
Therefore, improvement in the quality of administered items is divided into levels called registration
status. In addition, there are status levels for administration between each of these quality levels.
Collectively, these status levels are called administrative status. They indicate the point in the
registration life cycle currently attained for an administered item.
The provenance of metadata and the chain of responsibility are managed in an MDR, too. The tasks
and roles of the registration authority, data steward, responsible organization, and submitting
organization are described. A framework for the registration process to be used in an MDR is
provided. Registration is both a process and a goal. The assignment of an identifier, quality status,
life-cycle status, and describing provenance are goals. The rules by which these goals are
accomplished are the process.
8.2 Basic principles for applying ISO/IEC 11179

Each part of ISO/IEC 11179 assists in a different aspect of metadata creation, organization, and
registration; and each part shall be used in conjunction with the other parts. ISO/IEC 11179-1
establishes the relationships among the parts and gives guidance on their usage as a whole. ISO/IEC
11179-3 specifies metadata items a registration applicant shall provide for each object to be
registered. Detailed characteristics of each basic attribute are given. Because of their importance in
the administration of metadata describing data constructs, three of the attributes (name, definition,
and identification) are given special and extensive treatment in two documents. ISO/IEC 11179-4 shall
be followed when constructing data definitions. Identification and naming shall follow principles set
forth in ISO/IEC 11179-5. ISO/IEC 11179-2 specifies a set of attributes for use in the registration and
administration of classification schemes and their components. Metadata items are registered as
registry items and administered as administered items in an MDR. ISO/IEC 11179-6 provides
guidance on these procedures.
I
9 Conformance
There are no specific conformance criteria for this part of ISO/IEC 11179. It is a framework that ties
the other parts of ISO/IEC 11179 together. As such, conformance is not an issue for this part. Each of
the other parts of ISO/IEC 11179 has its own conformance clause.
Bibliography
[1] Barr, Avron & Feigenbaum, Edward A., The Handbook of Artificial Intelligence (3 Volumes), William
Kaufman, Inc., 1981
[2] Gosh, Sakti, P., Data Base Organization for Data Management, Second Edition, New York:
Academic Press, Inc., 1986
[3] Herman, G.T., "Theory of Algorithms", in Encyclopedia of Computer Science and Engineering, by
Ralston, Anthony & Reilly, Jr., Edwin D., Second Edition, Van Nostrand Reinhold Company Inc., 1983.
[4] ISO/IEC Guide 2, Standardization and related activities — General vocabulary
[5] ISO 639 (all parts), Codes for the representation of names of languages
[6] ISO/IEC 646, Information technology — ISO 7-bit coded character set for information interchange
[7] ISO/IEC 2375, Information technology — Procedure for registration of escape sequences and
coded character sets
[8] ISO/IEC 2382 (all parts), Information technology — Vocabulary
[9] ISO 2788, Documentation — Guidelines for the establishment and development of monolingual
thesauri
[10] ISO 3166:1988, Codes for the representation of names of countries
[11] ISO/IEC 4873, Information technology — ISO 8-bit code for information interchange — Structure
and rules for implementation
[12] ISO 5964, Documentation — Guidelines for the establishment and development of multilingual
thesauri
[13] ISO 6093, Information processing — Representation of numerical values in character strings for
information interchange
[14] ISO 6862, Information and documentation — Mathematical coded character set for bibliographic
information interchange
[15] ISO/IEC 6937, Information technology — Coded graphic character set for text communication —
Latin alphabet
[16] ISO/IEC 7498-1, Information technology — Open Systems Interconnection — Basic Reference
Model: The Basic Model
111/173
[17] ISO 8601, Data elements and interchange formats — Information interchange — Representation
of dates and times
[18] ISO/IEC 8824 (all parts), Information technology — Abstract Syntax Notation One (ASN.1)
[19] ISO/IEC 8859 (all parts), Information technology — 8-bit single-byte coded graphic character
sets
[20] ISO/TR 9007, Information processing systems — Concepts and terminology for the conceptual
schema and the information base
[21] ISO/IEC TR 9789, Information technology — Guidelines for the organization and representation
of data elements for data interchange — Coding methods and principles
[22] ISO/IEC 10027, Information technology — Information Resource Dictionary System (IRDS)
framework
[23] ISO/IEC TR 10032, Information technology — Reference Model of Data Management
[24] ISO/IEC 10241:1992, International terminology standards — Preparation and layout
[25] ISO/IEC 10646, Information technology — Universal Multiple-Octet Coded Character Set (UCS)
[26] ISO/IEC 11404:1996, Information technology — Programming languages, their environments
and system software interfaces — Language-independent data types
[27] ISO/IEC TR 20943 (all parts), Information technology — Procedures for achieving metadata
registry content consistency
[28] Manual for Data Administration, edited by Judith J. Newton and Daniel C. Wahl, National Institute
of Standards and Technology, 1993
[29] Tasker, Dan, Fourth Generation Data, Prentice Hall
From Wiki.GIS.com
Metadata
To ensure correct and proper use and interpretation of data, all users and owners of data should have
a common understanding of the meaning or semantics of the data. To achieve this common
understanding, a number of characteristics, or attributes of the data have to be defined, also known
as metadata (ISO/IEC, 2003).
Metadata is often defined as data about data (e.g., NISO, 2004; Duval 2001, Cabinet Office, 2006). It
is “structured information that describes, explains, locates, or otherwise makes it easier to retrieve,
use or manage an information resource” (NISO, 2004, p.1), especially in a distributed network
environment like for example the internet or an organization (de Carvalho Moura et al., 1998). A good
example of metadata is the cataloging system found in libraries, which records for example the
author, title, subject, and location on the shelf of a resource.
Metadata is usually categorized in three types (Lambe, 2007; NISO, 2004; NISO, 2007):
 Descriptive metadata describes an information resource for identification and retrieval

through elements such as title, author, and abstract.
 Structural metadata documents relationships within and among objects through elements
such as links to other components (e.g., how pages are put together to form chapters).
 Administrative metadata helps to manage information resources through elements such as
version number, archiving date, and other technical information for purposes of file management,
rights management and preservation.
Available metadata standards
Metadata elements grouped into sets designed for a specific purpose, e.g., for a specific domain or a
particular type of information resource, are called metadata schemes. For every element the name
and the semantics (the meaning of the element) are specified. Content rules (how content must be
formulated), representation rules (e.g., capitalization rules), and allowed element values (e.g., from a
112/173
controlled vocabulary) can be specified optionally. Some schemes also specify in which syntax the
elements must be encoded, in contrast to syntax independent schemes. Many current schemes use
Standards Generalized Mark-up Language (SGML) or XML to specify their syntax (NISO, 2004).
Metadata schemes that are developed and maintained by standard organizations (such as ISO) or
organizations that have taken on such responsibility (such as the Dublin Core Metadata Initiative) are
called metadata standards.
Many different metadata schemes are being developed as standards across disciplines, such as
library science, education, archiving, e-commerce, and arts. In the table below, an overview of
available metadata standards is given.
113/173
9 goes as 5.14. The Cohesion van Plant breakdown structure, Identification, Coding, Plant
numbering, Structure, Master Data Management, Data exchange, Data storage, STEP AP221,
ISO 15926 and Gellish in the life cycles of a plant. (it deals with information aspects of the
translation from functional engineering to the hardware (materialized) engineering)
5.14.1 Introduction
Many of the elements, rules, regulations etc around Plant Structures and numbering of consistency,
already discussed above. Here we want the first names of their relationship's unveil. There are many
items been addressed through other technical issues, not to mention items of the behavioral
sciences? It may at first seem that this goes beyond the scope, is not true, because everything
discussed has its place in the overall picture. Discussing the relationship also involves the repetition
of parts from the above, especially on standards is noticeable.
In this chapter, in which also plant is renumbered, we make our arguments do not Principe distinction
between the tag numbers of tools and other process equipment (the only difference is the office eels,
which are in instrumentation for the physical objects around about 10-fold higher than that of
equipment, basic there is no difference. Process equipment is often a letter R reactor, E heat
exchangers, the instrumentation-beads is richer body of the letters of the alphabet made PDRIC gives
a differential pressure recorder Indicating controller. This is not an easy Items, the previous texts can
be seen that the standardization of it still in full swing. The balance between the long rule-based
uniform coding and shorter more random codes has not been found. The difference of several
standard electricity plants and different chemical processes of the respective examples. In addition,
our engineering tools CAE solutions for different alternatives on board, but not all the same and
combined use is certainly an issue. Letter code / numbering arbitrarily interchanged is often spoke,
orderings through PPS, AKS, VNS or similar systems, with proper attention to work well but often
provide (unnecessary) long number systems.
5.14.1.1 The primary BP (The primary BP)

The plant breakdown structure intersects a plant in several ways, first we follow the primary BP, with
some modifications, the plant around 25 years in operation, the capacity and the product is usually of
character changed.
Buying raw materials
Operations
Sell Product
Logistic
5.14.1.2 Secondary BP (BP The secondary)

The secondary BP includes the creation and maintenance of the plant.
Do Research
Design a Plant
A Plant Engineer
Basic Engineering
Detailed Engineering / Procurement
Construct a Plant
Pre commission the Plant
Test the Plant and Verification Thu
The Commissioning and Start-up Plant
Hand over to production
Maintain the plant
5.14.2 The Identifier (Letter Code)

The kick-off or the start of the coding and numbering is in the conceptual engineering. The function-
oriented structure is thereby used, it is in the design and development of the P & ID. .
t. .
114/173
5.14.2.1. Plant Equipment encryption function codes (General)
Giving the coding is not difficult, but this project by each participant from start to finish also carried out
(nothing else fits) will certainly be a problem. It takes an authoritative employee with a special sense
of coordination and an overview on effective coding
The process is doing this from a rough measurement signal as drawn on the P & I D through the
FCD's (functional control diagram) to the SCD's of the entire chain (including the hardware
connections and for 4-20 mA loops and Field Buses and on the run chart, DCS, MES, and BU EEP
COEP also SCD's or minor hassles software link lists). Alone in Process Automation several parties,
each discipline codes from their distribution
5.14.2.2. Plant Equipment encryption function codes (not Process Control)

1 The power industry is now ISO TS 16952-10 Power Plants, we are working on this for work to part
10 of IEC / ISO 81346
3 The function codes that STEPlib will constitute a good beginning for the process industry. The
alternative is the DIN 6779-13 it has no international
successor as ISO TS 16952-10 DIN 6779-10 it has become, see Part 4 of DIN 28008 in the table
below.
115/173
116/173
5.14.3.2.3. Plant Equipment identificatie de functiecodes (Procescontrol)
old old new new new
Funct ANSI/ISA S5.1 DIN 19227 IEC/PAS 62424 DIN EN 61346-2 NEN-EN-IEC/ ISO
ie 1992-07-13 1993-10 2000-12 81346-2 -2009
code
s
A Erst- Buchstabe Analysis
B Burner, Users choise
Combustion
C Users choise Users choise Users choise
D Users choise Dichte Users choise Dichte Density
E Voltage Elektrische Electrical Value Elektrische Voltage
Größen Variable
F Flow Rate Durchfluß, Flow Durchflussrate Flow Rate
Durchsatz
G Users Choise Abstand, Länge, Distance, length, Maß. Lage, Länge Users Choise
Stellung, position
Dehnung,
Amplitude
H Hand Handeingabe, Manual and Manuell Hand
Handeingriff manually
Initiated operation
I Current Users choise Current
J Power 2) Users choise Leistung 2) Power
K Time, Time Zeit Time based Zeit Time, Time
Schedule function Schedule
L Level Stand (auch von Level Niveau Level
Trennschicht)
M Users Choise Feuchte Users choise Feuchtigkeit, Users Choise
Luftfeuchte
N Users Choise Frei verfügbar Actuating setting Auswahl durch Users Choise
(motor) denAnwender
O Users Choise Frei verfügbar Users choise Auswahl durch en Users Choise
anwender
P `Pressure, Druck Pressure Druck, Vakuum `Pressure,
Vacuum Vacuum
Q Quantity Stoffeigenschaft, Quantity or counter Qualität Quantity
Qualitätsgrößen,
Analyse (ohne
D,M,V)
R Radiation Strahlungsgröße Radiation Strahlung Radiation
n
S Speed, Geschwindigkeit, Speed or frequency Geschwindigkeit, Speed, Frequency
Frequency Dreh- Frequenz
Zahl, Frequenz
T Temperature Temperatur Temperature Temperatur Temperature

U Multivariable Zusammengeset Mehrfachvariable Multivariable
zte Größen
V Vibration, Viskosität Vibration Auswahl durch Vibration,
Mechanical den Mechanical
Analysis Anwender Analysis
W Weight, Force Gewichtskraft, Weight, mass, Gewicht, Kraft Weight, Force
Masse force
X Unclassified Sonstige Größen 3) Nicht klassifiziert Unclassified
Y Event, Frei verfügbar Actuating setting Auswahl durch
State or Presence (valve) den
Anwender
Z Position, Users choise Anzahl von
117/173
Dimension Ereignissen,
Menge
The result is only the first letter of the function code, and then with a limited or too many letters are
unclassified users choices left.
First letter
D density (Density)
E electrical quantities (Electricity)
F flow rate (Flow)
H manual entry or manual operation (Hand)
K Time (Schedule)
L level (Level)
M humidity (moisture)
P Pressure (Pressure)
Q quality (in terms of property of a substance) (Quality)
S velocity or speed (Speed)
T Temperature (Temperature)
V viscosity (Viscosity)
W Mass (Weight)
Supplementary letter
D difference (Difference)
F ratio (Fraction)
Q running sum / integral (e.g., total flow) (Quantity)
Sequence point
A Alarm (Alarming)
C Control / Control (Controlling)
I Indicator (Indicating)
R storage / recording (Recording)
S circuit (switching)
Emergency operations Z (Emergency)
ceiling or H (High)
- Or lower limit L (Low)
Examples
PI512 pressure indicator
PD512 indication of the pressure loss
PICA 512 control the pressure with an alarm if it exceeds a threshold
F100 actual flow
FQ100 flown by Stat
The matter of the coding of signals is further discussed below separately
This overview (DIN 28004-flow diagrams or process plants) also gives a nice overview of what's PFD
and P & IDs, he must of reagents, this material has now been given an international
twist.LuisterenFonetisch lezen
DIN 28004 8.8.3.3.1 flow diagrams of process plants
Part 1 tag, diagram types, information content, replaced by 3.2001 to DIN EN ISO 10628
Part 2 Drawing version, replaced by 3.2001 to DIN EN ISO 10628) *
Part 3 Graphical symbols, replaced by 3.2001 to DIN EN ISO 10628
Part 4, Designation, DIN 6.2003 replaced by 6779-13 and DIN EN ISO 10628
)* ISO/CD 10628-2 Diagrams for chemical and petrochemical industry -- Part 2: Graphical symbols is
“under construction”
ISO 14617, Graphical symbols for diagrams, and IEC 60617, Graphical symbols for diagrams,
together form a universal library of symbols for all types of diagrams.
Part 1, General information and indexes

Part 2, Symbols having general application
Part 3, Connections and relate devices
Part 4, Actuators and related devices
118/173
Part 5, Measurement and control components
2)Part 6, Measurement and control functions
1)Part 7, Basic mechanical components
1)Part 8, Valves and dampers
1)Part 9, Pumps, compressors and fans
1)Part 10, Fluid power converters
1)Part 11, Devices for heat transfer and heat engines
1)Part 12, Devices for separating, purification and mixing
1)Part 13, Devices for material processing
1)Part 14, Devices for transport and handling of material
Part 15, Symbols for use on installation diagrams and network maps
1) Does the following summary

2) are given in the following
ISO / IEC 81346-1and 2 (2009)

The 81346 is a new international standard about multidisciplinary coding principles, know as
reference designations.
Using the structuring principles described in the standard and gain experience from the forthcoming
user guide, will lead you to economical benefit and enable you to re-use your engineering design in a
smart, structured and international recognized way.
The standard is the common international formula of standardized letter codes for any technical
object and in addition the basic philosophy of creating reusable modules of any design for further
development. The structuring principles enable control and overview of very complex designs.
The system which is the result from the 81346 standard is known as a reference designation system.
The codes are known as reference designations. You might know reference designations by
synonyms like ‘Component ID’, ‘TAG identifier’ or similar.
In chapter 5.12 this will be discussed in more detail
The standard is recognized as one of the most important news for technical disciplines within the next
10 years.
ISO / IEC 81346-1 (2009)
Industrial systems, installations and equipment and industrial products -
structuring principles and reference designations -
Part 1: Basic rules
IEC 81346-1:2009, published jointly by IEC and ISO, establishes general principles for the structuring
of systems including structuring of the information about systems. Based on these principles, rules
and guidance are given for the formulation of unambiguous reference designations for objects in any
system. The reference designation identifies objects for the purpose of creation and retrieval of
information about an object, and where realized about its corresponding component. This edition
includes the following substantial changes with respect to the previous one:
- a new introductory clause providing a description and explanation to the concepts used elsewhere in
the publication;
- a more comprehensive description of the structuring principles and rules for structuring are
provided;
- 'other aspects' are introduced, and the prefix sign # is assigned to these aspects;
- the concept of reference designation group has been deleted;
- the specific term 'transition' has been avoided and been replaced by an improved textual description
of this phenomenon in annex D;
- a new clause about labeling is introduced;
- the old annexes have been removed with the exception of the annex showing an example of the
application of reference designations within a system;
- a new annex explaining the manipulation of objects is introduced;
- 4 new annexes are introduced as rearrangement of detailed examples or explanatory information.
ISO / IEC 81346-2 (2009)

Industrial systems, installations and equipment and industrial products -
structuring principles and reference designations -
Part 2: Classifications of objects and code for classes.
119/173
IEC 81346-2:2009, published jointly by IEC and ISO defines classes and subclasses of objects based
on a purpose- or task-related view of the objects, together with their associated letter codes to be
used in reference designations. The classification is applicable for objects in all technical areas, e.g.
electrical, mechanical and civil engineering as well as all branches of industry, e.g. energy, chemical
industry, building technology, shipbuilding and marine technology, and can be used by all technical
disciplines in any design process.
Basic issues
Common methods for structuring and identification, earlier subjects that could be handled discipline
by discipline, have become increasingly important because of the integration that the use of IS/IT
tools in the design and engineering processes causes. The basic problem to solve is that when, in
different disciplines and in different IS/IT tools, and during different phases of the life cycle of a
developed product or system, the same component is referred to, it has to be known by all involved to
be just that, in order to allow that information on its properties can be shared or transferred.
A typical example can be a signal, which is partly transferred as a conventional electric signal, partly
on a bus, and partly stored in a process computer. Such a signal may be handled in an electrical CAD
system and in tools for programming of the process computer, and these need to exchange
information on it.
Main publications
The structuring principles laid down in the International Standard 81346 series: Industrial systems,
installations and equipment and industrial products - Structuring principles and reference designation,
developed jointly by IEC TC 3 and ISO TC 10, are central and considered capable of dealing with this
problem in an appropriate way. The standard consists presently of two parts: IEC 81346-1 Part 1:
Basic rules, and IEC 81346-2 Part 2: Classification of objects and codes for classes.
NOTE - International Standard 81346 was issued 2009-07 replacing IEC 61346, which consisted of
four parts: Part 1: Basic rules , Part 2: Classification of objects and codes for classes, Part 3:
Application guidelines and Part 4: Discussion of concepts (technical Report) and IEC/PAS 62400
Letter codes - Main classes and subclasses of objects according to their purpose and task. These
publications have all been withdrawn.
The structuring principles of International Standard 81346-1 is a "backbone" for the structuring of
products and systems and therefore also inherently of related documents and documentation. It is
therefore referenced from a number of other publications like IEC 61082-1, IEC 61355, and IEC
62023.
IEC 61666 Industrial systems, installations and equipment and industrial products - Identification of
terminals within a system is directly based on IEC 81346.
The IEC 81346 series together with IEC 61175 Industrial systems, installations and equipment and
industrial products - Designation of signals provides the required links between software objects, e.g.
programmable logic controllers languages as in IEC 61311-3 and the related hardware objects.
IEC 62491 Industrial systems, installations and equipment and industrial products - Labeling of cables
and cores provides rules and guidelines for the labeling of cables and cores/conductors used in
industrial installations, equipment and products, in order to maintain a clear relation between the
technical documentation and the actual equipment and for other purposes.
The full capability of IEC 81346 is only taken into service by a limited segment of the market, and
incompatible identification systems for some application areas exist. Therefore marketing and more
concrete guidelines for specific areas, such as process control, may be necessary to develop.
Closely related topics: Document and documentation management, Information modelling, Semantic
definitions.
Ongoing maintenance and new projects (2010-01)
The revision of IEC 61346 was finished 2009-07. The work was carried out by the Maintenance Team
TC3/MT18, with participation from ISO TC10. The revised publication is published under the number
IEC 81346, indicating that it is a joint IEC/ISO series of publications, intended to include Parts from
both organizations.
With this result available the revision of IEC 61666 was initiated and is presently going on. Document
3/943A/CDV IEC 61666 Ed.2: Industrial systems, installations and equipment and industrial products
- Identification of terminals within a system, were closing 2009-09-18. The document 3/987/RVC has
been circulated and the FDIS registered.
A New Work Item Proposal 3/810/NP Rules for identification systems, was circulated for approval
within IEC TC3 and ISO TC10. The project was approved as IEC 62507 Ed. 1 in TC3 and TC3/PT 39
was set up. Document 3/836/RVN gives details on the result and the comments provided. As a result
of the work in PT 39 document 3/908/CD IEC 62507 Ed.1: Requirements for identification systems
enabling unambiguous information interchange - Part 1: Principles and methods, was circulated for
120/173
commenting, closing 2008-09-26. The comments were discussed at a meeting with the PT and
document 3/946/CDV (with the same title) prepared. It was closing 2009-12-09 and the comments are
presently being considered by the PT39...
5.14.3.2 Symbols of chemical apparatus and equipments

Below are listed some symbols of chemical apparatus and equipment normally used in a P&ID,
according to DIN 30600 and now ISO 14618.
Symbols of chemical apparatus and equipment
Thermally
Jacketed Cooled or
Pipe insulated
pipe heated pipe
pipe
Jacketed
Half pipe Pressurized Pressurized
mixing
mixing horizontal vertical
vessel
vessel vessel vessel
(autoclave)
Vacuum
Pump pump or Bag Gas bottle
compressor
Fan Axial fan Radial fan Dryer
Packing Cooling
Tray column Furnace
column tower
Plate &
Heat Heat
Cooler frame heat
exchanger exchanger
exchanger
Fixed
Double U shaped
straight Spiral heat
pipe heat tubes heat
tubes heat exchanger
exchanger exchanger
exchanger
Covered Curved gas

Dust trap Funnel
gas vent vent
121/173
Pressure
Viewing
Steam trap reducing Flexible pipe
glass
valve
Control Manual Back draft

Valve
valve valve damper
Needle Butterfly Diaphragm

Ball valve
valve valve valve
5.14.3.3 General instrument or function symbols
122/173
5.14.3.8. Plant (serial) numbers (main principles to capture) ISO / TS 16952 IEC 81346-1
Common methods for the identification and structuring, rather items which can be handled by the
various disciplines have become increasingly important because of the integration that the use of IS /
IT tools in the Guided Design and engineering processes caused. The fundamental problem is that
when, in different disciplines and different IS / IT tools, and also at various stages of the life cycle of a
product or system developed, the same part is called, is to identify all relevant simply be that, in order
to allow the information on the properties can be shared or transferred. A typical example may be a
signal that is transmitted as part of a conventional electrical signal, partly on a bus, and partly stored
in a computer process. Such a signal can be processed in an electrical CAD system and CAE reading
tools for programming the computer process, and these need to exchange information.
5.14.3.8.1 Quote from the chapter 6.1.8.1.5.1 on PNS
PNS is a new number system for processing. There are three points in PNS:
1. to create a numbering system to the machines themselves have enough information to

communicate with various devices to allow using field bus systems data with other systems to
exchange. It will not separate field bus addresses, directories, etc. are necessary.
2. The various methods such as temperature, pressure, level, flow etc, to be numbered as properties
of the material to which they belong such as tank level and temperature, pump pressure, pipe flow
etc. instead of using the names of process variables. This makes it much easier to oversee the
process control system. For example, the conveyor belt PP2 a tank - T9 (PP2T9) - with switches on
two levels, contains PP2P1 pump controls. In a traditional instrumentation drawings, the switches at
two levels of sign them as such as level switches PP2LG1 (flat size 1) and PP2LG2 are mentioned,
but in this way, it is only possible to tell that the switches at two levels of a pump. However, with PNS
is also possible to short codes such as PP2T9L1 PP2T9L2 and use. Now it is clear that two levels -
L1 and L2 - Tank PP2T9 check the pump. In the same way, the different sizes on a pipe or a tank as
properties of the pipe or tank such as PP2WL3F2 (3 water Pipe stream 2) and PP2WL3T1
(temperature 1) are listed.
3. All parts of the plant including replacement parts with the same numbering system to be numbered.
It will not separate numbering systems for machinery, instrumentation, pipes, etc. are necessary.
5.14.3.8.2. Plant Equipment Numbering. (General)

In the example of the Plant Breakdown structure we have seen in the previous and alphanumeric
code is made up of a breakdown structure and function code. The ISA method is the feature code
first, and then follows the sequence.
First method
Many used the method of sequence with the P & ID number as the basis
P & ID no 201 (this is not the drawing number) than the first pressure transmitter PT 20101,
The following PI 20102 pressure instrument from top left to bottom right by numbered.
Second method
Sometimes the requirement that it should relate to the process equipment, with a chain of dual
(redundant because of vulnerability) equipment installed, this method is problematic. Then applying
A / B as a numerical code can quickly lead to confusion in engineering, construction, operation and
maintenance data consultations.
Use of prefixes
There are many owner operators prefixes denote the INSTALLATION, so a code for the top of the
break-down structure, all objects will automatically get a code to crack1 when the first cracker at that
location.
Meta data
When defining meta data, we must ask ourselves what is meta data, the cry of the first pressure
transmitter PT 20101 with dates, maybe may be not but it is not a good meta data, there is indeed
enough define kidney income information. The condition should be to indicate which of the larger
123/173
system part in code as well as in the name of the pressure transmitter PT 20101 Third xyz evaporator.
Thus, both the course code as the P-20 101 PT 20101 device code is defined.
This way people can easily look at an existing computer. PT20101 The code would in it be sufficient,
but in general, such codes do not remember the man.
Plant Breakdown Structure

This is the top down structure that indicates how the plant is classified.
Alone would equal a set of physical plants breakdown structuring a variety of plants can get according
to a different team that does break down.
The PPS, AKZ, VNS or equivalent (Plant Breakdown Structure) method
TAGs 1 2LAC03 CT002 QT12 is defined as follows:
Level 0: 1 is the first part of a power plant

Level 1: 2LAC03 of the second water-steam system feed water Pomp third.
Level 2: CT002 is the second temperature measurement.
Level 3: QT12 is the 12th cap (well) of a temperature measurement.
This is the twelfth well of the second temperature reading of the third feed water Pomp half of the
water-steam portion of the first part of a power plant.
QT is the actual function code; the other characters give the
Function place "again.
Because the main power plants have the same structure to grant equal numbers for the process
industry, this course different.
A disadvantage is the impossibility long codes on drawings and display areas. But as we process in
our plants here long (for a less extensive problem) is that a solution here.
Level 0: 1
Level 1: 1 2LAC03 the can at this level and below are omitted
Level 2: The CT002 2LAC03 at this level and below are omitted.
Level 3: The Code Part QT12 CT002 at this level and below, no longer necessary.
Condition is that somewhere on the specific information carrier parent code key (lower right corner) is
shown clearly once. In itself nothing special, in our electrical systems and controls, we do this a long
time.
Displays function codes as for field bus participants, DCS, PLC applications, MES and EEP also
helps communications, in any case, on pain of recode and errors in the configuration and
maintenance.
Function codes (chapter 8.8.3.2.3. Plant Equipment identification
AHH
TIC AH TIC AH SH AL SL TIC AH SH AL SL
AL
6018 ALL 6018 1 2LAC03 CT002 QT12
ISA DIN KKS ......VNS..... IEC/ISO 81346-1
Designation codes
The attentive reader probably has some balls signed the instruments to give this response to the texts
so far, so that you may or may not have in mind to fill with characters written.
We highlight in blue indicate a doubling in the function code
124/173
They make mistakes quickly by itself to establish, simply by following the same proven and
Identification Instrument, the function code in the upper part of the circles and ovals are declared
clean.
Designation of the code in the lower part of the ball will be placed, ranging from the short-cut from
6018 to 1 2LAC03 CT002 QT12
For all non electro technical plant components is IEC / ISO 81346 is not yet ready for the power
plants, both electrical and non electrical components as in the figure by the red (power stations)
blocks indicated everything is ready
ISO / TS 16952-10 many siblings will be given, as we share Din 6779 unaltered, have seen.
The figure below shows a cutout of a screen image of a CAE system, where a portion of a P & ID is
shown.
125/173
Format of Code
Types and Levels of the Code
In examining the various demands placed on the identification of plants, plant parts and equipment in
power plants, PPS has three different types of code
� (FunctionProcess-related code)
Process-related systems and identification of items of equipment according to their functions in
mechanical, civil, electrical and instrumentation and control engineering
� Point installation code
Identification of the points of the installation of electrical and instrumentation and control devices in
the installation units (e.g. cabinets, panels)
Location Code �
Identification of sites in structures, and floors in the rooms and the areas of fire and topographic terms
(surface grille)
5.14.3.8.3. Plant Equipment Numbering (Non Process Control)

The numbering system should follow the numbering system breakdown plant
V-6060 unit in 6000 as Shell, or VSN for power
Below is a picture within which the PPS structure break down a pump P001 is in their area and
numbered as pump P is encrypted.
126/173
5.12.3.8.8. Plant Equipment numbering (Procescontrol)
According to ISA would be a PT-33 PT-(2 3) 4 2 33 plant site area (section) and subarea number of
the same letter code (instruments). The first two digits are often used and gives the recognizable PT-
February 4, 1933
In the PPS method, we place beside QT12 from 1 2LAC03 CT002 QT12 a 33rd pressure transmitter,
which has the numbering system of the plant breakdown number system to follow, as previous
example is that a 2LAC03 CT002 P 33, but with the 33rd pressure transmitter (PT) of same system
breakdown 2LAC03 CT002 1, note that the instrument with a letter code is defined.
5.12.3.8.5. Plant Equipment numbering i.r.t STEP AP 221, ISO 15926 and Gellish
This example is the definition of the nozzle and manhole K! A A-1, which are both part of the vessel V-
6060 unit in 6000 unit each row in the table describes a fact by defining an associations between the
objects. The columns' Association type contain standard STEP AP221 association and the columns'
class ID 'and' class of physical object name 'includes class IDs and class names STEPlib Standard.
The other text in Table 1 is defined and user created as part of the 6060th design process for V-tables
as in Table 1a and 1b can be used to any conditions of any type of equipment.
This example is the definition of the nozzle and manhole K! A A-1, which are both part of the vessel V-
6060 unit in 6000 unit. Each row in the table describes a fact by defining an association between the
objects. The columns' Association type contain standard STEP AP221 association and the columns'
class ID 'and' class of physical object name 'includes class IDs and class names STEPlib Standard.
The other text in Table 1 is defined and user created as part of the 6060thdesign process for V-tables
as in Table 1a and 1b can be used to any conditions of any type of equipment.
Fact id Item id Item name Association Item id Item name

type
101 1 unit 6000
102 2 V-6060 is a part of 1 unit 6000
103 3 head-1 is a part of 2 V-6060
127/173
104 4 K1A is a part of 2 V-6060
105 5 flange-1 is a part of 4 K1A
106 6 reducer-1 is a part of 4 K1A
107 7 neck-1 is a part of 4 K1A
108 8 collar-1 is a part of 4 K1A
109 9 K1A-flanged end is a part of 5 K1A
110 10 A-1 is a part of 8 V-6060
111 11 flange of A1 is a part of 10 A-1
112 12 cover of A1 is a part of 10 A-1
The features and other aspects of the individual items can be described in a similar way, using the
standard classes of properties and categories of documents from STEPlib. This is illustrated in Table
2 for main-1 and the nozzle of the barrel K1A V-6060 from Table 1
Luisteren
Fonetisch lezen
Woordenboek - Gedetailleerd woordenboek weergeven
Assoc. Item Item Association object id Encoded UoM Classifi- Unique Name of Class of
id id name type informati cation Class id Property or
on *) (from Class of Encoded
(Value) STEPlib) Information
(from STEPlib)
201 3 head-1 has property 101 4124 mm which is a 550206 external diameter
202 3 head-1 has property 102 3300 mm which is a 550325 crown radius
203 3 head-1 has property 103 635 mm which is a 550361 knuckle radius
204 3 head-1 has property 104 12 mm which is a 550454 thickness before forming
205 3 head-1 has property 105 10.3 mm which is a 550967 minimum thickness after
forming
206 3 head-1 has property 106 40 mm which is a 550326 cylindrical height
207 3 head-1 is described 108 DIN which is a 910181 fabrication standard
via 28013
209 4 K1A has property 110 DN 40 x which is a 551563 nominal diameter
20
210 4 K1A has property 111 150# which is a 551396 rating
211 5 flange-1 is described 115 ANSI which is a 910181 fabrication standard
via B16.5
212 5 flange-1 has property 116 3/4" which is a 551563 nominal diameter
We see from the above tables that V-6060 unit in 6000 exists, the equipment code defines V as the
vessel (vessel) so it should also be some kind of device, and then there are many forms. The
breakdown structure is V-6060 appears to unit 6000.
Also as you may expect, ISO 15926 and Gellish no problems with it.
So it is for those with Prolist Plib a different starting point has no problem with this designation
standards used. as I said do not need the entire code designation to be mentioned, however it is
advisable to keep the same function codes, as mentioned above need not all be mentioned
Designation Code
5.14.5.5.Plant signal encoding function codes (Process Control)

The need for universal comprehensive identification, coding and numbering for
equipment and signals. The numbering system would plant breakdown number system to follow, but
the plant breakdown mechanism does not always go to that detail level
We consider therefore the origin of the signals.
We have seen in several places independently several different systems and various measurement
equipment, computational and control signals can be assigned. In the previous chapter on master
data management, this has been one other heavier dimension figure below, we are seeing in the light
128/173
of information transmission between the systems: Field Buses, DCS, MES, BU EEP, and COEP. And
all their Guided Design and maintenance tools.
DCS ERP ERP

MES BU CORP
We see from the above tables that V-6060 unit in 6000 exists, the equipment code defines V as the
vessel (vessel) so it should also be some kind of device, and then there are many forms. The
breakdown structure is V-6060 appears to unit 6000.
Also as you may expect, ISO 15926 and Gellish no problems with it.
So it is for those with Prolist Plib a different starting point has no problem with this designation
standards used. As I said do not need the entire code designation to be mentioned, however it is
advisable to keep the same function codes, as mentioned above need not all be mentioned
Designation Code
5.14.5.5... Plant signal encoding function codes (Process Control)

The need for universal comprehensive identification, coding and numbering for
equipment and signals. The numbering system would plant breakdown number system to follow, but
the plant breakdown mechanism does not always go to that detail level
We consider therefore the origin of the signals.
We have seen in several places independently several different systems and various measurement
equipment, computational and control signals can be assigned. In the previous chapter on master
data management, this has been one other heavier dimension figure below, we are seeing in the light
129/173
of information transmission between the systems: Field Buses, DCS, MES, BU EEP, and COEP and
all their Guided Design and maintenance tools.
Outside the signals in the operating range (typically used in the above figure), four signals but the
existence of the hardware alarm in LO or HI position mode are mutually exclusive, the true signal
encoding is not explicitly excluded. This we find with the HART application.
(11) Requires option code D1 hardware settings.

For the 3051S SIS Safety Transmitter, the scalability on all models except range 0.
3051S2CD0 the scalability is limited to 2:1, the 3051S2CA0 scalability is limited to 5:1.
Special configuration (software) for the figure.above.

(C1 (12) Custom software configuration (A Configuration Data Sheet must be completed, see page
38.)
C3 Gage pressure calibration on Rosemount 3051S_CA4
C4 (12) NAMUR alarm and saturation levels, high alarm
C5 (12) NAMUR alarm and saturation levels, low alarm
C6 (a) (1912) Self Custom alarm and saturation levels, high alarm
Note: requires option code C1, custom software configuration. A Configuration
Data Sheet must be completed, see page 38.)
C7 (1) (1912) Self Custom alarm and saturation levels, low alarm
NOTE: Option Code C1 required, custom software configuration. A Configuration
Data Sheet must be completed, see page 38.)
C8 (12) Low alarm (standard Rosemount alarm and saturation levels)
Also runs the field of various forms of sigaaltransport now a bit different, Hart, with code A and B, we
have just discussed, Fieldbus Foundation now follows. (Profibus follows thereafter)
130/173
5.14.5.5.8. The control and Diagnose functions
These control and Diagnose functions are worked out below
3051S REV 23
revised April, 2007
Channel Designations
(Advanced Diagnostic – Statistical Process
11 = All ADB-SPM Outputs
Monitoring)1 = Pressure
2 = Electronics Temperature 12 = ADB-SPM1 Pressure Mean
3 = Internal use 13 = ADB-SPM1 Pressure St. Dev
4 = Pressure Mean 14 = ADB-SPM2 Pressure Mean
5 = Absolute Pressure for Mass Flow (AO OUT) 15 = ADB-SPM2 Pressure St. Dev
6 = Process Temperature for Mass Flow (AO OUT) 16 = ADB-SPM3 Pressure Mean
7 = Compensated Mass Flow 17 = ADB-SPM3 Pressure St. Dev
8 = Absolute Pressure for Mass Flow (AO CAS_IN) 18 = ADB-SPM4 Pressure Mean
9 = Process Temperature for Mass Flow (AO CAS_IN) 19 = ADB-SPM4 Pressure St. Dev
10 = Scaled Differential Pressure for Mass Flow
Standard Function Blocks (Execution Time in ms) Relevant Specifications

RESOURCE (NA) Current Draw = 18.5 mA
Sensor Transducer (NA) Voltage Requirement = 9 to 32 VDC
LCD TRANSDUCER (NA) Polarity Insensitive
Analog Input(20 ms) Qty 4 Back-up LAS capability standard
PID(25 ms) Supports Plant Web Alerts
Supports Function Block Instantiation
Optional Function Blocks (Execution Time in ms) Optional LCD displays up to 4 variables
A01 Option Ci = 0.0 uF (capacitance)
Input Selector(20 ms) Qty 2 VCR = 20 max (1 permanent, 19 configurable)
Signal Characterizer(20 ms) Link's = 30
Arithmetic(20 ms) Schedule Entries = 14
Multiple Analog Input(20 ms)
Analog Output(20 ms) Qty 2 Current Revision Information
Control Selector(20 ms) Device Revision = 23 (Hex 17)
Output Splitter(20 ms) DD Revision = 3
CFF Revision = 4
D01 Option ITK Certification to Revision 5.0
Advanced Diagnostic Transducer (NA)
Plugged Impulse Line Detection Revision History
Statistical Process Monitoring Revision 23 (April, 2007)
H01 Option
Mass Flow Transducer (NA)
PlantWeb Alerts
Failed/Maint/Advise Active
Alarm Type Recommended Action Text String
Event
None None No Action Required
Advisory LOI Failure Check Display and Sensor Connections
Process Anomaly Detected Check the Statistical Process Monitor Status in the ADB
(SPM) Block.
Plugged Impulse Line
Maintenance Check the Device Impulse Line(s)
Detected
Secondary Value Degraded The Instrument Body Temperature may be too Hot or too
Cold. Confirm that it is within the Operating Range of the
131/173
Transmitter.
Primary Value Degraded The Instrument Pressure may be too High or too
Low. Confirm that it is within the Operating Range of the
Transmitter.
Sensor Module Memory Replace the Sensor Module at the next scheduled
Warning Maintenance.
Failed Sensor Module Memory
REPlace the Sensor Module.
Failure
Secondary Value Failure Check the Interface Cable Between the Sensor Module
and the Field bus Electronics Board.
Primary Value Failure Check the Interface Cable Between the Sensor Module
and the Field bus Electronics Board.
NV Memory Failure Reset the Device then Download the Device
Configuration.
Memory Failure Replace the Field bus Electronics Board.
GENERAL BLOCK INFORMATION
The Modes, Resource, transducer, and all function blocks of the device modes of operation. These
modes of operation govern the operation of the block. Each block supports both automatic (AUTO)
and out of service (OOS) modes. Other modes can also be supported.
Changing the mode of operation if the modes of operation, set the MODE_BLK.TARGET to the
desired mode. After a short delay, the parameter MODE_BLOCK.ACTUAL changing the display mode
when the block is functioning properly.
Permitted Modes
It is possible to prevent unauthorized changes to the operation of a block. To do this,
MODE_BLOCK.PERMITTED configure only the desired modes are possible. It is recommended to
always select OOS as one of the permitted functions.
Types of Modes
The procedures in this manual will be helpful to understand the following modes
AUTO
The functions of the block will be executed. When the block exits, these will continue to update. This
is usually the normal operating mode.
Out of Service (OOS)
The functions of the block will not execute. If the block outputs, they will usually not update the status
of all values that are passed to downstream blocks will be bad "bad". Make some changes to the
configuration of the block, change the mode of the block to OOS. When the modifications are
completed, change the mode back to AUTO.
MAN
This mode allows variables that are passed from the block be set manually for testing or overwrite ..
Other Types
Other types of changes modes are Cas, Rcas, milling, Iman and LO. Some of these can be supported
by different function blocks in the Rosemount 2051.
For more information, see the Function Block manual,
NOTE : When an upstream block is set to OOS, this will affect the output of the status of all
downstream blocks. The figure below shows the hierarchy of the blocks:
Simulation
Simulation is the functionality of the AI block. To support the testing, or change the mode of the block
to the exit on hand and change the settings or simulation to allow using the configuration tool and
manually enter a value for the measured value and status (this single value will apply to all outputs).
In both cases, the first ENABLE jumper on the transmitter field
NOTE
All instruments have a fieldbus simulation jumper. As a safety measure, the jumper must be reset
each time a power failure. This measure is to prevent the devices by simulation in the staging process
132/173
was installed by the simulation on. With simulation enabled, the actual measurement value does not
affect the OUT value or status. The out-values will all have the same value as determined by the
value simulation.
RESOURCE BLOCK
FEATURES and
FEATURES_SEL
The features parameter is only read and decide which features are supported by 2051. Below is a list
of the functions of the 2051 supports. FEATURES_SEL is used to switch to one of the supported
features are found
the attributes parameter. The default setting of the Rosemount 2051 select one of these functions.
Choose one or more of the supported features if applicable
UNICODE
All configurable string variables in 2051, with the exception of tag names are octet strings. Either
ASCII or Unicode can be used. If the configuration device is generating Unicode octet strings, set the
Unicode option bit.
Report
The 2051 supports alert reports. The Reports option bit must be set in the bit string attributes to use
this feature. If this is not set, the host poll for alerts. When this bit is set, the transmitter is active report
alerts.
Resource
Block
Transducer
Block
Analog Input (AI Block)
Other function blocks
SOFT W LOCK and HARD W LOCK
Entrance to the safety and security features include hardware write protection off, the hardware and
software write lock bits of FEATURE_SEL parameter, the parameter WRITE_LOCK, and
DEFINE_WRITE_LOCK parameter.
The WRITE_LOCK parameter prevents modification of parameters in the device, except to the
WRITE_LOCK parameter. During this time, the block will continue their normal operation inputs and
outputs and executing algorithms. When the condition is cleared WRITE_LOCK, WRITE_ALM an
alert is generated with a priority that matches the parameter WRITE_PRI ..
The FEATURE_SEL parameter allows the user to select a hardware or software write protection
write-protection or no assets. The hardware security function, so that the HW_SEL FEATURE_SEL
parameter. When this bit is on the WRITE_LOCK parameter is read only and will reflect state of the
hardware switch. In order to write software to lock, the SW_SEL FEATURE_SEL bit set in the
parameter.
If this bit is set, the WRITE_LOCK parameter set to "locked" or "unlocked." Once WRITE_LOCK
parameter is set to "Locked" by either the software or the hardware lock, all user requested writes as
determined by the DEFINE_WRITE_LOCK parameter is rejected ..
The DEFINE_WRITE_LOCK parameter allows the user to configure or lock functions (both software
and hardware write) will control writing to all blocks, or only on the source and the transducer blocks.
Internal updated data such as process variables and diagnostics will not be restricted by the security
off.
The following table shows all possible configurations of the WRITE_LOCK parameter.
MAX_NOTIFY MAX_NOTIFY The parameter value specifies the maximum number of reports warning
that the source sent without an attachment, which corresponds to the number of buffer space
available for alert messages. The number can be set lower, to alert overflow control by adjusting the
parameter value LIM_NOTIFY. If LIM_NOTIFY is set to zero, no warnings will be reported.
Other
function
133/173
blocks
FEATURE_SEL
HW_SEL bit
MAX_NOTIFY MAX_NOTIFY The parameter value is the maximum number of reports warn that the
source may be sent without a confirmation, which corresponds to the amount of buffer space
available for alert messages. The number can be set lower, to alert flooding, by adjusting the control
LIM_NOTIFY
parameter value. If LIM_NOTIFY is set to zero, then no alerts are reported.
Luisteren
Fonetisch lezen
Woordenboek - Gedetailleerd woordenboek weergeven

FEATURE_SEL
HW_SEL bit blocks
0 (off) 0 (off) NA 1 (unlocked) Read only NA All
0 (off) 1 (on) NA 1 (unlocked) Read/Write NA All
0 (off) 1 (on) NA 2 (locked) Read/Write Physical Function
Blocks only
0 (off) 1 (on) NA 2 (locked) Read/Write Everything None
1 (on) 0 (off) (1) 0 (unlocked) 1 (unlocked) Read only NA All
1 (on) 0 (off) 1 (locked) 2 (locked) Read only Physical Function
Blocks only
1 (on) 0 (off) 1 (locked) 2 (locked) Read only Everything None
(1) The hardware and software write lock select bits are mutually exclusive and the hardware select
has the highest priority. When the HW_SEL bit if set to 1
(on), the SW_SEL bit is automatically set to 0 (off) and is read only.
5.14.5.5.6. Function blocks.

In part, we XXXXX.1.2 whole list of Foundation Fieldbus function blocks come, we will first discuss a
single simple block the ANALOG INPUT BLOCK.
Analog Input (AI) function block

Configure the AI block a minimum of four parameters are needed to configure the AI Block. The
parameters are described below with example configurations at the end of this section.
CHANNEL
Select the channel that corresponds to the desired sensor measurement. The 2051 measures both
pressure (channel 1) and temperature sensor (channel 2).
L_type
The l_type parameter defines the relationship of the sensor measurement (pressure or temperature
sensor) to the desired output of the AI block (eg, pressure, level, flow, etc.). The relationship can be
direct, indirect or indirect square root.
Direct
Select direct when the desired output will be the same as the sensor measurement (pressure or
temperature sensor).
134/173
Indirectly
Select indirect when the desired output is calculated from a measurement sensor measurement (eg a
pressure measurement is made to a deterministic level in my tank). The relationship between the
sensed and calculated linear measurement.
Indirect Square Root
Select indirect square root when the desired output is a secondary measurement based on the
sensor measurement and the relationship between sensor measurements and the square root is
derived measurements (eg flow).
XD_SCALE and OUT_SCALE

The XD_SCALE and OUT_SCALE each include three parameters: 0%,
100%, and, engineering units. Set these based on the L_TYPE:
L_TYPE is Direct
If the desired output Measured variable is set to the XD_SCALE the "Primary_Value_Range. This is
found in the Sensor Transducer Block. Set to match XD_Scaling, Out_Scaling XD_SCALE.
L_type is indirectly
When a derivative measurement is made based on the sensor measurement, set the XD_SCALE the
operating range to present the sensor sees in the process. Find the derivative values corresponding
to XD_SCALE 0 and 100% points and set the XD_Scaling, Out_Scaling.
Table 3-1. I / O Channel Definitions

Channel Number Channel Description
A differential pressure units in AI.XD_SCALE
2 temperature sensor units in AI.XD_SCALE
L_type is Indirect Square Root

When an inferred measurement is made on the basis of the sensor measurement and the relationship
between the measurement and derived measurement sensor is a square root, put the XD_SCALE to
the range to represent the sensor sees in the process. Find the derivative values corresponding to 0
and XD_SCALE
100% points and set the XD_Scaling, Out_Scaling.:
FEATURE_SEL
Configuration Examples
Pressure transmitter Situation #1
A pressure transmitter with a range of 0 – 100 psi.
Solution
135/173
Table 3-2 lists the appropriate configuration settings.
Table 3-2. Analog Input function block configuration for a typical pressure transmitter.
.
Pressure transmitter used to measure level in an open tank
Situation #2
The level of an open tank is to be measured using a pressure tap at the bottom of the tank. The
maximum level at the tank is 16 ft. The liquid in the tank has a density that makes the maximum level
correspond to a pressure of 8.0 psi at the pressure tap (see Figure 3-1).L
it SECURITY SWITCH WRITE_LOCK
136/173
WRITE_LOCKRITE_LOCK
137/173
5.14.5.6.3 Signaaltransport van EEP en naar, al dan niet via MES, naar DCS en
fieldtransmitters en terug.
Dit met nog steeds in de achtneming van VNS (KKS) ISO/IEC 81346 en de relevante
MasterdataMangement aspecten
138/173
5.13.5.12 relationships between various system components, objects and their representation.
The graphic representation (drawings on paper, flat electronic display and data-centric view, whether
or not 3D) have been used for years for various types of display assemblies. For many regions (the
medical world, setups and tactics in football, chess, skating, our technique) are drawings with or
without the use of symbolism often subject-made. The current trend from the WEB makes it blew over
by the variety, ambiguity, etc., for the broad-based geibruiker it any easier. It is recommended in the
email technology so leaving them clear and agreed lines to follow.
We follow it here first on the lifecycle of a group, a site or plant and its components for new plants
called "green field" or green field projects from "cradle to grave" also called cradle to grave.
Under Master Data Management, we will in the next chapter of existing installations or brown field
projects better view.
We see in this way a list of documents which arise in part matches the list or in the transmittels
inventation to bid and contract award in the composition of the contractors.
5.13.5.8.2.Detail Engineering
PFD’s only functions ara indicated
Equipment lists
5.13.5.8.3 Basic Engineering

P&ID
The indication objects and features simplified weather data.

Often has the appearance of a Process Automation somewhat simplified form
If the P & ID's words made the line architectures are not known, as they also must be fully
subscribed, the P & ID's completely unreadable.
Functional Control Diagrams
Functional Logic Diagrams
Batch Functional Diagrams
Equipment index the mark all objects and functions

Equipment in the index (similar to the tool index) we take all physical objects that must be specified,
and afterwards claimed the offers satisfy looked and weighed selected above and purchased etc.
Line list (list Piping)
Piping specification
Structured stem Civil List
Instrument index indicating all objects and functions

The instrument index, we take all physical objects that must be specified, then claimed the deals
looked satisfied and weighed, and purchased selected above etc
Electrical indicator index all objects and functions

The instrument index, we take all physical objects that must be specified, then claimed the deals
looked satisfied and weighed selected above and purchased etc.
Equipment data sheets
Instrument data sheets
Electrical data sheets
139/173
Typical loopdiagrams
5.13.5.5.11.Detail Engineering
Process / Mechanical
Equipment drawings
Isometrics
Process Control / Instrumentation
System Control Diagrams
System Logic Diagrams

Safety related.
Non safety related
Sequence Control.
Loop diagrams instantiated
Hook-ups (Installation details)
Electrical
Civil
5.13.5.8.5 Uit het “directe” zichtveld van Proces automatiserings systemen (Objecten en functies)
Soorten Veldapparatuur
Transmitters
KlEPpen
Signaal omvormers
Veldbussen
Netwerken
Hulpapparatuur
Netwerken
DCS-en
Dit is een groot device (mogelijk op te delen in verschillende objecten) met veel functies
PLC’s regel, stuur, vergrendel en afloop activiteiten

Dit is een groot device (mogelijk op te delen verschillende objecten) met veel functies
PLC’s beveiliging
MES’sen
EEP systeem (vertikale integratie van transmitters, DCS en PLC, MES en EEP)
140/173
EEP SAP met functie code de horizotale integratie

De objecten die in SAP worden bijgehouden zijn functiEPlaatsen, equipment en installaties
13.14.5.8.Bestaande installaties Brownfield
Een zinvole PBS met zinvole coderingen is bij Bestaande installaties dan een kwestie van passen en
meten, in het hoofdstuk over Master Data Management hebben we dit goed kunnen zien.
141/173
5.15 What elements, ideas and considerations are technically still missing
5.14.1 By first looking at what we do have is probably easier to answer this question
5 14.1.2. But we must now build new factories, ensuring that ICT work?
5.14.2.1. Introduction
You understand it, this is a joke and this is entirely not the intention, because we have really robust
codes able to deal with in order to achieve effective solutions, on the other must
present the required flexibility for the same efficiency.
ABCD
5.14.2.2 What are key elements we have discussed so far from Chapter 1.
5.12.2.2.1 The work we are in chapter 6.1.1.4. encountered ones.

By studying at level 4, one can see when the information and thus the codes and text info on its
carriers need to be declared
5.14.2.2.2. Plant breakdown structure as seen in Chapter 6.1.5.
142/173
Now there are several methods to consider for our representation and an appropriate concept for the
engineering machinery.
There is the concept of division and breakdown of the disciplines,

This starts with the conceptual engineering with the main equipment, other
components will be in place with code and number in the break-down
structuring. As you may know this are the familiar ease-doubles,
triple cycles, quaterlingen etc. in the first letter of the function codes established.
According to division rather than the P & ID example per discipline from top left to bottom right. This is
flexible for expansion by parts to accounting or annex and improvements in process efficiency, the
environment or reducing the number of bridges,
More Principal is to choose the course of the process to bring forth a number plant sections choose,
process units or process steps (unit operations units according to a number of items and equipment)
and then the breakdown by sub unit or units equipment.
Instrumentation as SAP is XXX-YYY-ZZZ-AAAA9999BB an option
This code means:

XXX Plant section
YYY Process Unit
ZZZ Sub Unit
AAAA Instrument prefix (indicating the function of the instrument eg PT)
9999 Instrument Number
BB Instrument suffix
143/173
5.14.2.3.. Generieke Namen ook namen van de klassen in de RDL bekend.
Er bestaan (helaas) verschillende class libraries,
Binnen het vakgebied proces control zijn we er ondanks dit fenomeen toch in geslaagd om van de
groEP instrumenten de namen en definities voor de objecten (meetinstrumenten) gelijk te houden
binnen STEPlib, ISO 15926, Gellish, Prolist, IEC61987, zie de tabellen hieronder.Voor de andere
vakgebieden zijn we nog niet zover, maar er zijn methoden voor.
In het hierna volgende geven we voor een pressure meter de respectievelijk RDL van STEPlib, ISO
15926, Gellish, Prolisten IEC61987-11 de naam en de definities
5.10.2.3.1”STEP applicatie” als basis voor velen (voorbeeld uit STEPlib working tables)
intended to is a meter
measure and intended to
indicate a measure and
contr
is a pressure indicate a
ol 70 pressu 1,0 19-
Eng190,75 1,1 speciali 70, and/or pressure and/or accE 19-Apr- I&C
engi ,3 re 70, meter Apr-
lish 8 46 zation 254 produce a produce a Pted 96 peers
neeri24 meter 673 96
of signal which signal which
ng
represents the represents the
## measured measured
# pressure. pressure.
contr
pressu
ol 70 1,0 is a 16- Andries
Eng190,75 re 1,9 70, pressur accE 16-Jan-
engi ,3 72, synony Jan- van
lish 8 transm 81 324 e meter Pted 03
## neeri24 083 m of 03 Renssen
itter
# ng
contr
pressu is a is a regulator
ol 70 1,0 intended to 30-
Eng190,75 re 1,1 speciali 70, regulato intended to accE 1-Dec- I&C
engi ,3 70, control a Dec-
lish 8 regulat 46 zation 357 r control a Pted 97 peers
## neeri25 366 pressure. 96
or of pressure.
# ng
5.10.2.3.1 STEPlib super class en class weergave (device namen)
Super
class class Definition
is a meter intended to measure and
indicate a pressure and/or produce a
pressure signal which represents the measured
instrumentation meter pressure.
is a pressure meter in which pressure
absolute pressure is applied to one side of the sensor
instrumentation meter while the other side has a vacuum chamber.
is a pressure meter where pressure
gauge pressure is applied to one side of the sensor
instrumentation meter while the other side is open to atmosphere.
144/173
5.14.2.3.1.1 afstemming 28-02-2007 tussen JEMIMA/IEC61987-1/PROLIST/STEPlib
Langauge 120 JEMIMA IEC Ger DEVICE STEPl STEPlib STEPlib Relati STEPli JEMIMA Synony
community 61987 man LIST ib UID name Definitio on b Definition ms
-1 name PROLIS n type Super s
(Devic T name type
e
type)
11 Instrumen Dru 70,324 Pressur is a is a pressur pressure/
8 tation ck PRESSURE e meter specia e differenti
mes METER meter intende lizatio meter al-
s 140/JEMIMA d to n of pressure
umf //. measur meter
or JEMIMA_C0 e and that
mer 00107 indicate detects
a the
pressur differenti
e and/or al
produce pressure
a signal between
which the
represe measurin
nts the g point
measur and the
ed vacuum
pressur or the
e. atmosph
ere
5.14.2.3.2.ISO 15926 part 4
Unique name Text definition Source Notes Super Super Super

class 1 class 2 class 3
Pressure A detecting instrument, detecting class_of_inanimate_physi
meter usually a hand-held or instrument cal_object
portable instrument
consisting of a digital
display and a pressure
sensing element
(pressure transducer),
that is intended to
measure and indicate a
measured pressure.
5.12.2.4.2 ISO 15926 toEPassing met marktconforme componenten
RDLthing
idPCA designation type status definition deleted creator creationDate
RDS388 TRANSMITT CLASS_OF_ Incomplete A pressure MVSEN 2004.02.15

2237330 ER BODY INANIMAT transmitter body
0 ROSEMOUN E_PHYSICA for Rosemount
T L_OBJECT 3051CG5A22A
3051CG5A22 1KB4I1L4M6Q
A1KB4I1L4 4.
M6Q4
145/173
5.14.4.9.2.3.2 Gellish
ID
Lang
of
uage
Co Si
com Si
nt mu Ri
munit Le mul R Suc
ext lta Left Re gh
y ft tan Right UI e ces
La for ne hand lati Relatio t Date
(cont ha Fa eou hand Full D Um sor D
ng left ou objec on n ha Statu of
1 ext of nd ct s objec Definition definiti of o a of l
ua ha s t typ type nd s start
left obj id car t on Uo Mr rela c
ge nd car nam e name obj of life
hand ect din name M k tion
obj din e ID ect
objec id aliti s ID
ect alit id
t es
na ies
nam
m
e)
e
is a meter
intended to
intended to measure and
measure and indicate a
control pressur 1,07 is a indicate a pressure pressure
Engl 190, 70,3 1,14 70,25 accEPt 19-Apr-
1 engine e 0,67 specializ meter and/or produce a and/or 1
ish 758 24 6 4 ed 96
ering meter 3 ation of signal which produce a
represents the signal which
measured pressure. represents
the measured
pressure.
pressur
control 1,07 is a pressur
Engl 190, 70,3 e 1,98 70,32 accEPt 16-Jan- 1
1 engine 2,08 synony e
ish 758 24 transmi 1 4 ed 03 0
ering 3 m of meter
tter
pressur is a regulator
control 1,07 is a
Engl 190, 70,3 e 1,14 70,35 regulat intended to control a intended to accEPt 30-Dec-
1 engine 0,36 specializ 1
ish 758 25 regulat 6 7 or pressure. control a ed 96
ering 6 ation of
or pressure.
5.14.2.4.De keuze van de equipment of device-namen.
Ook voor andere equipment dan de reeds bekende pressure meter zijn bovenstaande rijen in de
verschillende tabellen gemaakt en voor een groot deel geharmoniseerd.
De funktie code uit het vorige hoofdstuk 6.1.4.1 Coderings systeem en Nummerings systeem geeft
gelijk ook de benaming weer voor de objecten. Uiteraard is dat een generieke benaming, alle
gelijksoortige equipment zou dezelfde benamining krijgen.
Daar is het gewenst proces gerelateerde informatie aan de objectnaam toe te voegen.
Binnen besturings en beveiligings systemen noemen we dit in het Engels Longname, in het Duits
Langname, respectievelijk Shortname en Kurzname.
5.14.2.4.1 De relatie tussen equipment of device-namen en document-namen.
Niet alle tekenningen / documenten kunnen aan een speciefiek uniek object worden opgehangen.
Indien men bijvoorbeeld van een installatie 3000 gelijksoortige tekeningen heeft en men stopt deze
allen in een electronisch opbergsysteem met alle de naam functionel logics erop, (immers hun relatie
met een PLC zzz doet vermoeden dat dit zo hoort) dan is men er echter van verzekerd dat men deze
voorgoed kwijt is. Willekeurig komen ze bij oproEP wel eens op het beeldscherm, maar wat men
zoekt en wat men krijgt heeft nooit de goede relatie.
Masterdata management wil niet alleen zeggen geef een lijstje van atributen, maar in de eerste plaats
geef in een eenvoudige structuur een hoofdnaam die voldoende disccriminerend is.
5.12.2.5 De formele benaming van equipment, grootheid of documenten.
146/173
5.10.2..5.3.Een van de woordenboeken uit Hoofdstuk 6.1.5 e.g. STEPlib
Elk object of grootheid moet zijn eigen unieke naam hebben en behouden, voor de CAE machine
maakt het niet uit of die naam iets voorstelt, spreken we af dat een Temperatuur element een “Stom
ding” dan zullen alle computers dit al zoemend aanvaarden. De mens is hier de bEPerkend factor, die
vindt zoveel “dingen” stom dat hij de bezine motor van zijn auto ook een “stom ding” vindt de
volgende dag specificeert hij eenTemperatuur element onder de motor kap.
5.10.2.5.4 De engineerings machine (complete fabriek) STEP, ISO 15926 en Gellish (6.1.5)
De engineeringsmachines die we daar besproken hebben van verschillen stelsels van normen,
symbolen en lijstjes aanboord. Doelmatige inzet moet echter bekeken worden afhankelijk van
grassroot/Brownfield Condities en de andere elementen.
Bij eenduidige inrichting naar een van de normen , STEP AP221, ISO 15926 en Gellish zal die dan ter
beschiking staan (alle objecten).
5.12.2.5.5 Het engineerings tool (instrumenten) Prolist IEC, 65E XXX, Ecl@ss ETIM (6.1.5)
De engineeringsmachines die we daar besproken hebben van verschillen normen, lijstjes symbolen
aanboord, maar in samenhang met Prolist kan alleen de laatste worden gebruikt.
Plib wordt in dit verband gebruikt voor niet instrumentatie / electrotechnische onderdelen
5.12.2.5.6.Voor beiden, de combinatie (voor een complete fabriek) (6.1.5)
Voor proces control equipment is de naamgeving dezelfde en in harmonie met de ISA zie XXXX voor
de atributen zijn we hard op weg, over de mechanical equipment kunnen we dat niet zeggen, hoewel
het mechanismen ertoe is overgedragen.
5.12.2.5.7 Naast een naam heeft elke entiteit een nummer
Uit de bibliotheken hebben we formele naam genomen, al deze namen hebben ook nog een uniek
nummer
Left hand object id Left hand object name
70,324 pressure meter
Klasse of groEPsnamen bij de inrichting van portals
In internetverkeer wordt portaal gebruikt als een webpagina die dienst doet als "toegangspoort" tot
een reeks andere websites, die over hetzelfde onderweEP gaan. Soms dus synoniem van start- of
hoofdpagina, maar meestal ook als vertrekpunt en overzichtstabel voor verdere navigatie binnen een
onderweEP.
De Engelse naam, die ook veel in Nederlandse teksten gebruikt wordt, is portal.
Veeleer dan te proberen een eenduidige en algemeen geldige definitie te geven, volgen hierna
enkele veel gebruikte definities of pogingen tot definitie.
Een webtoEPassing die via een eenvormige gebruikersinterface toegang geeft tot een gevarieerd
aanbod aan informatiebronnen.
Meer dan een webpagina met links naar andere toEPassingen.
De universele, veEPersoonlijkte toegang tot elke toEPassing of informatiebron.
Beveiligde en veEPersoonlijkte toegang tot inhoud en toEPassingen.
Alhoewel dus afwijkende definities gehanteerd kunnen worden, wordt algemeen aangenomen dat
een portaalsite in grote mate over volgende functies moet kunnen beschikken:
Authenticiteit bevestigen
VeEPersoonlijkbaar zijn (personalisatie)
Inhoud beheren
Toegang verlenen tot toEPassingen
GroEPeren en integreren
Zoeken en catalogeren
Samenwerken bevorderen
147/173
Meertaligheid
Distribueerbaar via diverse kanalen
We kunnen zo’n portaal in wezen opvatten als een rangeer station (spoorwegen, telefoon centrale,
high rise warehouse, hedendaags postsorteerstation. Bij binnenkomen wordt het gesorteerd op het
doelstation, bij de uitgaande richting gaat het ook doelgericht met een pakket mee. Hierbij is een
juiste labeling nodig inclusief de juiste adressering
CoEPorate webportalen
CoEPorate intranetten gemeengoed werd in de jaren 1990. Zoals intranetten groeide in omvang en
complexiteit, werden webmasters geconfronteerd met toenemende content en user management
uitdagingen. Een overzichtelijke weergave van informatie over het bedrijf was onvoldoende
beoordeeld; gebruikers wilden personalisatie en maatwerk. Webmasters, indien bekwaam genoeg,
waren in staat om een aantal mogelijkheden te bieden, maar voor het grootste deel belandde rijden
gebruikers weg van het gebruik van het intranet.
Veel bedrijven begonnen te bieden tools om webmasters te helpen het beheer van hun data,
applicaties en informatie gemakkelijker, en door persoonlijke standpunten. Portal oplossingen kunnen
ook workflow management, samenwerking tussen werkgroEPen, en het beleid beheerde inhoud
publicatie. De meeste kunnen toestaan van interne en externe toegang tot specifieke zakelijke
informatie met behulp van veilige authenticatie en single sign-on.
Normen JSR168 ontstond rond 2001. Java Specification Request (JSR) 168 normen toestaan dat de
interoperabiliteit van de portlets portaal tussen verschillende platformen. Deze normen kunnen
portaal ontwikkelaars, beheerders en consumenten om op standaarden gebaseerde integratie van
portals en portlets in een verscheidenheid van vendor oplossingen.
Het concEPt van het content aggregatie lijkt aandacht te krijgen, dynamiek en portal-oplossing zal
waarschijnlijk aanzienlijk blijven evolueren in de komende jaren. De Gartner Group voorspelt de
generatie 8 portals te breiden op de Business Mashups concEPt van het leveren van een
verscheidenheid aan informatie, tools, applicaties en access points door middel van een enkel
mechanisme.
Met de toename in user generated content, ongelijksoortige gegevens silo's, en bestandsformaten,

informatie-architecten en taxonoom nodig zal zijn om gebruikers de mogelijkheid om tag (delen) van
de gegevens. Dit zal uiteindelijk leiden tot een rimpel effect waar gebruikers zal ook het genereren
van ad hoc-navigatie-en informatiestromen.
CoEPorate Portals bieden ook klanten & medewerkers self-service mogelijkheden.
Hosted webportalen
Als coEPorate portals populariteit kreeg een aantal bedrijven begonnen met het aanbieden hen als
een gehoste dienst. De gehoste portaal markt fundamenteel veranderde de samenstelling van de
portals. In veel opzichten ze dienden enkel als een instrument voor het publiceren van informatie in
plaats van de verhevener doelen van de integratie van legacy applicaties of de presentatie van
gecorreleerde gegevens uit gedistribueerde databases. De vroege hosted portal bedrijven zoals
Hyperoffice.com of de nu opgeheven InternetPortal.com gericht op samenwerking en scheduling in
aanvulling op de verdeling van de bedrijfsgegevens. Zoals gehost webportalen zijn gestegen in
populariteit hun functies is uitgegroeid tot gehoste databases, document management, e-mail,
discussieforums en nog veel meer. Hosted portals automatisch gegenereerde personaliseren van de
inhoud van hun modules op een persoonlijke ervaring te bieden aan hun gebruikers. In dit verband zij
zijn trouw gebleven aan de oorspronkelijke doelstellingen van de eerdere coEPorate web portals.
Domein-specifieke portals
Een aantal van portalen zijn gekomen over die specifiek zijn voor het specifieke domein, biedt
toegang tot verbonden ondernemingen en diensten, een goed voorbeeld van deze trend zou de groei
in onroerend goed portals die toegang geven tot diensten, zoals makelaars, verhuizer, en advocaten
dat aanbod overdrachtskosten. Langs dezelfde lijnen hebben industrie-specifieke nieuws en
informatie portals verschenen, zoals de klinische studies specifieke portal: IFPMA Clinical Trials
Portal
Het bedrijfsportaal en het gemeenschapsportaal zijn twee brede categorieën van portaalsites. Deze
sites bieden dan een startpagina met nuttige links en informatie voor de medewerkers van het bedrijf
of de leden van de gemeenschap
148/173
5.12.2. De ontbrekende delen (The FIATECH Vision statement)
De FIATECH heeft de teksten van haar werkprogramma 9 geupdate.“Lifecycle Data Management &
Information Integration” is nu (voorjaar 2009) de nieuwe slogan. Het nu volgende Vision statement is
een meer gedetailleerde uitwerking van deze slogan. Dit lijkt een goed uitgangspunt immers
FIATECH heeft haar werk vanuit hun visie tot uitvoering goed in kaart gebracht. (de complete
FIATECH organisatie met het gehele werkprogramma wordt nog later behandeld)
The Vision statement beschrijft wat in de toekomst gewenst is

Het toekomstige project planningssysteem zal interactieve evaluatie van project alternatieven
versterken, verwezenlijking van concEPtuele ontweEPen toelaten en projectplannen die het best aan
de behoeften van allen voldoen.
Dit samenwerkings planningsmilieu zal volledige voorlichting van de effecten van besluiten
betreffende kosten, programma's, en levenscyclusprestaties verstrekken. Het systeem zal de
aanvankelijke input aan een uitvoerig projectplan en specificaties verstrekken, die uiteindelijk in een
Systeem van de Informatie van de Levenscyclus van Activa wordt gevangen, verdere
projectontweEPen te leiden en stroomafwaartse projectfuncties te steunen. Het systeem van de
Informatie van de Levenscyclus van Activa is een stichting van de toekomstige staatsvisie, die als
bewaaEPlaats voor al ontweEP en planningsinformatie en interface voor alle systemen en
toEPassingen dient.
Werk Processen
De project teams zullen met klanten en andere bewaarders interactie aangaan om diverse opties te
herzien en een reeks projectvereisten en plannen te ontwikkelen en te raffineren. De opties zullen
worden geëvalueerd gebruikend een rijke reeks van geïntegreerdee modellering en simulatie
5.12.3. Herkenbaarheid van componenten in ontweEP, procurement, voorraad en in situ.
Voor wie in fabrieken heeft gewerkt heeft opgemerkt dat de equipment verbaal vaak met de naam en
de code wordt aangeduid bijvoorbeeld, eerste voorreactor, R 12001, vanuit productie begrijpelijk,
immers hun communicatie middelen tussen veld en meetkamer maakten het onmogelijk slechts een
van beide te gebruiken.
Objecten uit verschillende vakdiciplines, De eerste letter voor een Pomp is een P, velen weten dit,
Voor meetinstrumenten kennen we voor druk ook de eerste letter P. Op zich niet erg als de volgcode
maar verschillend is, daar moeten we zelf op letten, de computer doet dit niet die gooit de meest
sofisticated druktransmitter zonder pardon op de pompen vloer.
149/173
We herkennen de ontleding (decomposition) van een XXXXXXX fabriek via de zwarte lijn, dit wordt
ook wel de plant break down structure genoemd (hoofdstuk 1
150/173
Information management
Formalisierte Process beschreibungen
6 THE SOLUTIONS 3.6 35
Formalisierte Prozessbeschreibunges (VDI/VDE Richtlinie

3682) als Basis für die Auswwahl von feld gereráten
B POLKE & M. POLKE
ZVEI/FGCA-Workshop – ZVEI Frankfurt Main 14.Oktober
2003
further to be developed
Examples from other disciplines is required but possible ???
DSM Corporate Safety, Health, Environment & Manufacturing

Global Manufacturing Competence Center - Process Control- Hindrik Koning
“Harmonizing standardization on Data Integration in the life cycle of the Process and Power plants.”
Date 2005-09-21
151/173
152/173
Annex 1 Some extensive reading material
A.1.DISTRIBUTED CONTROL AND PROGRAMMABLE ELECTRONIC SAFETY SYSTEMS FOR A

LARGE OFFSHORE OIL AND GAS PLATFORM.
Abstract: The Paper Describes the various aspects of the selection, design, standards and problems
associated with Process Control and Electronic Safety systems for a large offshore oil and gas
platform.
It has been written essentially in an educational vain and the principles addressed can assist personnel
involved in the specification, design and maintenance of programmable electronic control systems as
used in Process or Safety related Applications.
Included are lists and typical examples of the documents which require to be produced, applicable
standards which are of use and details of a very advanced hierarchical shutdown system.
INTRODUCTION: The design of the Control systems for a large offshore platform is a complex task in
that there are many constraints associated with it. These vary from the equipment density, when figures
in the order of $80,000 per square metre of platform real estate are quoted there is little wonder at this,
weight - severe weight restrictions being in place because the modules must be capable of being lifted,
restrictions on the UPS supply available, space and most importantly the hazardous nature of the
product.
The Programmable Electronic Control and Safety Systems must be Specified and designed to exacting
standards. This is essential in that these systems are responsible for the control of the facility and also
the safeguarding of platform personnel and a major oil company strategic asset worth $billions!
Platforms are generally built up of units which are called modules and within these are situated the
various items of plant. These items of plant vary from Reinjection Compressors to Pressure Vessels
and are generally purchased as discrete packages.
Whilst the package controls are generally 'stand alone' they do need to interface with the Platform
Control System and this is achieved by Serial Links for loops of a non critical nature and hard wiring for
critical circuits. Also it is necessary to interface these packages with the platform Programmable
Electronic Safety System, both these areas are difficult to supervise as there are so many vendors and
subvendors involved.
Once the Control systems have been determined conceptually the associated interfaces with the
Onshore base and /or other platforms need to be finalised. The Control/ Monitoring being made
available to these facilities by means of Telemetry.
The Modules although being located within a very small area lend themselves to Distributed Control in
that they may well be fabricated in different locations and by utilizing the advantages of a distributed
approach can be pre commissioned on a 'Standalone basis'.
Of course if the platform has been designed on the single lift 'integrated deck' basis then the control
systems are generally centrally located. There are however still advantages in the distributed approach
since should an 'event' occur the adjacent module controls continue to report and operate.
There are generally FOUR totally discrete Control systems utilised on Major offshore platforms that
should be considered, these being:-
a. The PROCESS CONTROL SYSTEM (PCS) - Utilised for the process control of the platform.
b. The PROCESS AND EMERGENCY SHUTDOWN SYSTEM (PSD/ESD) - Responsible for the
safe shutdown of the process and utilities in the event of a Process Fault or Fire/Gas detection.
153/173
c. The FIRE AND GAS SYSTEM (F&G) - This system with its associated sensors detects fire or
gas and initiates appropriate fire protection systems ie., Deluge, CO2 or Halon release. It alerts
personnel to the location of the event and automatically operates the platform status lights/ audible
warning. The appropriate signals to the PSD/ESD system for controlled shutdown of the plant are also
initiated.
d. The DRILLING CONTROL SYSTEM - Provides the Control and Safety Interlocks for the
drilling operation. This system is outside the scope of this paper.
The PSD/ESD and F&G system are sometimes called a COMBINED SAFETY SYSTEM and are
generally purchased from the same supplier even though the systems are functionally totally
independent of each other. There are advantages in this approach in that wherever possible similar
hardware is utilised and the interface is clearly defined. Owing to the criticality of the intersystem signals
they are generally hardwired and are backed up by serial communication links.
THE CENTRAL CONTROL ROOM
Control of an offshore Platform revolves around the Central Control Room, this room is the most
important in any Offshore facility since it is the location of the Human Interface.
Operations staff must be capable to effectively and in a well ordered manner control the facility under
both normal and 'extreme stress' conditions. This is why in ALL installations an ERGONOMIC STUDY
should be undertaken. A study of this nature provides the guidelines for the design of the Control Room,
detailing such items as console layout, keyboard height, lighting requirements, functionality,
communications, room colours, operator chair type, VDU graphics colours and alarm priority. Of course
consideration should be given to Console noise and the location of printers.
When considering printers it is worthwhile to consider ink jet or laser units in the specifications since
one day the DCS suppliers may wake up to the office technology which is currently available.
The Controls Engineer has to be prepared to spill blood, have fits, ulcers and tear his hair out over this
room, Architects will try to dictate requirements, EVERYONE will say too much space has been
allocated and opinionated engineering will rule if one is not careful. It is essential that Operations are
involved, after all they have to work in the room and if IGNORED they will ensure that even the best
CCR does not suit them! What must be stressed is MAINTAIN THE SPACE requirement, too little space
will result in a poor operating environment for operators.
The use of large graphic backwall displays which utilise video projectors is slowly becoming a feature in
control rooms, some regard this as a gimmick' but this is just not so. The displays are a very useful tool
for replacing the 'old' mimic and also serve for demonstration, documentation and training purposes.
A useful reference document associated with ergonomics is ISA RP60.3-1985 'Human Engineering for
Control Centres'.
SYSTEM SELECTION
It is essential that the RIGHT SYSTEM is selected. In the selection there are three distinct phases these
being:-
a. PREQUALIFICATION
b. SELECTION
c. IMPLEMENTATION
PREQUALIFICATION
154/173
The prequalification is best carried out by utilising a technical questionnaire, this really sorts out the best
systems and suppliers with eventual selection being restricted to perhaps three to four bidders from a
field of 12 to 15.
The prequalification is a very important document and should for expediency be of a database format,
as each supplier answers the same questions it is then possible to easily compare the answers. From
this document it can be determined whether there are technical, engineering or support problems with
the various systems.
The questionnaire highlights any failings with the system, engineering or support and by utilising this
method a equitable prequalification can be made.
SELECTION
Once the prequalification is complete then the initial functional specification and associated invitation to
bid has to be prepared. These documents are then sent out to the suggested MAXIMUM of four bidders
and work begins for the poor unfortunates who have to put it all together.
What must be remembered by the Company requesting bids is that they are not cheap to produce and
if it is their intent to go to sole tender then they should not waste suppliers time or money, they certainly
would not like something similar happening to them!
The bid documents submitted by the vendors should initially be superficially technically reviewed, the
idea of this is to immediately identify a non compliant bid. Generally if there has been a good
prequalification all bids will be of a high standard technically.
Concurrently with the Technical Bid Evaluation there should be a Commercial review by A CONTROLS
ENGINEER IN ASSOCIATION with the purchasing department.
Finally the bid clarification meetings take place, costs are finalised and a supplier is selected.
IMPLEMENTATION
At this stage you have to find out if you have selected the correct supplier, this you do by partitioning the
purchase order into two sections, these being 'IMPLEMENTATION SPECIFICATION' and 'DESIGN
AND CONSTRUCT'. The supplier must 'pass the test' of implementation (sometimes called preliminary
design) where hopefully 90% of the problems can be identified at an early stage.
The Implementation spec also sets down the ground rules and provides a basis on which to engineer
and build the system. Particular emphasis should be placed on planning and ensuring that the supplier
is fully conversant with what is required and how the system is to be configured. The actual
configuration being completed at a later stage during detail design. During this period data which is
required by other sections in the platform design team must be supplied, these include layout and
footprint, heat dissipation, weights and availability MTBF.
Suppliers generally under estimate the work to be done in the implementation specification phase, it is
hard work involving long hours but if done correctly can save both money and schedule delays in the
long run.
THE SYSTEMS
For normal operation the Process Control system is utilised. This system is DISTRIBUTED with
OUTSTATIONS in FIELD EQUIPMENT ROOMS (FER) in each module. Each outstation is stand alone
and in the event of a communication failure (a pretty remote possibility in that the communication links
are duplicated and routed differently) the control actions associated with it still operate.
Also 'critical signals' are hardwired to provide increased reliability.
155/173
RELIABILITY and AVAILABILITY are of course paramount with any failure possibly costing $millions.
Reliability and Availability of a system is enhanced by the use of 'REDUNDANT CONTROL' in the form
of DUAL Multifunction Controllers and automatic transfer of I/O in the event of failure. Availability figures
in the order of 97% for the Process Control System and 99.99% for the Combined Safety System are
generally required.
CABLES, WIRING AND DUCTING
Fire retardant/ fire resistant cables, wiring and ducting which has low toxic and low smoke emission
properties should be included in the functional design specification. Utilising Materials which have these
properties has several advantages including the elimination of Halon systems along with the associated
environmental problems.
FIELD EQUIPMENT
Electrical equipment selected for use on an offshore oil and gas platform is usually protected against
igniting any hazardous atmosphere by some means. This is generally intrinsic safety for the
instrumentation and other means for high/medium voltage electrical equipment ie.,Exd Exe etc. Special
care should be taken to ensure that the interfaces to the PCS or CSS are compatible with the input/
output devices and that 'ohms law' is addressed ie., calculations are done to ensure that there is
sufficient available voltage at the transmitters.
Smart 'Analogue' Transmitters are being used increasingly on platforms. It is very important to ensure
that the requirements are included in the functional design specification since when the 'communication
mode' is selected it is possible that the interface at the PCS or CSS may not be compatible and
spurious control or shutdown actions occur.
INTERFACES
It is necessary to have extensive interfaces with the Motor Control System, these are achieved by use
of 'System Cables'. System Cables are preformed and utilise plug and socket arrangements. This
method of connection is also used for interconnection between the Marshalling and System Cabinets. It
is a very efficient means of connection in that (a) module yard terminations are minimised and (b) the
system cables can be coiled into the marshalling cabinets for transport.
THE DISTRIBUTED APPROACH
The advantage of the distributed approach is apparent in that every I/O point can be checked in the
module yard thus minimising costly offshore commissioning.
Even if the CCR is in another module simple PC interfaces are used to test that each and every I/O
point associated with the module outstation is operating satisfactory. Thus when the system network is
finally connected together one can be confident that the system is operable.
SERIAL LINKS
Where there are packages then serial links can be used to great effect. On a large platform these may
well be numerous, perhaps 15 to 20 and they are very economic in transferring information without
hardwiring each I/O point.
Engineers should however be WARY in that many suppliers have a simplistic view of them and the
statements 'EASY' 'A PIECE OF CAKE' 'WE CAN IMPLEMENT ANY SIGNAL YOU REQUIRE' are
common place. We all know that this is not true. It is very easy to state that a serial link is the
PANACEA of the Control Signal world but realities do dictate that there is more to it than that.
It is however quite possible to achieve a fully operational link at an early stage by testing hardware
against hardware and protocol against protocol.
156/173
The best method of achieving the desired results is to (a) Purchase an interface to your PCS which can
be readily connected with the serial links to be tested, (b) ensure that the interface is totally portable in
that it can be readily transported to your package supplier's location and finally (c) terminate and test
'EARLY' against the appropriate equipment, producing a serial link specification as you glean the
information from the various suppliers. By taking this approach the majority of surprises can be avoided.
Of course the dreaded 'MURPHY'S LAW' cannot always be catered for and may ultimately confound
even the most rationally thinking engineer.
It is very important to remember that the signals coming from packages via serial links will have link
delays associated with them and in order to get firstup alarming special programming of the PLC may
be necessary. Also link speed is critical for accurate event recording on the system.
SPECIAL APPLICATIONS
Offshore platforms today are utilising latest technology to the fullest to achieve the implementation of
special applications, typical of these are as follows:-
WELLFLOW: Other than some experimental systems there are at present no proven way for
measuring two phase flow from each well. With this special application flow through the individual
wellheads is inferred by comparing three massflow calculations for gas,oil and water, averaging and
correcting them. The first calculation utilises the tubing head pressures and the test separator results for
the well in question and computes the resultant inferred flow.
Using this method it is proven that accuracies of around + or - 2% will be achieved.
MASSFLOW: Some platforms are now utilising the Process Control systems for the calculations of
Massflow, however in general this is not so as 'Flow Computers' of a 'standalone' nature continue to be
used in that they are tried and proven, incorporate self testing features such as pulse integrity and
finally use proven algorithms that are readily accepted by the authorities monitoring the fiscal metering.
CHOKE CONTROL: The choke valves control the flow from each wellhead and the control associated
with these devices is becoming increasingly complex. The chokes must have the capability to be
stroked individually and also together with other chokes, of course this has to be achieved without
causing any major process upsets.
The control normally operates in the following way, the operator selects the choke in question and keys
in the opening percentage required. The choke then opens rapidly through what is known as the
'erosion zone' (normally 0 to 25%) which is a zone of operation where rapid wear occurs on the valve. If
the operator has selected less than this value the PCS will not allow the action to take place and will
advise the operator by way of a help message.
When the valve has been manually positioned then the operator will put the choke into 'cascade'. At this
point the chokes in automatic are pulsed sequentially until the desired setpoint is reached. The operator
also has the ability to 'bias' any of the chokes so that 'optimisation' of the various wells is achieved.
Should the platform have a Reinjection Compressor it is important to consider the effects of control and
shutdown of that unit. This is a very complex subject which requires a Dynamic Stability Study to be
performed in order to ensure safe and effective control under these conditions.
RED TAGGING: Modern PCS have the ability to 'redtag' or electronically lockout items of equipment.
Red tagging systems now being implemented ensure that the operator is aware of any item of
equipment or plant area which is subject to a permit by ensuring that the permit system is tied in with
the PCS and that the permit is actually issued by the PCS via the operator responsible.
157/173
Of course the maintenance man still has the ultimate responsibility to also physically lock out the unit
and complete appropriate documentation ie., site permits.
ENERGY MANAGEMENT: On an offshore platform Energy Management Systems are used, usually if
there are no generation problems then there is sufficient power for all users however when generation
capacity is down or drilling activities are in place it is essential that priority of users is defined. These
systems are with the technology available being incorporated into the platform PCS system. The
system allocates priorities both on startup and shutdown of electrical plant.
ALARM PRIORITY: Process Control Systems have Intelligent alarm systems and these facilities are
extensively used on offshore platforms. All alarms are prioritised into priority (Bright RED), normal
(MAGENTA) and information (YELLOW) with different alarm tones and frequencies for the various
priorities.
Operators are very often subjected to INFORMATION OVERLOAD when confronted with poor alarm
management. Priority alarms should direct the operator what to do by effective use of message lists.
Also less important alarms should not cloud the operators decision by causing confusion.
Packages on shutdown should alarm only the first two or three alarms the remaining alarms being
suppressed. Of course the graphics reflect all alarm states.
Considerable time and effort should be devoted to this subject of alarm priorities as it is crucial to
effective operation of any facility.
ELECTRONIC MANUALS: Office technology has started to make inroads into the offshore
environment. Instead of the hard copy manuals which when you really want them are either not
available, pages are missing and have scrawlings all over them one can now call up the manual via a
video disc system. It is then possible to look, take a copy if necessary and finally include edit
comments. These edit comments are not immediately included in the text original but are placed into a
special comment column. The process superintendent then has the final choice whether to include the
comment in the next manual update.
PCS DESIGN DOCUMENTS
It is worthwhile considering the extensive use of a database system in the production of the design
documents which are to be used as input documentation by the system supplier. Most of the major DCS
suppliers use Microsoft Access or Excel programs for the configuration of their database. For instance
I/O schedules and Message Lists can be read straight from the disk into the system thus saving time
and eventually schedule.
The generation of 'base graphics' MUST be configured by the operating company since a supplier just
does not have the experience to produce graphics which accurately reflect the process. It is not simply
a job of 'copying' the P&IDs. The most effective way of configuring these base graphics which the
supplier enhances is to use the supplier configuration package, thus having the ability to transfer the
data to the supplier database easily.
It is also a great idea to use a Database for creation of the Instrument Index , Cable data Sheets, I/O
schedules, Message Lists and Motor Schedules as data can then be effectively transferred from one
database to another. This does have the added advantage in that errors are minimised once one
database has been checked. Mind you if adequate checking does not occur then the problem will be
multiplied.
The following input documents should be produced for issue to the PCS supplier. Some operators
consider that it is more effective for the PCS suppliers to create some of these documents but that is
just not so in that they just CANNOT have adequate experience to provide a comprehensive enough
package.
158/173
(1) I/O SCHEDULES - this is the base document around which configuration revolves, information
contained within it should include tag number, whether it is an Intrinsically safe or Non I.S. loop, digital
or analogue, range, units, critical or non critical loop, report input and alarming priority.
Typical PCS I/O schedule fields are detailed in attachment 1.
(2) FUNCTIONAL LOGIC DIAGRAMS - these are the base documents which the supplier uses for
motor and sequence control. They are usually drawn utilising logic blocks around the logic symbols
which are identified in AS 1102.9 - 'Graphical Symbols for Electrotechnology - Part 9 Binary Logic
Elements'.
(3) MESSAGE LISTS - these lists are the base document which are used for the generation of reports,
alarm and special messages.
They are usually configured using a database format which the supplier can easily transfer to his own
database.
Typical PCS Message List fields are detailed in attachment 2.
(4) BASIC GRAPHICS - the rudimentary graphics which are initially passed to the operating company
OPERATIONS GROUP for comment and then used by the supplier as the base graphic background
which the supplier then enhances.
(5) CABLE DATA SHEETS - these sheets are used rather like termination diagrams where normal
termination diagrams do not exist.
(6) MOTOR SCHEDULE - this document details the requirements needed by the energy management
system ie priority of tripping.
(7) TERMINATION DRAWINGS - details of all incoming terminations and cables.
(8) FUNCTIONAL DESIGN SPECIFICATION - This document specifies the functional and technical
requirements of the system. It should be comprehensive and miss nothing. 'Slimline' specifications DO
NOT work and leave the customer wide open for variations.
THE 'TAIL END CHARLIE SYNDROME'
It has always been the case that the Controls/ Instrumentation design could not be finalised until the
piping design has been completed because the instrument locations are unable to be adequately
determined. This of course is true if total accuracy is required, however, if you have a schedule problem
there is a method of achieving 90% accuracy at a very early stage, picking up the remaining 10 % at a
later time.
This method utilises the base vessel layout and allocates instrument positions on a 'best guess' basis
(usually they are very close to the final position) and 'driving' package vendor terminations at edge of
skid. The suppliers we have found are not adverse to this approach as it does do a fair bit of design for
them.
THE 'LOST' TAGS
It is always a problem as to just where you pick up internal system tags and tags which do not appear
on the P&IDs. A convenient method of picking up these tags is to use a document called a Instrument
Line Diagram. The ILD is essentially a point list and can be in diagrammatic or data format.
This document however must be treated with great care in that it can become a monster if you are not
careful. Keep it as simple as possible, utilise it by all means as a tool for creating 'temporary P&IDs'
159/173
when package P&IDs are not available but ensure that the tagging system used does not cause
problems later.
CHECKING
It is absolutely essential that all documents produced are cross checked, to not check is false economy
as eventually the supplier will pick up errors and it takes significantly more effort at that time to rectify
them. Considerable cost overruns can result from poor cross checking.
THE COMBINED SAFETY SYSTEM
As mentioned previously the CSS is made up of two very distinct sections these being the Process/
Emergency Shutdown Systems and the Fire and Gas System.
The individual system and marshalling racks are segregated into PSD/ESD and F&G outstations within
the Field Equipment Rooms.
Typical Combined Safety systems are generally duplex (2 processors) or triplex (3 processors). The
reason for this is self explanatory as it would be impossible to achieve the desired levels of reliability or
availability with a single processor. The difference between Duplex and Triplex processors is a subject
which is outside the scope of this paper.
Generally the system is designed in accordance with the requirements of API RP14C "Recommended
Practice for Analysis, Design, Installation and testing of Basic Surface Safety Systems for offshore
Production Platforms" and the UK Health and Safety Executive document "Programmable Electronic
Systems in Safety Related Applications" which has a number of check sheets. These are very useful
indeed when adapted to suit your particular application.
These documents should be read extensively to ensure that requirements are met.
Other useful reference documents are "Defences against common mode failures in redundancy
systems" which has been published by the U.K Safety and Reliability Directorate and also the UK Dept
of Energy publication "Guidance notes for Emergency Shutdown Systems".
IEC 61508 Programmable Electronic safety Systems in draft.
Further references can be found in the "Useful References" section at the end of this paper.
Many Applications use standard PLCs for safety related services, these units are not suitable for this
role as they do not have adequate diagnostics and also being very user friendly are too easily
reconfigured by unqualified personnel.
DESIGN DOCUMENTS
The CSS utilises several documents to develop the necessary logic these being:-
PLATFORM SHUTDOWN PHILOSOPHY - this is the most important document associated with the
Combined safety System in that it lays down the philosophy applicable to it. In this document are listed
the hierarchical shutdowns. One must not lose sight of the fact that although the system has the ability
to implement very critical shutdown features it also implements less critical unit and process
Shutdowns.
In offshore platforms the usual stages of shutdown are as follows:-
a. UNIT SHUTDOWN - this, the lowest level of shutdown, causes the individual units to stop.
160/173
b. PROCESS TRAIN SHUTDOWN - an individual Process Train will shutdown on occurrence of
any applicable trip.
c. PROCESS SHUTDOWN - on this occurrence the complete process stops but utilities remain
running, in effect it is a process 'stop' with NO BLOWDOWN in order to facilitate a easier startup on
rectification of the problem.
d. EMERGENCY SHUTDOWN - This action results generally from fire or Gas being sensed on
the platform, obviously a fire in the Galley or in a room in the accommodation does not cause a ESD but
more serious events in the Process, Wellhead or other critical areas will result in an ESD. An ESD is
actually a Process Shutdown with Blowdown and isolation of the platform trunkline. The blowdown
results in flaring of the gas component of the platform inventory whilst the liquid component is
maintained within the various process vessels. When co-incident fire detection in the process or
wellhead areas occurs one of the two strategically placed firepumps start and deluge occurs
automatically.
On some platforms main power is shutdown and the emergency generator starts when an ESD occurs
whilst on others main power is maintained by the generators switching to Diesel except when there is
fire in a critical area such as the wellheads. This approach is advocated in that maintaining lighting
ensures that at night the firefighting crew can see what they are doing.
e. TOTAL PLATFORM SHUTDOWN - This shutdown hopefully will never require operation
during the life of the platform since it usually is the result of abandonment. There are generally only two
or three TPSD pushbuttons which are under the control of the Platform Operations Manager. The result
of this action is total blackout of the platform including isolation of batteries except for some navaids
which continue to run. The intent of this shutdown is to maintain some battery power for when the 'black
start team' reboard the platform.
Other documents used in the development of the CSS configuration are as follows:-
I/O SCHEDULES - these detail the fundamental configuration such as tag number, IS or NIS, alarm
limits, analogue ranges etc.
PSD/ESD CAUSE AND EFFECTS - these documents which are based on the Process Cause and
Effects are used by the CSS supplier as the basis for the logic. The usual appearance of them is to
have the cause on the lefthand side with the effect at the top with a 'X' matrix, however it is becoming
more standard to also include logic symbols on the drawing.
A typical cause and effect is detailed in Attachment 3.
FIRE AND GAS CAUSE AND EFFECTS - These documents are similar to the PSD/ESD C&E
described above except that they do not have logic symbols incorporated (matrix only).
The logic is developed by the vendor based on the above documentation on the CSS
CONFIGURATION PACKAGE. This package is deliberately separate from the executive software of the
system since it is very important that software previously developed is not corrupted in any way. After
completion the software is tested extensively before being included in the overall software package.
Great emphasis is placed on ensuring that the executive software cannot be accessed by unauthorised
personnel and once the system is operational the configuration package is usually located onshore.
MESSAGE LISTS/CABLE DATA SHEETS/ TERMINATION DRAWINGS - As previously described for

PCS.
When designing and specifying a CSS it is important to remember that it does have a fundamental
common mode failure point this being of course the software. It is all very well to have duplicated and
triplicated hardware but if there is a common software bug just what can be done to overcome the
problem. Well the answer is that the requirements of API RP14C should be followed in that there should
161/173
be a primary and secondary safety system. Usually the primary being the electronic system and the
secondary, safety relief valves.
Where there is no possible alternative to having a single electronic system then it is absolutely
imperative that DUAL sets of software are used which have been written by DIFFERENT personnel.
Having to use this route has great disadvantages in that it is very complex, extremely costly and difficult
to maintain. The RULE is therefore - devise some form of secondary system.
PLANNING
Planning is a very critical component of any PCS/CSS design since if the planning is inadequate then
schedule and cost overruns will result. Generally PCS and CSS systems are the longest lead time items
and are therefore are on the critical path for platform design.
It is essential that in the early stages of design that a manufacturing plan is submitted by the Control
Systems supplier. This ensures that the fabrication, fitout and wiring schedule is maintained.
It is recommended therefore that considerable effort is included in the suppliers scope for the provision
of bargraphs and precedence networks, this effort must also be 'mirrored' by the consultant in the
checking and verification of adherence to the plan.
FACTORY ACCEPTANCE TESTING
After the supplier has completed his own factory testing the consultant/operator should conduct a very
comprehensive test. These tests should include at a minimum the following:-
a. HEAT SOAK TEST - this test should run over a period of a recommended 200 hours and
cycled between ambient and a upper value applicable to the maximum supplier specification.
b. POWER VARIATION TEST - this test should vary the input power between the lower and
upper voltage and frequency values as specified by the supplier.
c. 100% I/O TEST - Every I/O point should be checked for complete operation I/O card to
Controller to Graphics thence onto alarms etc.
d. SPECIAL APPLICATIONS, GLOBAL AND PROCESS UNIT FUNCTION TESTS-Extensive

testing of all special applications and all process/ global system functions.
e. FULL LOAD STRESS TEST - In order to ensure that the communications are adequate a full
load stress test is recommended. This test involves the switching and manipulation of large amounts of
data to load the communications link to ensure that it will operate under high stress conditions and not
'lock up'.
f. RETEST - Any modifications post FAT should be comprehensively tested.
CONCLUSION
There are many 'traps' to be avoided when involved in the selection, design, manufacture and testing of
any Control System. Hopefully by utilising some of the suggestions, methods and references suggested
in this paper some of these may be overcome.
USEFUL REFERENCES AND RELEVANT STANDARDS:
Petroleum Submerged Lands Acts (PSLA) Specific Requirements as to Offshore Petroleum Exploration
and Production -1985
162/173
API RP14C 'Recommended Practice for Analysis, Design, Installation and Testing of Basic Surface
Safety Systems for Offshore Production Platforms'
API RP14G 'Fire Prevention and Control on Open Type Offshore Production Platforms'.
AS 1211 'Reliability of Electronic Equipment and Components' - Parts 1,2 and 3.
AS 1670 'Automatic Fire Detection and alarm Systems, System Design, Installation and
Commissioning'.
AS 3563-1988 'Software Quality Management System'.
IEC SC65A ' Software and Hardware for Computers in the application of Industrial Safety Related
Systems'.
ISA RP60.3 - 1985 'Human Engineering for Control Centres'
ISA RP55-1 'Hardware Testing of Digital Process Computers'
MIL-HDBK-217E 'Reliability Prediction of Electronic Equipment'.
UK Health and Safety Executive 'Programmable Electronic Systems in Safety Related Applications'.
UK Safety and Reliability Directorate ' Defences against Common mode Failures in redundancy
systems'
UK Safety and Reliability Directorate 'Reduction of Human Error in Process Operation'.
UK Department of Energy "Guidance notes for Emergency Shutdown Systems'
J.A.(Jim) Russell I.ENG MIICA is at present Lead Controls Engineer with Davy McKee McDermott who
are contracted by Woodside Offshore Petroleum to complete the topsides design of the Goodwyn 'A'
Platform which is to be installed on the Northwest Shelf. Jim's design responsibilities include the
Platform Process Control and Combined Safety Systems and Instrumentation and Control associated
with packages. He has been associated with Instrumentation and Control for his whole working life
having previously worked with ESSO Fawley UK, Impala Platinum South Africa, British Gas, Worley
Engineering (Design of North Rankin A) and West Australian Petroleum.
6.2 Industrial best practices of conceptual process design

G.J. Harmsen∗
Shell Research and Technology Amsterdam, P.O. Box 38000, 1030 BN Amsterdam, The Netherlands
Received 4 August 2002; received in revised form 24 January 2003; accepted 5 February 2003
Abstract
The chemical process industry aims particularly at energy, capital expenditure and variable feedstock
cost savings due to fierce global competition, the Kyoto Protocol and requirements for sustainable
development. Increasingly conceptual process design methods are used in the industry to achieve
these aims. They are used in:
• existing processes to renew parts;
• process re-designs based on existing feed stocks and catalysts;
• innovative processes (new feed stocks, new catalysts, new process routes, new multifunctional
equipment).
This article is focused on the best industrial conceptual design practices applied for these application
areas. To this end we have reviewed methods, which are used in the chemical process industry in the
last 15 years. Capital, energy and variable cost savings are indicated for each method. Specific
attention is paid to:
• functional integration to multi-functional equipment;
163/173
• heuristic based selection of unit operations and recycle structure;
• superstructure based design optimization with mixed-integer-non-linear programming (MINLP).
1. Introduction
This article describes the industrial best practices of conceptual process design as publicised in the
open literature over the last 15 years. In view of the Kyoto Protocol and the requirements for sustain
able development energy savings become more and more important for the process designer
[1]. To stay competitive in the global market capital and operating cost savings are needed. This is why
this article focuses particularly at industrially applied design methods resulting in new designs with
savings of energy, capital expenditure and feedstock cost compared to old processes.
Any design contains the steps:
• problem definition,
• synthesis of solutions,
• analysis of solutions,
• evaluation,
• reporting.
This article focuses on methods for the synthesis of promising solutions, as this step has a large impact
on the development and design of novel process designs and several methods for this step have been
developed recently, while in the past little to nothing was available. Where available, commercial scale
novel processes resulting from the new design methods are reported, with resulting savings on energy,
capital expenditure and feedstock cost. Because of the industrial scope of this article many methods
reported by academic researchers are not mentioned. This is no implicit negative judgement on those
methods. Several of those methods are probably applied in the process industry but are not publicised
so far and could therefore not be included in this article.
2. Basic principle for energy savings in combination with capital expenditure reduction
Before we start to describe conceptual process design it is useful to explain the basis principle of
energy requirements for any chemical process. The basic principle to save on requirements of high
quality energy carriers (fossil fuels, solar energy) follows from thermodynamics. All process steps are
carried out in a finite time and are therefore irreversible, by which high quality energy is converted to
lower quality energy. This is defined as exergy loss. By reducing the irreversibility of the process this
exergy loss can be reduced [2].
This reduction in irreversibility can be achieved by combining process functions in one process step, by
selecting the best unit operations with their recycle structure, by heat integration, and by variable
optimization; spreading the irreversibility evenly over the process [2]. Often the exergy loss reduction
also results in lower capital expenditure cost due to number of steps reduction [3].
3. Conceptual process design position in the life cycle

From Siirola, Eastman Chemicals Company [4], Kaibel, BASF [5] and the authors experience in Shell a
general picture of all life cycle steps of industrial projects could be compiled as shown in Table 1. The
steps chemical route synthesis, conceptual design and process development are sometimes carried out
con-currently. As more information becomes available from the development experiments the
conceptual design becomes better defined. A sketch of an industrial method for this combination of
these steps is given by Siirola [4]. A detailed publicised method is however lacking for this combination
of chemical route synthesis, process design and process development in industry. In the remaining part
of this article, we will therefore concentrate on conceptual process design methods, etc. Some generic
steps in process development will also be briefly discussed at the end of this article.
Before we describe the elements of conceptual design shown in Table 2, it may be useful for clarity to
explain two other terms used in the literature for conceptual process design. The first term to explain
is process synthesis. In 1972, AIChE organised for the first time a meeting devoted to process
synthesis [6]. Since then more and more companies are using it and now some consensus in industry
is reached about the definition of the term. According to Siirola of Eastman Chemical Company,
process synthesis is the invention of chemical process designs [4]. To cite him: “It involves the
generation of alternatives in all process engineering steps within the innovation process. There is
some overlap with the preceding chemistry stage and the subsequent basic engineering stage. The
goal is to develop a flow scheme”. According to O’Young, Mitsubishi Chemical Corporation it is
distinguished from the subsequent steps modelling and optimization [7]. It is to be noted however,
that superstructure optimisation is part of process synthesis [6]. Hence, process synthesis can be
seen as the second step in modern conceptual process design. Process Intensification is a term that
is becoming prominent in publications. A definition is given by Stankiewicz,
164/173
Table 1
Overview of all steps to commercial operation and end of life
Life cycle step Involves
Chemical route synthesis Development of chemical synthesis steps
Selection of best chemical synthesis steps
Conceptual process design Function integration
Heuristic selecting unit operations and
recycle structure
Superstructure optimisation
Process development Experiments for kinetic, physical data
Reaction and separateion tests
Pilot plant
Cold flow scale-up tests
Process engineering Definition of all equipment and control
for accurate economic evaluation
Site integration Connect energy and mass flows with
other processes and utilities
Detailed engineering Definition of all process details to allow
purchasing and construction
Plant operation
Deconstruct and reuse parts End of life Find second use
Table 2
Functions in conceptual process design
Function Example
Molecular identity change Chemical reaction
Amount change Add component
Composition change Separate, mix
Phase change Evaporate
Temperature change Cool
Pressure change Pumping
Form change Extrusion
DSM [8]: “Process intensification consists of the development of novel apparatuses and techniques
that compared to commonly used today are expected to bring dramatic improvements in
manufacturing and processing, substantially decreasing equipment–size/production–capacity ratio,
energy consumption or waste production and ultimately resulting in cheaper, sustainable
technologies”. He distinguishes between process intensification equipment and process
intensification methods. The methods contain multifunctional.reactors, hybrid separations alternative
energy sources and other methods. He provides however no generic design method. From
Stankiewicz description, it can be concluded that process intensification is not a conceptual design
method,
4. Conceptual process design by function-integration

The conceptual process design can start with defining functions (tasks) and integrating these into a
process design containing novel process units. Siirola, Eastman Chemicals Corporation describes his
method in general terms with the following functions most common to the chemical process industry
[4].
After the functions have been synthesised. The functions are combined as much as possible by
shifting to common pressure and temperature ranges. After this a set of multi-functional equipment
can be defined. He explains the method with the design of the methyl acetate process as an example
[9,10]. A conventional process would consist of 11 different process steps. By designing first in
functions the problem could be reduced to six steps, which could be combined in one column. This
design is factor 5 lower in energy requirements and capital expenditure [4].
165/173
In the authors experience only very experienced process designers can understand and work with
Siirola’s method and no other publication has been found of industrial use of his method. The
advantage of designing by functions and combinations of functions is that the freedom of action is
large. This enhances creativity and increases the number of attractive process alternatives. Functions
operating at the same temperature and pressure range can be combined in one piece of equipment.
In this way capital expenditure and exergy losses are often reduced.
Many cases of function-integrated novel commercial processes or process steps are available in the
open literature. Green gives an overview of commercially applied types of process intensifications
[11]. Stankiewicz reports also several types of industrial applications [8]. The energy and capital
expenditure savings range between 20 and 80% [4,12,13]. A major sub-class of multi-functional
design in the industry is reactive distillation [14–16]. CDTECH alone reports 79 commercial processes
on reactive distillation, of which 60 ether units, 15 selective hydrogenation units and 4 aromatic
alkylation units [14]. For reactive distillation many conceptual design methods are available. For the
industry, the method of Schoenmakers, BASF, is most useful as it does also include non equilibrium
and non-azeotropic systems like hydrogenations [17]. Multi-functional reactors is an other sub-class.
Dautzenberg, ABB Lumus provides us with many industrial examples [18]. For multi-functional
reactors however no generic industrially applied conceptual design method is yet available [3].
Dividing wall column distillations is also an important sub-class. It combines both separation and
thermal coupling. BASF alone reports 30 columns in commercial operation [5]. Typical energy savings
over conventional column systems are around 30% [5]. The field of conceptual design methods for
reactive separation is under rapid development and methods are emerging, see Schembecker,
Process Design Center [19], so widening the scope of applicability of multi-functional design in the
industry.
The resulting novel multifunctional process steps require in general a large development effort as all
knowledge for design and scale-up of the novel unit operations has to be developed. So this type of
design is only selected if large improvements in a design are needed. At the end of this article a
development path for novel processes is outlined. If the time is lacking for radically new designs other
conceptual design methods can be applied as described in the next sections.
5. Conceptual process design by heuristic selection of unit operations and recycle structure
Conceptual process design by heuristics is about the selection of the best unit operations, their
sequence and recycle structure [20]. An easy to use method is described by Douglas [20] and is used
in Shell training classes as a first introduction to conceptual process design. Especially the exercises
are well chosen for an industrial environment. The main disadvantage is that it is targeted at
economics, while other criteria like safety, health and environment are hardly addressed. A
comprehensive expert software system supporting conceptual process design is the software
package “PROSYN”.
An overview description is given by Schembecker et al. [21]. Special attention is given by PROSYN
on selection of reactors and separators. For reactor selection a specific software
module READPERT is available. It also can be used on its own [22,23]. PROSYN is used by BASF
[5], Shell [24] and others, often with the support of Process Design Centre [25]. The conceptual
design with PROSYN is in general carried out by a multi-discipline team, consisting of at least a
chemist and a chemical engineer [21,24]. The energy saving by process synthesis depends strongly
on the exothermicity of the reaction. For a strongly exothermic reaction the energy savings can be
100% [24]. The total cost savings by industrial applications of process synthesis range from 20 to
60% [24].
6. Superstructure optimisation by mixed integer non-linear programming (MINLP)

Conceptual process design by superstructure optimization contains five steps:
680 G.J. Harmsen / Chemical Engineering and Processing 43 (2004) 677–681
• All conceivable unit operations are generated using the creativity of the process engineer [5].
• All individual units are connected in all possible ways into a so-called superstructure.
• A large mathematical model is made for this superstructure, containing all components mass flow,
enthalpy flows, cost expressions for feed stocks, capital expenditure and fixed cost related to the
sizing of equipment.
• A cost optimisation function is defined together with all constraints of the variables.
• The optimum selection of equipment and conditions is determined by numerical optimization using
MINLP methods.
The method described by Seider et al. [26], Biegler et al. [27] and Floudas [28], is industrially applied
for optimizing existing processes [5,29] and for optimising a design resulting from a heuristic method
166/173
[24]. For these cases a small design section is optimised with a few alternative options. So far the
industrial does not apply the method for generating completely new process designs [5]. This is due
to the complexity of the models, the time needed to set up the models with their equations and the
large size of the numerical optimisation problems.
7. Development plan for novel processes or process steps

The development effort for a novel process or a novel process step is in general considerable. The
following industrial development programme could be compiled from descriptions by Siirola, Eastman
Chemicals Corporation [4], Kaibel, BASF [5], and the experience of the author in Shell.
1. First make a first scouting conceptual design. This design is to evaluate the feasibility, safety,
health, environment, sustainability, product quality, and economy aspects. It also is used to estimate
the development effort required in knowledge, time and money and the risk of failure.
2. Determine the physical and chemical properties, crude required for the design, and some proof of
principle experiments.
3. Make a second conceptual design for the commercial scale plant and a downscaled pilot plant.
Based on these designs and costing a decision is taken to continue with constructing and operating
the pilot plant. If scale-up effects on certain phenomena, like mass transfer, or mixing are not
sufficiently known a computational fluid dynamics model will be developed and a so-called cold flow
large scale experimental model will be designed and operated to validate the CFD model.
4. Operate the pilot plant.
5. Design the commercial plant based on the pilot plant findings.
8. Conclusions and recommendation

Conceptual process design methods are applied successfully in the industry to obtain processes at
lower cost and energy requirements. The largest savings in capital expenditure and energy
requirements are obtained by function integration methods resulting in processes with novel unit
operations. Further research in design methods and simulation tools are required to increase the
number of application areas for function integration.
References
[1] G.J. Harmsen, Sustainable process design, in: Proceedings on Environmental Performance
Indicators in Process Design and Operation, EFCE Event 616, Delft University Press, 1999.
[2] E. Sauar, Energy efficient process design by equipartion of forces: with applications to distillation
and chemical reaction, Ph.D. thesis, Norwegian Technical-Natural Science University of Trondheim,
1998.
[3] G.J. Harmsen, L. Chewter, Industrial applications of multi-functional, multi-phase reactors, in:
Proceedings of the International Symposium on Multi-functional Reactors I, Amsterdam, 26–28 April
1999, Chem. Eng. Sci. 54 (1991) 1541–1545.
[4] J.J. Siirola, Industrial applications of chemical process synthesis, in: J.L. Anderson (Ed.),
Advances in Chemical Engineering: Process Synthesis, vol. 23, Academic Press, New York, 1996.
[5] G. Kaibel, H. Schoenmakers, Process synthesis and design in industrial practice, in: J. Grievink, J.
Van Schijndel (Eds.), Proceedings of the European Symposium on Computer-Aided Process
Engineering (CAPE-12), Elsevier, Amsterdam, 2002, pp. 9–22.
[6] W.R. John, Process Synthesis: Poised for a Wider Role, CEP, April 2001, pp. 59–65.
[7] D. Lionel O’Young, Y. Natori, Process synthesis: technology, environment and applications,
Comput. Chem. Eng. 20 (Suppl.) (1996) S381–S387.
[8] A.J. Stankiewicz, J.A. Moulijn, Process intensification: transforming
chemical engineering, Chem. Eng. Progress January (2000) 22–34.
[9] J.J. Siirola, Synthesis of equipment with integrated functionality, in: Syllabus First Dutch Process
Intensification: Profits for the Chemical Industry Symposium, 7 May 1998, November 1998.
[10] J.J. Siirola, An industrial perspective on process synthesis, in: Proceedings of the 4th
International Conference on Foundations CAPE, AIChE Symp. Ser. 91 (304) (1991) 22–233.
[11] A. Green, in: Proceedings of the 3rd International Conference on Process Intensification for the
Chemical Industry, BHR Publication 38, London, 1999.
[12] G.J. Harmsen, A.P. Hinderink, We want less: process intensification by process synthesis
methods, in: A. Green (Ed.), Proceedings of the 3rd International Conference on Process
Intensification for the Chemical Industry, Antwerpen, 25–27 October 1999, Prof. Eng. Publ. Ltd.,
London, 1999.
167/173
[13] G. Jan Harmsen, G. Korevaar, S.M. Lemkowitz, Process intensification contributions to
sustainable development, in: A. Stankiewicz (Ed.), Re-engineering the Chemical Processing Plant,
2003, in press.
[14] K.L. Lock, Selective hydrogenation of MAPD via catalytic distillation, in: ERTC Petrochemical
Paper Conference, Amsterdam, 20–22 February 2002, p. 7.
G.J. Harmsen / Chemical Engineering and Processing 43 (2004) 677–681 681
[15] M.M. Sharma, S.M. Mahajani, Industrial applications of reactive distillation, in: Proceedings of the
1st Ont. Workshop on Reactive Distillation, Magdeburg, Germany, 2–3 July 2001.
[16] A. Stankiewicz, Reactive separations for process intensification: an industrial perspective, Chem.
Eng. Process. 42 (2003) 137–144.
[17] H.G. Schoenmakers, B. Bessling, Reactive and catalytic distillation from an industrial
perspective, Chem. Eng. Process. 42 (2003) 145–155.
[18] F.M. Dautzenberg, M. Mukherjee, Process intensification using multifunctional
reactors, Chem. Eng. Sci. 56 (2) (2001) 251–268.
[19] G. Schembecker, S. Tlatlik, Process synthesis for reactive separations,
Chem. Eng. Process. 42 (2003) 179–190.
[20] J.M. Douglas, Conceptual Design of Chemical Processes,McGraw-Hill, New York, 1988.
[21] G. Schembecker, K.H. Simmrock, A. Wolff, Synthesis of chemical process flowsheets by means
of cooperating knowledge integrating systems, in: Escape 4, IChE Symposium Series no. 133, 1994.
[22] G.J. Harmsen, H. Van Hulst, Reactor selection methodology, in: CAPE Symposium on Process
Synthesis Art and Application, Amsterdam, 3 February 1998.
[23] G. Schembecker, Th. Dröge, U. Westhaus, K.H. Simmrock, READPERT—development,
selection and design of chemical reactors, Chem. Eng. Proc. 34 (1995) 317–322.
[24] G.J. Harmsen, et al., Industrially applied process synthesis method creates synergy between
economy and sustainability, in: Proceedings Conference FOCAPD99, Breckenridge, USA, 19–23 July
1999.
[25] H. Keuken, Process Design Centre, Breda, The Netherlands, email Input voor VNCI best
practical means conceptual design”, 8 September2000.
[26] W.D. Seider, et al., Process Design Principles, Wiley, New York, 1999.
[27] T. Biegler, I.E. Grossmann, A.W. Westerberg, Systematic Methods of Chemical Process Design,
Prentice-Hall, Upper Saddle River, NJ,1997.
[28] C.A. Floudas, Nonlinear and Mixed-Integer Optimization Fundamentals and Applications, Oxford
University Press, Oxford, 1995.
[29] J. Van Schijndel, E.N. Pistikopoulos, Towards the integration of process design, process control
and process operability—current status and future trends, in: Proceedings Conference FOCAPD99,
Breckenridge,
6.3 USA, 19–23 July 1999.Functional design of spacecraft
The first step in S/C design is to decide on the function(s) it has to fulfil. Typical functions are:
 Protect payload from the environment

 Provide supporting structure to payload and other parts of the vehicle (when needed);
structural integrity
 Fix vehicle to launcher
 Determine attitude and rotational rate of vehicle
 Determine position and trajectory/heading (orbit) of vehicle
 Adjust/control orbit/flight and attitude of vehicle
 Provide communications with ground and vice versa
 Provide command and data handling (the brains)
 Control temperature of payload and the other parts of the vehicle
 Provide electric power to the payload and the other parts of the vehicle
 Protect payload from electric power surges, etc.
 Perform vehicle destruct
 Perform separation
 Provide life support
168/173
Once we have decided on the functions, we can decide on what element(s) of the vehicle is (are) to
provide for this function. As in the beginning not much of the design of a vehicle is known, we like to
refer to these elements as subsystems of the vehicle. A subsystem generally incorporates all the
hard- and software necessary to fulfil the stated functions.
The table below gives an overview of a traditional division of S/C functions over the
vehicle subsystems as well as their naming.
Table 1: Traditional spacecraft subsystems [Source: "Space Mission Analysis and Design", by
Larson & Wertz]
Principal functions Subsystem Other names
Adjust orbit and attitude Propulsion Reaction Control System (RCS)

Manage angular momentum
Guidance, Navigation &

Orbit determination and control Orbit Control System (OCS)
Control (GNC)
Attitude Determination & Attitude Determination and Control

Attitude determination and
Control (ADCS) System (ADCS) or
control, Spacecraft pointing
Control System
Ground communication Communications Tracking, Telemetry, Command

Spacecraft tracking (TT&C)
Command processing Command & Data Handling Spacecraft Computer Syste,

Data processing/formatting (C&DH) Spacecraft Processor
Thermal Environmental Control System

Equipment temperature control
Power Electric Power Subsystem (EPS)

Power generation/distribution
Support structure, Launcher Structures & Mechanisms Structure Subsystem

adapter, Articulation,
Separation
The next step is to determine the interrelationships between the various subsystems. These can be
shown in a functional block diagram. See below for a simplified example [source "Elements of
spacecraft design", by C.D. Brown].
169/173
Fig.: S/C functional block diagram1
1) Functional flow diagrams are block diagrams which illustrate the relationships between different functions. Usually, these functions are expressed by a "noun-
verb-number" combination, in order to identify each function and the sequences within the process.
A Dictionary of Computing | 2004 | JOHN DAINTITH | 331 words | Copyright

functional design A design method in which the system is seen from the functional viewpoint. The
design concentrates on isolating high-level functions that can then be decomposed into and
synthesized from lower-level functions. Development proceeeds as a series of stepwise refinements
of functionality. Compare data-driven design.
170/173
6.4.The term Life Cycle comes from the IT industry and has been taken up by the Control
Systems suppliers, however there way it is applied in automation is often quite different from that in
other software. In general automation is not about inventing anything new, it is generally more a
matter of adapting pre-established system designs to a new plant.
Specifications and Testing are linked so you should write your specification thinking about how you
know that it has been attained.
The diagram below is based in the GAMP Life Cycle used by the pharmaceutical industry
Click on an area to go to the topic.
The stage at which the supplier, in conjunction with the user, develops the Functional Specification,
showing what functions are to be provided to meet the user's requirements, stating what resources
will be required, and providing the agreed basis of the system design.
A Functional Design Specification (FDS) details the solution to be provided to meet the Users and
Functional Requirements. It should be approved by the User and should form the basis of the design
for both Hardware and Software.
All the functions, operator interactions control and sequencing associated for the prcoess automation
should be clearly detailed. This allows the User to confirm, before the system is developed that the
proposed solution fully meets the requirements.The FDS provides the basis of the design of the
system and is used to verify and validate the system during the testing, ensuring all the required
functions are present and that that they operate correctly.
The FDS should cover
Control Modules such as PID Loops, Indicators etc
HMI Graphic displays
Equipment Basic Control
Phase Logic
Operations
Unit Procedures
Recipes
The Inputs and Outputs of the systems with cards and channels assigned to them.
Much of the FDS may be references to standard system objects.

But beware, sometimes what are supposed to be standard turn out otherwise, and some 'standard
modules' turn out to be not what you really wanted.
171/173
6.5 Functional design WIKI
Functional design is a paradigm used to simplify the design of hardware and software devices such as
computer software and increasingly, 3D models. A functional design assures that each modular part of a
device has only one responsibility and performs that responsibility with the minimum of side effects on other
parts. Functionally-designed modules tend to have low coupling.
edit] Advantages
The advantage for implementation is that if a software module has a single purpose, it will be simpler, and
therefore easier and less expensive, to design and implement.Systems with functionally-designed parts are
easier to modify because each part does only what it claims to do.Since maintenance is more than 3/4 of a
successful system's life[1], this feature is a crucial advantage. It also makes the system easier to understand
and document, which simplifies training. The result is that the practical lifetime of a functional system is
longer.In a system of programs, a functional module will be easier to reuse because it is less likely to have
side effects that appear in other parts of the system.
[edit] Technique
The standard way to assure functional design is to review the description of a module. If the description
includes conjunctions such as "and" or "or", then the design has more than one responsibility, and is therefore
likely to have side effects. The responsibilities need to be divided into several modules in order to achieve a
functional design.
[edit] Critiques and limits
Every computer system has parts that cannot be functionally pure because they exist to distribute CPU cycles
or other resources to different modules. For example, most systems have an "initialization" section that starts
up the modules. Other well-known examples are the interrupt vector table and the main loop.
Some functions inherently have mixed semantics. For example, a function "move the car from the garage"
inherently has a side effect of changing the "car position". In some cases, the mixed semantics can extend
over a large topological tree or graph of related concepts. In these unusual cases, functional design is not
recommended by some authorities. Instead polymorphism, inheritance, or procedural methods may be
preferred.
[edit] Applied to 3D modeling and simulation
Recently several software companies have introduced functional design as a concept to describe a
Parametric feature based modeler for 3D modeling and simulation. In this context, they mean a parametric
model of an object where the parameters are tied to real-world design criteria, such as an axle that will adjust
its diameter based on the strength of the material and the amount of force being applied to it in the simulation.
It is hoped that this will create efficiencies in the design process for mechanical and perhaps even
architectural/structural assemblies by integrating the results of finite element analysis directly to the behavior
of individual objects.
[edit] Software
FunctionCAD is an open source application used for the visual representation of functional models.
172/173
Functional design
Design refers to the planning that is the foundation of making things. There are different design philosophies,
approaches, and methods. Design strikes a balance between a number of different components, and
depending on the situation, it can give more weight to one or another. For example, one might focus on
materials and ask what could be made with a certain collection of items, or one could focus on aesthetics and
try to imagine the most beautiful object to place in a certain setting. Functional design can refer to a focus on
function rather than aesthetics, a concern with objectives rather than components, or it can refer to the use of
a complete requirements document to guide development and testing or to a computer modeling technique. In
addition functional design is an integral part of functional design specification.
Most often, functional design is used to mean that the product’s functionality is taken into account in important
ways as it is imagined and built. For a product to end up being functional, both the end user and the client
need to be considered all the way through the design process. It may take some work to describe the target
audience accurately. The process of functional design begins with the goal of the product: a clear statement of
what it is supposed to do. This does not mean that what the client wants it to do is the only thing that the user
will, in fact do with it. It does need to do well what it was made to do.
Usually the end user is not represented directly in the functional design process, so his or her responses have
to be imagined. Designers must also imagine his or her ability to learn how to use the product, to integrate it
with other products he or she already has, or to adapt it to his or her unique circumstances, if it is the kind of
product that is meant to be personalized. Similarity of design to existing products and well-done
documentation can contribute to the end user’s experience; that is, thoughts about things that are not intrinsic
to the product itself can help the product to be more functional for the user than it would be otherwise. With
any product that has to be plugged in, a feedback system needs to be established. People are used to the
light that tells them that the vacuum is plugged in and the funny sound in their word processing software that
tells them that they’ve tried to do something that has no reasonable outcome. Part of functional design is
letting the user know that the product is or isn’t functioning. Furthermore, if something isn’t working or the user
attempted something that failed, a well-designed product will assist the user in getting things back on track.
Discuss the article
@empanadas - You should always have good lighting in any functional design whether you are designing an in house movie theater or
an office. It's a good idea to browse around office stores for furniture because they will often tell you what the special functions and
features are of that piece.
While Ergonomics is great and everything, the fact is that functionality goes all over your home as well. A lot of pieces coming out now a
days have what I like to call the "double duty factor." As an example, think of a storage ottoman in the living room: it hides your
magazines and the kid's toys, but it also provides more seating.
- lmorales
@empanadas - Surely. You can actually look it up online and find several different sites that will walk you through the reasons that you
should incorporate ergonomics in your home and/or office space. The entire ergonomics angle is that it will make you more productive
and give you the ability to be comfortable, which (if you ask me) goes hand in hand with productivity itself.
Basically you should incorporate an eye level computer monitor, a comfortable chair where your thighs rest parallel to the ground when
flat footed and seated, a wrist rest for both your mouse pad and keyboard, and good lighting. These are just a few suggestions and
standards incorporated in the functional design of Ergonomics. Good luck! BelugaWhale
@BelugaWhale - I would like to make my current office design more functional. Do you have any recommendations and could you
elaborate on the entire "ergonomics" aspect please? - empanadas
Ergonomics is a great example of functional home design. It is actually a great example of office design as well. Ergonomics takes into
account (often times, but perhaps not ALWAYS) the comfort of the user as well as the ability of that user to not only properly perform, but
perform their functions well. For example, there are standard heights that a chair or counter top should be in order to be "comfortable"
and functional. You might also consider ADA standards to be a form of functional design as well.
- BelugaW
.
173/173

CCPP

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

CCPP

Caricato da

Copyright:

Formati disponibili

Functional design, objects, documents/drawings, design spec’s, coding and break down structures

Difference between process design and Functional design.

WHAT IS FUNCTIONAL ENGINEERING?

Functional engineering in the life cycle.

Functional engineering and CAPE OPEN

Functional engineering and OntoCAPE

Function drives form to redefine CAD.

Nov. 10, 2006

Bridging The Gap Between Form And Function

Harnessing The Power Of Digital Prototypes

Solving Complex Challenges

2.2 What is functional design?

Under the hood of a typical 3D modeler

The functional fix

Difference between process design and functional design.

FEED, Front End Engineering and Design and Functional Engineering

Functional Mechanical Engineering ) Functions and Functional drawings do exist, no

System Flow Diagrams should not include:

 Example - Process Flow Diagram

P&ID vs. PFD

A PFD for the process is here:

Image courtesy of John Trumble, University of Michigan

Process flow diagrams generally do not include:

Other items of interest

4.2 P&ID General Information

Image courtesy of John Trumble, University of Michigan

Retrieved from "http://controls.engin.umich.edu/wiki/index.php/PFD/PID_industry_example_Wiki_Page"

Das Diagramm enthält folgende Informationen:

 Art und Bezeichnung der Apparate und/ oder Maschinen

Zusatzinformationen können angegeben werden, z. B. Höhenlagen der Apparate, weitere Werkstoffe,

RI-Fließbild nach ISO Standard (R+I Schema)

Kennbuchstaben und Kennzeichnung

Mess- und Regelstellen

Beschreibung der Kürzel

Programme zur RI-Fließbild-Erstellung

Übersicht anzuwendender Normen

Stand: Februar 2010

 EN ISO 7200 (alt DIN 6771-1) Dokumentenschriftfeld

R&I-Fließbilder nach amerikanischem Standard

RI-Fließbild nach amerikanischem Standard

Unterschiede zur DIN

Instrumente werden nicht zusammengefasst dargestellt, sondern explizit nach Einzelfunktionen

Beispiel für eine Durchflussmessung mit Anzeige, Regelung und Aufzeichnung:

In technischen Zeichnungen internationaler Projekten kommt es oft zu vermischten Kennzeichnungen.

Kennzeichen-Aufbau nach ISA 5.1

Durchfluss-Übertragung von Regelkreis 1000A

 Regelkreis Nummer 1000

 PT 1000A Druckübertragung 1000A

The following information is given on a P&ID that is not explicit on a PFD:

 ALL valves and valve types

 Develop operational methodology

 Grouped by specific section of plant

What A P&ID Is Not

What A P&ID should include

 Revisions should be clearly identified

How do you generate a P&ID?

[Needs link to other page]

Retrieved from "http://controls.engin.umich.edu/wiki/index.php/PIDGeneralInformation"

HEAT EXCHANGER DATA SHEET

JOB NO.: REVISION:

SPECIFICATION NO.: ENGINEER:

Service: Equipment No.:

Manufacturer: No. Required:

Supplier: Applicable to: Model No.: