See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/37420771

The Concepts of IEC 61346 Applied to a Software Architecture for Automation

Article · January 2004

Source: OAI

CITATIONS READS
0 5,328

3 authors, including:

Rodrigo Garcia Esther Myriam Gelle

SEDUC-AM Helbling Technik AG
19 PUBLICATIONS 24 CITATIONS 39 PUBLICATIONS 430 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Esther Myriam Gelle on 31 May 2014.

The user has requested enhancement of the downloaded file.

The Concepts of IEC 61346 Applied to a Software
Architecture for Automation
Technical Report IC/2004/20

Rodrigo Garcı́a Garcı́a Esther Gelle Alfred Strohmeier

Software Engineering Laboratory Information Technologies Dept. Software Engineering Laboratory
Swiss Federal Institute of ABB Switzerland Ltd Swiss Federal Institute of
Technology Lausanne (EPFL) Corporate Research Technology Lausanne (EPFL)
Ecublens Segelhof 1 Ecublens
CH-1015 Lausanne, Switzerland CH-5405 Baden-Dättwil CH-1015 Lausanne, Switzerland
E-mail: [email protected] E-mail: [email protected] E-mail: [email protected]

Abstract
The IEC 61346 standard establishes general principles for structuring the information of technical systems. The present
document discusses the ideas shown in the standard, emphasizing the fact that some parts of it are ambiguous and can lead to
different interpretations of the basic concepts. Consequently, we derive a concrete interpretation of the standard that tries to remove
the ambiguities. We will apply this interpretation to the development of an industrial software platform for building automation
applications.
 1

The Concepts of IEC 61346 Applied to a Software

Architecture for Automation
Technical Report IC/2004/20

I. T HE S TANDARD IEC 61346 correct owner of the information. A reference designation

mechanism helps service engineers to identify the type and
A. Introduction
version of a specific occurrence and thus to provide the correct
The IEC 61346 standard [1][2][3][4] describes how to repair action with a fitting repair part. As a consequence,
structure the information relative to a technical system. It is the standard has to provide open-ended structuring principles.
based on the idea that a system can be seen from different An open-ended approach supports reuse of defined objects
points of view and that the objects in a system can be while maintaining their internal structure and designations. For
organized hierarchically according to these points of view. The example, a defined and documented water pumping system
standard defines three key concepts among others. These are from an industrial plant could be reused in a power plant if the
object, aspect and structure. It employs these concepts and requirements on both subsystems are similar. One just would
a special notation to build up a reference designation system have to concatenate the defined system with the structure of
that identifies each object in a system. the power plant. Note that such a reuse is not possible in the
A standardized description of a technical system such as a common power station designation system KKS (German for
plant is useful in the context of large one-of-a-kind system Kraftwerks-Kennzeichen-System [6]) for power plants, which
projects where several integrators are involved. It supports a defines absolute levels and has a fixed designation structure.
common understanding of the system itself and provides a Using KKS it is not possible to reuse the water pumping
basis on which integrators can discuss their proposed solutions. system from an industrial plant (where KKS is not applied)
A common understanding of the technical concepts in turn in a power plant, even if they would happen to be technically
eases integration of parts coming from different industries and identical. The documentation would have to be re-done and the
it lays the grounds for standardized data exchange. Implicitly designations would have to be changed. Like IEC 61346, KKS
this requires the standard to be highly flexible in order to defines a reference designation system for uniquely identifying
accommodate the description of a technical system under equipment in a power plant. KKS defines three aspects for each
various aspects and viewpoints. From many industries the object in a plant: the process related, the point of installation,
need for a flexible support during engineering, operation and and the location designation. As stated, KKS defines absolute
maintenance has been pronounced. In the following, we often codes, i.e. the function codes describing process related aspects
refer to the example of a plant as a highly complex technical are fixed, A standing for Grid and Distribution Systems, B for
system. In the engineering phase, the standard should help Power Transmission, etc.
to manage the complexity of a technical system such as a
plant in a top-down fashion. At the same time the result
B. Basic definitions of IEC 61346
of the engineering process should be the documentation of
the technical system. Engineers typically define and organize An object, as defined by the standard, is an entity treated
a technical system into subsystems and components before in the process of design, engineering, realization, operation,
knowing their implementation. That is, functional modules maintenance and demolition. We can summarize this definition
are identified in the process, which later may be reused. The by saying that an object is an entity of interest in the life-cycle
order fulfillment of a plant includes more than just product- of a technical system.
oriented information, namely information on function but also An aspect is defined as a specific way of selecting informa-
on location of the various parts. Engineers have a need to tion on or describing a system or an object of a system (where
switch between different types of information or structures that a system is a set of interrelated objects). We can then see an
describe the different views or aspects of the system during aspect as a particular view of a system or object.
engineering, installation and commissioning. In the process- Structures are a way to organize the objects of a system by
ing of plant orders typically function, location and product- constituency relationships. Each structure is built around a par-
oriented information has to be managed simultaneously. In this ticular aspect or view of the objects that compose the system.
context it is nevertheless important to maintain consistency The standard considers three types of aspects in particular,
between the various views. In the operation and maintenance yielding three corresponding structures: the function-oriented
phase of a plant, the distinction between occurrences, types structure, the product-oriented structure and the location-
and individuals is important [5]. It must be possible to oriented structure. The standard allows for concrete imple-
retrieve and log operational information and attribute it to mentations to consider different aspects suitable for a specific
the correct occurrence and eventually also assign it to the technical field and to define the corresponding additional
 2

Structure
tion to cross structure boundaries. Each identifier is composed
of a prefix, a letter code and a number code. Prefixes are
established for the functional (=, equal sign), the product
(-, minus sign) and the location (+, plus sign) structures.
Function−oriented Product−oriented Location−oriented For an extended discussion about reference designations, see
Structure Structure Structure section 5 of IEC 61346-1. Starter =W2M1Q1 is an example
of a reference designation in Fig. 3.
Fig. 1. The three structures defined in IEC 61346.
II. I MPORTANT CONCEPTS AND THEIR LIMITATIONS
Function−oriented Product−oriented
Structure Structure A. The Definition of Object
Emit signalling light Light system In an additional note, the standard explains that the entity
=Q1 Turn light on −B1 Push button mentioned in the definition of object may refer to a physical or
=Q2 Turn light off −L1 Bulb non-physical “thing” or to a set of information associated with
=L1 Shed light −G1 Battery
it. In our opinion, this definition is too vague. The standard
aims at a wide variety of technical systems so it seeks for
=G1 Generate power −W1 Wire
generality in its definitions. However, this particular definition
=W1 Carry power
suffers from a recursion problem. According to it, an entity can
be a set of information related to itself. Conceptually, this is
clearly a circular definition. The set of information associated
−B1 to an entity is not the same thing as the entity itself. The
+
−L1 representation of an object or the information related to an
−G1
− object should not be confounded with the real-world object it
−W1
represents.
In an additional note to the definition of system (see note 2
Fig. 2. Two views of a simple lighting system using structuring. in section 3.2 of IEC 61346-1), it is said that a system that is
part of another can be considered as an object. From this note,
it seems that subsystems and objects are interchangeable, so
structures, but it only describes the three already mentioned maybe there is no need of two separate concepts. In any case,
(see Fig. 1). we consider that the definition of system is useful to clearly
Structures are graphically represented as trees, where the state that one is talking about a group (or set) of objects.
nodes of the tree that are up in the hierarchy are constituted
by their children nodes. In Fig. 2, we see an example of a
simple lighting system on which structuring has been applied. B. Content of the Structures
In this simple case, we have a one to one mapping between The standard tries to clarify from the beginning what are the
the two aspects of most objects: Shed light goes with Bulb, elements that the structures should hold. The examples shown
Generate power goes with Battery and Carry power goes with in the different parts of the standard exhibit however disparate
Wire. However, even in this simple example, there is a case criteria for choosing the nature of the nodes that compose the
of a two to one mapping. In effect, the product Push button tree-like structures.
performs two system functions, namely Turn light on and Turn The question is whether it is the aspects (views) of the
light off. In general, there is a many to many mapping among objects which should be represented in the structures or
the aspects in the strucures. whether the objects themselves should be the components of
Contrary to views in other notations, the graphical repre- a structure. In the former case, each structure would hold the
sentation of each one of the three structures is the same. In aspects that correspond to it (i.e. a function-oriented structure
UML [7], for instance, different symbols and artifacts are used would hold function names). This option is supported by
in the construction of the static view, the physical view or section 4.5 of IEC 61346-1, where it is said that an aspect
the use case view. In a standard about system architectures, of an object can be described in terms of the same aspect of
the IEEE 1417 [8], the architectural description of a system other objects. In the latter case, objects should be organized in
is also composed of different views. A view in IEEE 1417 the structure according to a particular aspect (i.e. an object in
shows a system from the perspective of a set of concerns a location-oriented structure would contain the objects that
(areas of interest). A viewpoint specifies the set of conventions are placed inside it). This latter interpretation works well
and artifacts used to develop an individual view. The standard with product-oriented and location-oriented structures, but not
IEEE 1417 provides us with the basis to build our own views with function-oriented structures. It is conceptually difficult
of a system. In IEC 61346, all the views use tree-like structures to think that an object can be constituent of another object
showing constituency relations. functionally. It is even more difficult if the function names are
The reference designation of an object is built by concate- not shown explicitly. Some examples in the standard follow
nating the identifiers of its parent elements in the structures. the first option whilst others use the second. There are even
Transitions among the structures allow the reference designa- some examples which mix the two options altogether.
 3

=W2 Conveyor belt function Structure IEC 61346-1 IEC 61346-3

Function-oriented Functional aspect Object based on
=W1 Conveyor belt of an object task or activities
=B1 Conveyor belt monitor Product-oriented Product aspect Object based on
of an object equipment or devices
=M1 Motor drive
Location-oriented Location aspect Object based on
=Q1 Starter of an object locations
Note: The examples shown in IEC 61346-1 do not conform to its interpretation.
=S1 Local control
=M1 Motor TABLE I
=S2 Safety switch I NTERPRETATION OF THE ELEMENTS IN THE STRUCTURES .
=S3 Emergency stop

Fig. 3. Extract from Figure D.3 of IEC 61346-1.

category of objects. In that case, it is the name of
the task which is shown.
The most prominent example of confusion due to these two 2) Product-oriented structure.
ways of interpreting the contents of the structures is made In the product-oriented structure there is no signif-
explicit in figure D.3 of IEC 61346-1. In this figure (see icant difference if the elements of the structure are
extract in Fig. 3), we see the functional decomposition of a aspects or objects. They represent a product in any
material-handling plant. This function-oriented structure holds, case.
at the same time, the two types of structure elements we 3) Location-oriented structure.
have seen: in the figure we can see a Conveyor belt function Aspects: The location is the the name of the place
(functional aspect) and a Conveyor belt (physical object). or the coordinates where the object of interest is
Moreover, the figure is not only mixing the two kinds of located.
elements, but it is also following a convention for naming Objects: The object is important because it deter-
the elements in the function-oriented structure that is against mines a well defined space in the technical system,
the recommendations of the standard itself. Indeed, there is an so it is placed in the location structure.
example for naming objects according to the function aspect
The possible misunderstandings are, in fact, recognized
in section 5.4.1 of IEC 61346-3, where it is recommended
by the standard itself. A revealing note in section A.1 of
to use “object for transporting from place A to B” instead
IEC 61346-3 (Annex A) states that both the object and the
of “conveyor belt”. The advantage of this convention is
aspect of an object are often described with the same terms
that, in this way, the function aspect is not attached to a
of function, product and location. This can sometimes lead to
concrete product implementation, but it is exactly the opposite
confusion.
of what we find in the figure of IEC 61346-1. However,
even if IEC 61346-3 recommends this advantageous naming
convention, it promotes at the same time the use of objects to C. Transitions
populate the structures. It talks about objects based on tasks
An important part of the standard is the ability to relate
as the elements that compose the function-oriented structure.
elements of the different structures. One can navigate from
This adds more confusion to what really are the elements of
one structure to another and thus designate an object by
the structures, whether they are either aspects or objects. means of different aspects. In principle, transitions seem the
The two different interpretations have a different impact on ideal mechanism that would allow the engineer to obtain the
each of the three types of structure that the standard proposes. products that are involved in the realization of a specific task
This is due to the diverse nature of the structures. Although or where they are located (see section 4.2 of IEC 61346-3).
the standard shows them as if they had a certain symmetry, However, the standard use transitions only as a method to
they cannot be always treated in the same way. Therefore, we build reference designations and not to show the relations
present a summary of the implications of choosing aspects or between structures. The relations are supposed to exist and
objects as the constituent elements of the structures (see also to be known (otherwise the transition would be impossible)
Table I). but they are not directly shown. A transition in IEC 61346
1) Function-oriented structure. goes from one aspect of an object to another aspect of the
Aspects: The functional aspect of an object is same object and then selects a child from the selected aspect
indeed a function (task or activity). The structures (see Fig. 4). Our interpretation of transitions differs. We do not
are thus populated with functions. The name of the select a child of the destination aspect, but rather the aspect
function is explicitly shown. itself is considered the target of the transition. In this way,
Objects: The object is placed in the functional we use transitions to get the relations among structures. See
structure because the activity it performs is impor- section III-A for details.
tant for the plant. The name of the object is shown The first part of the standard (IEC 61346-1) dedicates an
and the function it performs is implicit. A variant of extensive discussion to the way transitions should be done. Let
this option appears in IEC 61346-3, where it talks us recall that, in this first part, the structures are supposed to
about objects based on tasks, raising tasks to the hold the aspects of the objects. The discussion treats, among
 4

Product−oriented structure Function−oriented Product−oriented

structure structures

Pasteurize milk
Location−oriented structure Fill tank Plate heat exchager
Heat water
−A1 −A2
Inject steam
.
. Jacketed vat

+B1 +B2 .

−A2+B1 −A2+B2 Fig. 5. Dependencies between structures.

Fig. 4. Transitions as defined in the standard.

D. Limitations of Structures
Structures, as defined in IEC 61346 only show constituency
other issues, the case of transitions to a structure where an relations (see the definition of structure in section 3.6 of [1]).
object has different aspects. For instance, an object can be Transitions help to add more information by facilitating inter-
represented by one aspect in the product-oriented structure structure navigation. Still, there are other simple relations
and by two in the location-oriented structure. If a transition is among the elements of a function-oriented structure that
made from the product to the location-oriented structure, the cannot be expressed with structures. We are referring here
standard specifies how to unambiguously identify the concrete to relations of precedence among functions. The fact that a
representation in the location-oriented structure (see Fig. 9). function must be executed before another cannot be shown in
Part three of the standard (IEC 61346-3) only discusses a tree-like structure, which can only show the subfunctions.
transitions briefly in section 6. There, the principle of con- This kind of information has to be provided with additional
stituency used to build structures applies somehow to the documentation.
way transitions are done. For instance, a transition from the The structures do not take into account possible changes
function aspect to the product aspect is only possible if the in the location of objects (i.e. objects that move from one
product completely implements the function. This kind of place to another during system operation). The standard does
restriction is not stated in IEC 61346-1. In fact, this constraint not say anything about objects that can change its position
eliminates the possibility of having ambiguous transitions like in the system. The problem of how to model the products
the ones addressed by IEC 61346-1 (see again Fig. 9). It manufactured by the plant is related to this problem of
reduces the applicability of transitions to those objects that product displacement. Moreover, the products which are being
have a many-to-one mapping from one aspect to another. In elaborated in the plant are not finished products and they go
figure 12 of IEC 61346-3, where a transition is shown, it even through several phases during fabrication.
seems that the product aspect that completely implements a The interdependency of structures is another limitation that
function does not have to be a representation of the same is not treated in the standard. The standard seems to assume
object that is represented by the function aspect (it can be a that each one of the structures can be developed independently
higher-level object). This is in contradiction with IEC 61346- and that is not always true: structures are not completely
1, where transitions are supposed to occur between aspects orthogonal. The contents of one structure will usually impose
of the same object. Moreover, the standard does not take into some constraints in the contents of the others. It is often the
account that, if a product implements a function completely, case that if one specifies functions in great detail, the lowest
all its superproducts will implement that function as well (see level functions will be determined by the products used to
our proposed constituency rules in section III-B). As a conse- implement them. Let us see this with an example. Imagine
quence, a transition from the function-oriented to the product- that we have a plant for milk processing and we want to kill
oriented structure could reach any of those superproducts, as bacteria present in the milk with the help of pasteurization. We
long as the function and the product aspects do not have to have in our plant a pasteurizing vat, which consists of a tank
represent the same object 1 . We suppose that this is solved surrounded by circulating steam or hot water. The function
by not propagating the implementation of functions to the Pasteurize milk can then be decomposed into subfunctions
superproducts, but this point is not clarified in the standard. Fill tank, Heat water, Inject steam, etc. Imagine now, that we
decide to change the pasteurizing vat by a plate heat exchanger.
Contrary to our interpretation, the interrelations between
This device allows to pasteurize milk in a continuous way
structures that require a many-to-many mapping are not taken
and it is quicker than the vat. In this case, the main function
into account as transitions in IEC 61346. These relations are
(Pasteurize milk) will remain the same, but its subfunctions
supposed to be stored in a database in computer implementa-
(which depended on the use of a jacketed vat) will have to
tions of the standard (see again section A.3).
change.
The letter code system for reference designation shown in
1 We see here a consequence of the imprecise definition of object in the IEC 61346-2 has also one limitation. It classifies objects in
standard terms of their main functionality and assigns them a letter
 5

code according to this functionality. It also suggests possible we are limiting ourselves to a concrete field of application:
products that are suitable for performing the function. Thus, automation plants.
this approach is valid for the elements in the function-oriented Object: Real-world entity relevant to the operation of an
structure and even for those in the product-oriented structure, industrial plant.
but it is not adequate for the elements in the location-oriented Function: Activity performed by the objects in the plant.
structure. It would be good to have a better letter code Product: Information about the of an object in the plant.
assignment for the elements that specify locations. Location: Representation of a well delimited portion of
space in a plant.
III. I NTERPRETATION OF C ONCEPTS IN THE D OMAIN OF
As opposed to the standard, which considers objects treated
AUTOMATION
in the process of design, engineering, realization, operation,
As we have seen, the generality of the concept definitions in maintenance and demolition, we are only concerned with the
the standard and their multiple interpretations makes difficult objects which are important for the operation of the plant. It is
for an implementation to claim conformance (see [9]). Before up to the designer to decide which objects are relevant enough
going any further, we decided to clarify the concepts we were to put them in the plant model. It is important to note as well
going to use for our own implementation. that we admit both physical and non-physical objects (such as
Although we try to lose as little generality as possible, we software programs) in our definition of object. In any case,
are limiting ourselves to a field of application of the standard. they refer to entities that exist in the real-world and not to
The platform we are building is intended to model automation entities of a model.
plants, so we will impose some restrictions to the standard We think that, in natural language, a product is basically the
appropriate for this domain. For instance, in the construction same thing as an object. A possible difference is that a product
industry environment, rooms could be considered as products. is normally associated to something that can be purchased
For us, rooms will just be space delimiters, so they can only and typically identified by a serial number. For us, an object
be the location aspect of an object. can be a single product or logical assembly of products. In
The standard supposes a certain symmetry among the struc- the latter case, the object will not necessarily have an unique
tures it defines: they are all different views of the system. The serial number and it can be built by plant engineers rather than
function aspect, the product aspect or the location aspect of an purchased, but it is still a “logical product”. Because of this
object are not the object. They are just views of it. Although reason, we are thinking about the possibility of changing the
we agree up to some extent with this affirmation, we do not name of the product-oriented structure and call it component-
think that all three views can be equally related to a real- oriented structure or assembly-oriented structure. These names
world object. It is obvious that the product view has a much express better the real contents of the structure: not all the
closer relationship to the real object than the functional or the elements in the product-oriented structure have to be products
locational views. This is true up to the point that the two words but logical assemblies of products and parts of products. In
are usually interchangeable in natural language: an object (or this paper, we keep the term product in this general sense
product) implements a function and is placed somewhere. used by the standard. When we say that a product implements
We think that the terms used in IEC 61346-3 when it speaks a function, we are extracting a relation from our plant model
of objects based on tasks in order to refer to functional aspects, representing the fact that a real-world object is performing a
objects based on equipment in order to refer to products and certain activity. In this way, we avoid the confusion: we use the
objects based on spaces in order to refer to locations are an term product for the entities in the product-oriented structure
abuse of terminology (everything is an object). We also reject (model) and object for the real-world entities.
the idea of the object as a set of information, although when It is also important to note that many automation plants
we model it, we deal with information related to the object. generate manufactured objects as a result. When we talk about
We conceive the object as something real that has an identity objects, we do not refer to this kind of objects. They will not
by itself and we do not want to confuse an object with a be represented in the product-oriented structure since they do
representation of it (as we said in section II-A) or with a not participate in the plant operation but are the result of it.
conceptual idea that only lives in the mind of the engineer. This The figures related to the objects manufactured by a plant can
happens in section 5 of IEC 61346-4, for instance, where the be, however, important for management. Therefore, a software
life cycle of an object is described. The document discusses the platform based on the standard should provide support for
creation of an object motor 2 in the function-oriented structure handling these figures, but not within the product structure
during the design process. In our opinion, the object is not because that is not its purpose.
created, it is only the functional specification (a representation)
of the object. It seems that, in this case, the standard is not
making a clear distinction between objects in the model and A. Our Interpretation of Transitions
real-world objects. Transitions play a very important role in our interpretation
For all the reasons explained above, we propose to modify of the standard. They are not only useful for building reference
the definitions in the standard. Remember, however, that designations which include several structures, but also for
2 The name motor is used in IEC 61346-4 for designing an element in the
showing other inter-structure relations (e.g. show the products
function-oriented structure. As we have seen in section II-B, this is not a good that implement a function or the locations where products are
choice for the name of an element in that kind of structure. placed). Some parts of the IEC 61346 standard consider this
 6

Product−oriented structure always

Function−oriented Product−oriented Location−oriented

structure always structure always structure

Location−oriented structure
not always not always
−A1 −A2 +R2

not always

+B1 +B2
Fig. 7. Possible transitions between structures.
−A2+R2+B1 −A2+R2+B2

Fig. 6. The example of Fig. 4 with our interpretation of transitions. these transitions should always be possible as well.
A consequence of the asymmetry in our interpretation of
the standard structures is that there is no direct transition
latter functionality of the reference designation system apart between the function-oriented and the location-oriented struc-
from transitions (see II-C). However, we think that transitions tures. Transitions between these two structures are nevertheless
are indeed the right mechanism to reflect these relations. allowed and transparent to the user. They are made indirectly
In IEC 61346-1, transitions are said to occur between two by means of the product-oriented structure. Thus, when the
aspects of the same object. As we have seen in section II- user wants to know where are some functions located (a tran-
C, the transition is finished when it designates a child node sition from the function to the location-oriented structure) we
of the target aspect (see Fig. 4 or figures 27, 28 and 29 of interpret that what he really wants to know is where are located
IEC 61346-1). Transitions as in IEC 61346-1 cannot be used, the products that implement those functions. That is, we divide
for instance, to retrieve the product that implements a function, the transition function–location into function–product–location
since they are considered by the standard as different aspects (see Fig. 7). The inverse happens with transitions from the
of the same object3 . Instead, the transition from the function- location-oriented to the function-oriented structure.
oriented structure to the product-oriented structure will give, However, there are some transitions that are not always
as a result, a reference designation for one of the subproducts possible. Let us imagine the case of a product delivered
of the product that implements the function. We think that this with a set of subproducts. Maybe not all the subproducts are
is limiting the full power of transitions, so our proposal is that useful to the plant operation but, since they come indivisibly
transitions will be made between elements at the same level. with the product, they will appear in the product-oriented
That is, a transition from the function-structure to the product- structure. If some subproducts do not implement any function,
structure will return a product that implements the function and a transition from the product-oriented structure to the function-
not one of its subproducts. See Fig. 6 for an equivalent to Fig. 4 oriented structure will not be always possible. For instance,
but with our own interpretation of transitions. Since we make let us consider a simple circuit board with four NAND gates.
transitions between aspects at the same level, the aspect +R2 The plant could use three of the gates for implementing a
of the example appears in the reference designations whenever logical function and the fourth gate could be left unused. In
we want to reference +B1 or +B2 starting from -A2. that case, a transition from the fourth gate (in the product-
As a result of our interpretation of transitions, one can go oriented structure) to the function-oriented structure would be
back and forth in a relation. In the example of Fig. 6, for impossible. The same happens with the spaces defined in the
instance, the transition can be made either from -A2 to +R2 or location-oriented structure of the plant. Some of them can be
from +R2 to -A2. Nevertheless, reference designations should empty of objects.
not contain loops. If we take the same example, that would
The IEC 61346 standard says that the single-level reference
mean that one should avoid the use of reference designations
designation of an element must be unique within the same
like -A2+R2-A2+R2+B1 because they are redundant.
level in a structure. That allows the repetition of the same
In our opinion, and regarding their feasibility, transitions
single-level reference designation for other elements only in
should always be possible from elements in the function-
other levels of the structure. The idea is that the full multi-level
oriented structure to the product-oriented structure. The op-
reference designation of the element will always be different.
posite would mean that there are some unimplemented func-
However, if the reference designation includes transitions, we
tions in the plant. Only in the case that the plant model is
can have the same full multi-level reference designation for
unfinished may some of these transitions not be available.
different objects. Let us suppose, for instance, that the products
We differ from the IEC 61346-3 in this point, which has a
-T1-W1 and -T2-W1 implement the function =C2 in the
much more restricted view about what transitions are possible
model shown in Fig. 8. If we build a reference designation
(see again II-C). The same happens with transitions from
for these two products starting from the function-oriented
the product-oriented to the location-oriented structures. All
structure, both would have the same: =C2-W1. In order to
products must have been placed somewhere in the plant so
solve this problem, we suggest to go up into the hierarchy
3 It is not clear here whether the object should be given the same reference of the destination structure until we reach an element with a
designation in both structures. different single-level reference designation. All the hierarchi-
 7

Function−oriented Product−oriented Function−oriented Product−oriented

structure structure structure structure

=F1 −T1 Enter Data Computer

=C1 −Q1 Process Data Keyboard
=C2 −W1 =C2(−T1)−W1 Visualize Results Tower
=G3 −T2 Screen
−Q1
−W1 =C2(−T2)−W1

Fig. 10. Example of the properties of structures.

Fig. 8. Example of ambiguous multi-level reference designation.

Product−oriented structure
1) If a function is located somewhere, all its superfunctions
will be located (at least partially) in that same place.
Location−oriented structure 2) If a function is realized in one location, all the super-
locations will realize that function as well.
−A1 −A2 (1) (2)
As a guideline for building the plant model, we recommend
to relate the lowest elements in the structures hierarchy. If
+B1 +B2 +B1 +B2 possible, relate only the leaf nodes of different structures. The
reason for this is that all the elements which are hierarchically
−A2(1)+B1 −A2(2)+B2 superior to them will also be related to each other, as described
by the properties shown above. The explicit relations will be
Fig. 9. Resolving ambiguous references in the standard. thus the most concrete ones and the other relations will be
derived by the system from the properties of the structures.
Let us explore one simple example. Imagine a Computer
cally superior elements needed for uniquely designating the product composed by a Screen, a Tower and a Keyboard
transition target element will be enclosed in parenthesis. In subproducts. Suppose that we also have defined the functions
our example, that would mean to write =C2(-T1)-W1 for Enter Data, Process Data and Visualize Results, which are
one of the products and =C2(-T2)-W1 for the other. This implemented by the computer (see Fig. 10, we do not show
guarantees the uniqueness of the reference designation since, reference designations for clarity). Instead of assigning all
by the construction rules of the structures, there will always three functions directly to the computer, it is better to be
be a parent element whose single-level reference designation as much specific as possible and, for example, assign the
will be different. function Enter Data to the Keyboard, Process Data to the
As discussed in section II-C, this problem is also treated Tower and Visualize Results to the Screen product. In this
in IEC 61346-1, suggesting the identification of the exact way, transitions can be made from the specific subproducts
occurrence with a number in parenthesis (see Fig. 9 or to their corresponding functions (something impossible if we
figure 26 of IEC 61346-1). We based our solution on that idea. assigned the functions only to the computer). But we keep the
However, we have used the reference designation system itself advantages of direct assignment as well. In this case, we also
to solve the problem instead of using a single number whose can make the transition from the Computer product to its three
origin is not clear. functions because, as shown in the properties of structures, a
superproduct indirectly implements all the functions that its
B. Properties of Structures subproducts implement.
Following the discussion about transitions, we can state
some properties of the structures based on the constituency (“is IV. C ONCLUSION AND F UTURE W ORK
part of”) relationship of their elements. The basic properties We have seen that the IEC 61346 standard is an ambitious
are the following: document that sets the basis for modelling technical systems
1) If a product is located somewhere, all its superproducts from a wide variety of domains. Due to this generality and to
are located (at least partially) in that same place. some ambiguities in its definitions and concepts, the standard
2) If a product implements a function, all its superproducts is not applied as extensively as it should be. We have seen
are (indirectly) implementing that function. that a common standard would be useful for large projects
3) If a function is implemented by a product, the implemen- where multiple vendors can participate and supply different
tation of its superfunctions also depend on that product. products. By restricting ourselves to the field of automation
4) If a location holds a product, all its superlocations hold and by removing most of the ambiguities, we have tried to
that product as well. improve the standard and make it suitable for the modelling
The properties of functions related to products and vice of industrial plants.
versa can be derived from the basic properties. This is because We have started the development of a prototype software
functions and products are related by means of products, as platform for developing industrial applications based on our
seen in section III-A about transitions. interpretation of the standard. This platform will integrate
 8

different standards and concepts related to plant automation

and offer a consistent view to plant engineers and operators
alike.

V. ACKNOWLEDGEMENTS
Finally, we would like to thank Per-Åke Svensson from
ABB and member of the TC3 (the IEC technical committee in
charge of the publication and maintenance of IEC 61346). We
greatly appreciate his help for answering our questions about
the standard and for his extensive comments and suggestions
during the writing of this paper.

R EFERENCES
[1] Industrial systems, installations and equipment, and industrial products
- Structuring principle and reference designations. Part 1: Basic Rules,
IEC Std. (6)1346-1, 1996.
[2] Industrial systems, installations and equipment, and industrial products
- Structuring principle and reference designations. Part 2: Classification
of objects and codes for classes, IEC Std. 61 346-2, 2000.
[3] Industrial systems, installations and equipment, and industrial products
- Structuring principle and reference designations. Part 3: Application
guidelines, IEC Std. 61 346-3, 2001.
[4] Industrial systems, installations and equipment, and industrial products
- Structuring principle and reference designations. Part 4: Discussion of
concepts, IEC Std. 61 346-4, 1998.
[5] P. Froehlich, Z. Hu, and M. Schoelzke, “Using UML for information
modeling in industrial systems with multiple hierarchies,” in UML2002,
2002, pp. 63–72.
[6] KKS-Kraftwerk-Kennzeichen-System, Verlag technisch wissenschaftlicher
Schriften, VGB-Kraftwerkstechnik GmbH, 1988.
[7] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language
Reference Manual, Booch, Jacobson, and Rumbaugh, Eds. Addison-
Wesley, 1999.
[8] IEEE Recommended Practice for Architectural Description of Software-
Intesive Systems, IEEE Std. 1471, 2000.
[9] R. Garcı́a, E. Gelle, and A. Strohmeier, “A software architecture for
industrial automation,” in Proc. Seventh IEEE International Enterprise
Distributed Object Computing Conference (EDOC2003), Brisbane, Aus-
tralia, Sept. 2003, pp. 315–320.

View publication stats