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

net/publication/257364782

Design of Industrial Automation Systems - Formal Requirements in the

Engineering Process

Conference Paper · September 2013

DOI: 10.1109/ETFA.2013.6648148

CITATIONS READS

3 291

4 authors, including:

Natalia Moriz Oliver Niggemann

Ostwestfalen-Lippe University of Applied Sciences Fraunhofer Institute for Optronics, System Technology and Image Expl…
12 PUBLICATIONS   43 CITATIONS    229 PUBLICATIONS   900 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Analyse großer Datenmengen in Verarbeitungsprozessen (BMBF) View project

Montexas4.0 View project

All content following this page was uploaded by Oliver Niggemann on 07 March 2015.

The user has requested enhancement of the downloaded file.

 Design of Industrial Automation Systems - Formal Requirements in the
Engineering Process

Björn Böttcher1 , Johann Badinger2 , Natalia Moriz2 and Oliver Niggemann1

1
Fraunhofer IOSB-INA, Industrial Automation, Langenbruch 6, 32657 Lemgo
{bjoern.boettcher, oliver.niggemann}@iosb-ina.fraunhofer.de
2
Institute of Industrial Information Technologies, OWL University of Applied Sciences,
Liebigstrasse 87, 32657 Lemgo, {johann.badinger, natalia.moriz}@hs-owl.de

Abstract
Today’s production plants are not conceivable without
automation systems. Due to the increasing complexity of
production plants and therefore of automation systems,
delays and interruptions in automation projects are ob-
served. A design model for more efficient planning of in-
dustrial automation systems is introduced. It is based on a
new and practical proceeding for the construction of a re-
quirements model. Extended feature models as formal re-
quirements representation enable to verify the consistency
of requirements. New insights on the necessary capabili-
ties of a formal reasoning system for planning the whole
automation system are deduced from the design model.
1. Introduction
The objective of this paper is to introduce an ap-
proach for the formalization of requirements on indus-
trial automation systems and the planning of these sys-
tems. Based on today’s engineering processes a formal
requirements model is constructed in this approach. Solu-
tion variants for a whole automation system are automati-
cally derived from the formal requirements model with an
expert system for industrial automation. The design ap-
proach is based on extended feature models which allow
to verify the consistency of requirements.
Industrial automation requires deterministic system be-
haviour with high accuracy in time and space. The first
challenge to achieve this is to formalize requirements for
the system to be developed. Secondly, to fulfill these re-
quirements the following three steps are necessary:
(i) finding a set of components that match the require-
ments, (ii) to find a topology that describes the physical
connections of these components, (iii) to implement the
control application and to find configurations for the com-
ponents which guarantee that the components act and in-
teract only and entirely in the required way.
There is a variety of design solutions such as central-
ized versus distributed control architectures or alternative
products. Hence, measures for assessing and comparing
this solutions need to be defined. Measures are for exam-
ple energy efficiency or operation costs.
The significance of formal design in industrial automa-
tion manifests itself in the fact that in embedded system
design 59 percent of all companies don’t use any formal
development techniques although formal requirements are
important for efficient design processes [5]. A reason for
this is that the design of technical systems is an iterative
process between changing and extending formal and in-
formal requirements [9, 6] which needs to be integrated in
the whole engineering tool chain [8].
Additionally formal requirements on industrial automa-
tion systems are not only necessary for more efficient
planning but also for traceability and compliance of re-
quirements at changes of production systems and in plug-
and-produce processes like described in [10].
The paper is structured as follows. After an overview of
the state of the art the design approach is described. Based
on this necessary capabilities of the needed expert system
are discussed in a further section.
2 State of the art
2.1 Design models
The process of developing an automation system
can be distributed into the three phases, Requirement-
Analysis, Planning and Implementation. A survey on de-
sign and modeling of technical systems is given in [15].
Usually the automation solutions are designed manually
by a variety of different planners in the different life cy-
cle phases. This procedure is time consuming and error
prone. To deal with these issues, an automated design ap-
proach is more effective. In [12] it is shown how new de-
sign methods can improve the efficiency of the automated
development of building automation systems (BAS). A
dialog system guides the planner through the elicitation
of requirements. Based on the given requirements, an
abstract design is generated automatically with explicit
knowledge. To accomplish the complete automation sys-
tem, in a next step evolutionary algorithms search for a
detailed design. The detailed design replaces the technol-
ogy independent functions by manufacturer-specific com-
ponents based on rich semantic descriptions. Finally, a
variety of full developed BAS is provided to the system
integrator who chooses the best variant for a particular ap-
plication.
The framework for design from [6] gives important def-
initions and modeling concepts but can’t be summarized
within this paper’s available space. One of these concepts
is the distinction between ’expected behaviour’ and be-
haviour derived from the structure resulting from a design
process. This is important for verifying and adapting the
planning expert system.
2.2 Non-functional requirements and Design Pat-
terns
Non-functional requirements of industrial automation
systems are described in [3] and [4]. They focus on func-
tion and behaviour while this paper deals with inferring
structure from those. The well known concept of design
patterns in the domain of software engineering is applied
to automation systems by [2]. These design patterns pre-
cisely describe reusable specifications but do not use logic
for specifying requirements and planning of automation
systems as intended in this paper.
2.3 Extended feature models
An extended feature model (EFM) introduced in [1]
describes all variants of a (Software-)Product-Line. It is
a tree where each node is a feature. A feature is ”a promi-
nent characteristic of a product” [1] which ”may refer to
a requirement” [7]. Subtrees can be optional, mandatory,
alternative or excluding each other. A feature can have at-
tributes which are measurable properties. They are limited
by a domain which is a set of nominal, ordinal or cardinal
values. Furthermore, a feature may have extra-functional
features which define a relation between one or more at-
tributes of a feature’s child features. Such an EFM can
be mapped onto a constraint satisfaction problem (CSP)
[1]. Combining a CSP with an objective function leads to
a constraint satisfaction optimization problem (CSOP). In
[1] seven functions are defined on EFMs for reasoning on
EFMs to obtain information about number of variants, to
apply filters, to calculate the variability and to describe the
commonality of a feature.
EFMs will be refered to in the design model introduced in
the next chapter.
3 Design model
Figure 1 shows the four steps of the proposed design
model which guides our research on formal requirements
for industrial automation systems. The modelling is based
on the study of real use cases of automation systems from
the “Lemgoer Modellfabrik” (LMF) [11] and from com-
panies that participate in this research project.
The design process is structured as follows. In a first step
required mechatronical parts are selected. In the second
step requirements for each part are formulated. The first
two steps result in a requirements model for the whole
system to be designed. The third step uses expert knowl-
edge on industrial automation systems for deriving solu-
tion variants. Step four populates the alternative solutions
with concrete products. Because of alternative products
further variants emerge in step four.
S 1 Views/Templates
S 2 Requirements
Requirement Model
S 3 Architecture
Variants
S 4 Component Realization with
Variants concrete Products
Figure 1: The four design steps
In the first step (S1) the mechatronical parts of a planned
production system are chosen out of a catalog of prede-
fined so-called templates. The name template indicates
that not specific products are described but only properties
and constraints which are used to select specific automa-
tion products in the last of the four steps. Basic templates
such as sensors or actuators and composites of these can
be combined to more complex templates and added to the
catalog if necessary. A template has properties and con-
straints on these properties and is modelled by an extended
feature model. Templates correspond to features and a
template’s properties to the feature’s attributes. Software
function-blocks that encapsulate control algorithms for a
template may be part of a template. Inputs and outputs
of such a software block can be connected to properties
of other templates within the containing template. For ex-
ample a software block’s input can be connected to a sen-
sor’s value or an output to a motor’s speed. This allows
templates to contain expert knowledge that does not have
to be formalized in further steps.
An example for a template are a conveyor or a saw for
cutting the conveyed material. The level of production
cells is the highest modelling level for templates except
for a special template that corresponds to the whole pro-
duction. This is explained in the next step. Larger parts
of a production system are organized by views. A view

contains one or more templates and has no own properties
and is also modelled as an extended feature model. The
firstly chosen mechatronical parts, now templates, belong
to the initial view mechanics which serves as a sketch
like proposed in [13]. Different views address indepen-
dent concerns of the whole system such as data acquisi-
tion, visualisation, safety, etc. Typically only a subset of
all properties and sub-templates of a template are relevant
for a view. Views allow for the formulation of constraints
which span several templates and templates are allowed
to be referred to in more than one view. This is described
by the metamodel in figure 2. The views describe require-
Figure 2: meta-metamodel, metamodel, model
ments on interactions and dependencies of an automation
systems subparts. If the plant should be structured into
production cells a template describes one of these cells
and a view interrelations between cells. Given that views
allow for multidimensional separation of concerns [14].
In the second step (S2) the chosen templates are
parametrized by limiting attribute domains to single val-
ues or value ranges and by adding constraints. An EFM
is valid if the equivalent CSP is satisfiable ([1], definition
9). A template encodes requirements and is modelled as
an EFM. If this EFM is valid the requirements are consis-
tent. A constraint for example is that the rotation speed
of a motor has to be equal or smaller than another motor’s
speed (figure 3).
The first two steps result in a holistic requirements model
in form of a template for the whole system. Figure 3
shows such a requirements model. The whole system is
a template containing all views and their templates. Mod-
elling the whole system as a template and with that as an
EFM makes it possible to give the whole system proper-
ties that require for example a certain overall energy con-
sumption or a decentral or central control concept.
Step three (S3) is the task to use expert knowledge about
industrial automation systems to generate alternative ar-
chitecture variants from the requirements model. Until
now, the templates are connected by requirements in form
of constraints on their properties. One type of necessary
expert knowledge are rules that know which devices can
be physically connected. For example, two motors speeds
cannot be directly connected but only via a PLC with a
software function-block for speed synchronization.
It is necessary to know which properties and constraints
template system
view mechanics
 template saw
 attribute
 material ∈ {wood}
 trhoughput rate ∈ [0..50]
 template blade
 motor1
 attribute
 speed ∈ [0..500]
 template conveyor
 motor2
 attribute
 speed ∈ [0..200]
 template sledge
 motor3
 attribute
 speed ∈ [0..100]
 software_function_block
 constraints
 motor2.speed <= motor3.speed
view visualization
view safety
Figure 3: Exemplary requirements model
require the exchange of information at runtime. All of
these properties can be regarded as nodes of a graph with
an edge for each pair of properties in one constraint. Fig-
ure 4 provides a picture of that. The rules need to be ap-
plied until this graph is transformed into alternative archi-
tecture variants with only edges between abstract prod-
ucts that represent realizable fieldbus connections. A fur-
ther type of necessary knowledge is how to assure timing
and sufficiency of resources such as fieldbus bandwidths
or energy consumptions. The last step (S4) branches off
T1 T2
V1 Vm
Tn
T3
Figure 4: Templates T1 . . . Tn and views V1 and Vm . After
step S3 architecture variants represent alternative topolo-
gies such as the daisy chain indicated by the dashed lines.
each architecture variant into component variants with
real products based on the template’s EFMs. At least some
measures for comparing and assessing solutions cannot be
applied before this step. For example economical factors
or technical properties like efficient operating ranges are
unknown before this step. As mentioned in the introduc-
tion, a whole automation system is described by the com-
ponents, their topology (physical connections), the control
programs and configurations for each component. The lat-
ter cannot be generated without knowledge about the real
components. Hence, configurations such as certain field-
bus settings in vendor-specific formats need to be derived
in this last step and in dependency of the templates, views,
architecture variants and chosen products.
4 Related issues
This section focuses on S3 whereas S4 will be sub-
ject of further work. The question to be discussed here
is what is needed for realizing the step from the require-
ments model to architecture variants.
Despite the fact that views might explicitly limit topolo-
gies and field buses to certain classes the first necessary
information are data rates, real-time and redundancy re-
quirements. These are to be inferred from views and tem-
plates via appropriate expert knowledge. To assure timing
and sufficiency of resources such as fieldbus bandwidths
or energy expert knowledge in form of appropriate algo-
rithms is required.
A taxonomy of automation devices such as PLCs,
switches, IO-devices and so on is the base for the rules
that encode which devices can be physically connected.
So these rules define how invalid paths in the graph de-
scribed in S3 are transformed into valid fieldbus connec-
tions.
That means that an expert system has to find algorithms
and coordinate their execution to generate valid architec-
ture variants but it does not have to output the architecture
variants itself. S3 can be partitioned into single parts that
can be specified and implemented by different human ex-
perts for different fieldbus-, PLC- and other technologies.
Future work will answer the discussed issues in more de-
tail and present results from the prototype which is cur-
rently under development.
5 Conclusion
A four-stepped design process based on extended fea-
ture models has been introduced. In the first two steps
a formal-requirements model is constructed. Along these
steps the objective is to reduce the solution space of the
corresponding CSPs.
An expert system finds appropriate algorithms which gen-
erate architecture variants in step S3. Step S4 selects spe-
cific products for each architecture variant. Alternative
products branch each architecture variant into component
variants. The assessment and comparison of architecture
and component variants is not in the paper’s focus but will
be in future work. The formalisation of requirements on
industrial automation systems and their planning based on
these requirements are divided into smaller issues to be
conquered one by one.
The metamodel will be completed based on empirical
analysis of existing formal descriptions from the project’s
use cases. Currently there is a prototype for an engineer-
ing system based on the introduced design model under
development.
Further work will be on the assessment of design solutions
in regard to technical and economical measures.
By limiting the validity of a view’s constraints to different
operation modes and life cycle phases such as planning,
first operation, operation or upgrades requirements could
be handled in a holistic and refined manner.
6 Acknowledgement
This work is sponsored by the BMBF (German
Ministry of Education and Research), funding code
01M3204A, as part of the project ”EfA: Entwurfsmeth-
oden für Automatisierungssysteme mit Modellintegration
und automatischer Variantenbewertung” (2012-2015)
View publication stats
References
[1] D. Benavides, P. Trinidad, and A. Ruiz-Cortés. Automated
reasoning on feature models. In Advanced Information
Systems Engineering, pages 491–503. Springer, 2005.
[2] K. Eckert, A. Fay, T. Hadlich, C. Diedrich, T. Frank, and
B. Vogel-Heuser. Design patterns for distributed automa-
tion systems with consideration of non-functional require-
ments. In Emerging Technologies & Factory Automation
(ETFA), 2012 IEEE 17th Conference on, pages 1–9. IEEE,
2012.
[3] K. Eckert, T. Frank, T. Hadlich, A. Fay, B. Vogel-Heuser,
and C. Diedrich. Typical automation functions and their
distribution in automation systems. In Emerging Technolo-
gies & Factory Automation (ETFA), 2011 IEEE 16th Con-
ference on, pages 1–8. IEEE, 2011.
[4] T. Frank, M. Merz, K. Eckert, T. Hadlich, B. Vogel-
Heuser, A. Fay, and C. Diedrich. Dealing with non-
functional requirements in distributed control systems en-
gineering. In Emerging Technologies & Factory Automa-
tion (ETFA), 2011 IEEE 16th Conference on, pages 1–4.
IEEE, 2011.
[5] I. Garcia and I. Andrea. Using the software process im-
provement approach for defining a methodology for em-
bedded systems development using the cmmi-dev v1.2. In
Computer and Information Technology (CIT), 2010 IEEE
10th International Conference on, pages 233–240, 2010.
[6] J. S. Gero and U. Kannengiesser. The situated function-
behaviour-structure framework. In Artificial Intelligence
in Design, volume 2, pages 89–104. ed Norwell, MA,
USA: Kluwer Academic Publishers, 2002.
[7] S. Jarzabek, W. C. Ong, and H. Zhang. Handling variant
requirements in domain modeling, 2003.
[8] N. Maiden. Improve your requirements: Quantify them.
Software, IEEE, 23(6):68–69, 2006.
[9] B. Meyer. On formalism in specifications. IEEE software,
2(1):6–26, 1985.
[10] J. Otto, B. Böttcher, and O. Niggemann. Plug-and-
produce: Semantic module profile. In MBEES 2013 - 9.
Dagstuhl Workshop on Model-Based Development of Em-
bedded Systems, 2013.
[11] OWL University of Applied Science, Lemgoer Mod-
ellfabrik. http://www.hs-owl.de/init/en/research/lemgoer-
modellfabrik.html (Feb 5, 2013).
[12] S. Runde, H. Dibowski, A. Fay, and K. Kabitzsch. Inte-
grated automated design approach for building automation
systems. In Emerging Technologies and Factory Automa-
tion, 2008. ETFA 2008. IEEE International Conference on,
pages 1488–1495, 2008.
[13] M. Suwa, J. Gero, and T. Purcell. Unexpected discoveries
and s-inventions of design requirements: A key to creative
designs. Computational Models of Creative Design IV, Key
Centre of Design Computing and Cognition, University of
Sydney, Sydney, Australia, pages 297–320, 1999.
[14] P. Tarr, H. Ossher, W. Harrison, and S. M. Sutton Jr. N de-
grees of separation: multi-dimensional separation of con-
cerns. In Proceedings of the 21st international conference
on Software engineering, pages 107–119. ACM, 1999.
[15] Y. Umeda, H. Takeda, T. Tomiyama, and H. Yoshikawa.
Function, behaviour, and structure. Applications of artifi-
cial intelligence in engineering V, 1:177–194, 1990.