This paper describes an improvement of the engineering process of automated plants by combining information of the technical process and plant structure. Integrating a semi-formal process description in MS Visio® for the requirements engineering phases and using these planning results throughout the engineering process can be an approach for an integrated engineering. By linking the semi-formal process description with a plant structure description in AutomationML the engineering efficiency can be increased. The potential, arising through the presented approach, is shown by an example from the engineering of a hot strip mill. The requirements have been modeled within the MS Visio® implementation; these results can then be used for a consistent observance of the stated requirements on the technical resources that have to be engineered
The planning process of automated industrial plants
is characterized by interdisciplinary cooperation of
different disciplines. The similarities in the engineering of
manufacturing and process facilities are a breakdown
into many phases with phase-related tool support and a
lack of data exchange solutions [
Nowadays the necessary coordination between the
engineers of different disciplines is often handled on
the basis of a non-formal description of the realizable
technical process [
To create the basis for optimal information exchange during the planning process, this article presents an approach for a holistic formal plant description. Furthermore, it will be shown how a transparent requirements engineering can be achieved by the use of this holistic formal plant description.
As introduced in the first section misunderstandings and misinterpretations, e.g. of the technical process, are pre-programmed if the communication is based on an informal description, e.g. textual.
For the description of batch processes in [
For our purposes a general and formalized
description is required which is domain independent (i), easily
understandable to all engineers involved (ii) and usable
throughout the life-cycle of the system (iii) [
Accordingl to [
The formalized process description (FPB) offers the
possibility to easily and understandably describe a
process. Besides easy comprehension by all
participants the process description provides process-relevant
information throughout the entire life cycle of the
systems in a clear and structured way [
For this the guideline defines a small number of symbols for the graphical description of the process. The classes of objects are: operators (=process operator, technical resource), states (=product, energy) and relations (=flow, utilization, system boundary) (Fig. 1).
A technical process is modeled inside of a system boundary. This enables the identification of the systems input and output variables and thus, the process which is carried out in the system. The advantage of defining a system boundary is the breakdown of a system into different sub-systems which results in a hierarchical structure of the process. This leads to a detailed description of the process and identification of interactions between the objects inside the system and its environment. In the guideline states define the input and output variables of the process and the process operators and are linked by directed arcs (=flow). With the process operator a pre-state is transferred into a post-state. For carrying out the process a technical resource is associated with a bidirectional correlation (U).
The formalization is supported by rules defining in which manner states and operators are interlinked with each other inside the system boundary.
The technical process is first described by a graphical model in which states and operators are defined and linked with flows. By decomposing process operators a detailed description of the process is possible. The decomposition of the process supports a structured proceeding and results in a hierarchical process model. Therefore the FPB supports the creation of a graphical flow of the process which is more understandable than a textual specification as it is performed today. Besides detailing a process by decomposing, states and operators can be detailed by assigning attributes.
Attributes are next to the name and a unique ID process-specific data such as duration of a step, necessary pressures, temperatures, as well as material and energy quantities. These data provide the essential information of the process and are stored and managed in an information model. The information model also contains the causal relations between states and operators (Fig. 2).
The relational part describes e.g. different views on
the technical process like logistics, asset management
or security [
The graphical description of the technical process is
intuitive, easily understandable and comprehensible to
all participants without having extensive previous
knowledge of the process. The separation within the
process description between products (=states),
processes (=process operator) and resources
(=technical resource) provides a solution-neutral use at
the beginning of the engineering process. More
important than the graphical information are the
processspecific information like pressures, temperatures or
product quantity. These values of the states and
operators enable the derivation of requirements to the later
technical resource. Therefore at the beginning of the
engineering process the technical resource is assigned a
role that serves as a placeholder in advance. This role
is gradually substituted in the engineering process
through the concrete plant component, which meets the
requirements of the role [
Existing software tools which are available for using the FPB do not support an XML-based exchange of relevant process data. Therefore, the institute of the authorsinvestigated MS Visio® for implementing the information model which is presented in section 5. The advantage of MS Visio® is the possibility to store information in an XML data format which offers potentials for a consistent data exchange with other CAEtools (section 5).
model in MS Visio® FPB information
The tool MS Visio® has already been successfully used in the engineering process in many ways. Therefore it offers different Shape-Galleries for modeling P&ID (Process & Instrumentation Diagrams), circuit diagrams or various flow charts. In addition to the predefined shape-galleries it is possible to develop individual galleries according to one’s own needs. This provides a basis for adjusting the requirements of the formalized process description into MS Visio® with Visual Basic for Application (VBA).
Within MS Visio® graphical objects (=symbols) are provided in so called shape-galleries which act as classes for instantiating objects. The required symbols are taken by “drag&drop” onto the worksheet and finally linked to each other.
To describe processes with the formalized process description in MS Visio® the authors implemented a shape-gallery with the symbols and rules defined by the guideline (Fig. 1). For data management MS Visio® is based on so-called shapesheets which are comparable to excel sheets. These shapesheets contain general information of objects like size, color, coordinates of textual content (=graphical information) as well as information defined by user. This allows assigning additional information like predecessor and successor relationships of an object (=causal relationship) or assigning characteristics defined by the formalized process description (Section 3.1). The possibility to store information in shape-sheets creates an extensive information model.
Besides the guideline-specific functions e.g. rules for linking symbols, assigning of attributes the implementation of tool-specific functions increases the usability of the tool. With the representation of the hierarchy the user gets a comprehensive overview about the process structure with its decompositions. Furthermore, with the possibility to assign different views like quality or safety to each attribute only relevant information for the engineering process can be presented. This provides the possibility to derive only those requirements which are important for the engineer.
Due to a reduced period of planning a cross-trade exchange of information based on XML becomes increasingly important. With the use of MS Visio® for modeling and describing technical processes according to VDI 3682 it is now possible to provide processspecific data and information to different CAE-Tools as well as AutomationML.
Besides process-specific information like sequences
and duration of process steps or type of input/output
products the process description provides information
for basic engineering like requirements engineering
which is discussed in the following section.
Furthermore, causal information about the process can be used
during the whole life cycle of the plant e.g. for
diagnosis actions in the operational phase of the plant [
The integration of process description and plant structure information, in just one model will have a significant influence on the engineering results. Through the integration of the neutral process description with a multi-disciplinary plant structure description, the consistency in engineering can be improved.
Although on the one hand the formalized process description provides references to the technical resources and thus describes the plant structure and on the other hand AutomationML/CAEX provides a hierarchical structure, both models are used isolated nowadays. This contradicts the basic idea of an integrated engineering process.
This section gives an outline of the concept and terms of the data format AutomationML and CAEX. Furthermore the concepts of AutomationML, mainly derived from CAEX, used for the approach are described in detail.
The aim of the neutral data format
AutomationML™ is the storage and exchange of complex
engineering data within planning phases to bridge the gap
between separate and phase-specific CAE-Tools within
the engineering process. The problem is enhanced
because during the engineering the data are subjected to a
continuous and iterative enrichment and change.
Therefore, a continuous exchange of engineering data
by the vendor-independent data format
AutomationML™ was developed which is based on the
concept of the CAEX format and supports object-oriented
aspects like re-use and inheritance [
Besides the storage of the plant topology
AutomationML supports the integration of additional
engineering data. Therefore AutomationML references to other
exchange data formats [
For storing associated behavior of e.g. the handling
device AutomationML supports the integration of
programmable logic control (plc) data and information by
referencing to PLCopen XML. PLCopen XML was
developed to exchange project data and libraries of plc
programs between different environments [
Storing data about plant structure, geometry and kinematics and behavior offers a possibility to exchange complex engineering results. For the described approach only the opportunity for the storage of plant structure with CAEX plays an important role.
The meta model CAEX sets the definition of structure and storage of objects with their properties and relationships. CAEX is the basis of a general data format for the storage and exchange of complex engineering data. CAEX defines four fundamental elements, which are described in the following.
The SystemUnitClass describes physical or logical plant objects and units including their technical realization and internal structure with a reference to specific roles from the RoleLibrary. A plant object consists of different attributes, interfaces, nested internal elements as well as internal connections. Attributes including e.g. value, unit and constraints like maximum or minimum value.
The InterfaceLibrary comprises different types of interfaces. Interfaces are needed to define connections between objects e.g. for product, signal or information flow.
Objects, derived from the RoleLibrary are used for an abstract description of physical plant objects. The use of roles within the engineering process supports the independent description of the concrete technical realization of the objects’ functionality. Roles are used as placeholders at the beginning of the engineering process and are consecutively specified and replaced by the concrete object. Furthermore, roles can be used to determine requirements which the realization has to fulfill.
The InstanceHierarchy enables the description of
the plant’s topology with all its components,
instantiated from the SystemUnit, and all physical and
electrical connections. Furthermore, roles from the
RoleLibrary can be referenced to the objects in the instance
hierarchy to describe their function [
maionML/CAEX the
FPB in
The first step to integrate the formalized process description in CAEX is done by the expansion of a role library derived from the directive containing roles shown in Fig. 3.
Since the objects of the formalized process
description are connected through flows and utilization the
necessary interfaces have to be defined in the interface
library. One approach is to expand the interface library
with the interface classes process-product,
processenergy, process-information (=flow) and
processresource (=utilization). With these additional role and
interface classes the formalized process description can
be mapped in AutomationML [
The integration of roles and interfaces into an
AutomationML library offers the possibility of
transferring the graphical relationship as well as
processrelated information into a structural description with
CAEX. As the FPB AutomationML also supports the
separation of the three aspects product, process and
resource as it can be seen in Fig. 4 [
As shown in Fig. 4 a transfer medium like XML is required for an automatic assumption of process information.
Based on the concept presented in section 4 the following section describes which possibilities arise from this proceeding for a software assisted requirements elicitation and requirements management. For a better understanding this will be shown by the simplified example of a steel strip production model. The following use case deals with the planning of the laminar cooling section of a hot strip mill.
The task of a laminar cooling section is to cool the hot rolled steel strip distributed locally to adjust the desired material properties. Therefore the steel strip is applied selectively with water from both sides. Depending on the material properties to be achieved, different requirements for the technical realization of the cooling section arise. If the plant operator decides to modify the production process during the planning phase, e.g. to expand the product range, this leads to new requirements for the technical realization of the cooling section.
If the concept described in section three is implemented, this provides not only the ability to specify the resulting requirements from the process description formally, but additionally the option, to match this automatically with the parameters of the chosen technical implementation and point out the discrepancies that occur to the planning engineers (requirements management).
At the beginning of a project the technical process will be described with the formalized process description. For this purposes each process step, e.g. cooling the steel band, is represented by a process operator.
As described in section 3 a technical resource is assigned to each process operator in the process description. The technical resource is a placeholder for particular types of technical realization. The attributes of these placeholders describe the requirements which have to be fulfilled by the technical realization. After these requirements have been modeled in MS Visio®, the results can be exported into a CAEX file. The placeholder of the technical resource of the FPB is represented as an Internal Element and is connected with the process operator in CAEX as exemplarily shown in Fig. 4. Furthermore a predefined role from the Role Class Library is assigned to this Internal Element and the previously defined attributes are transferred to the role requirements of this Internal Element. This procedure creates a formal description of requirements of the technical process. Through the mapping into CAEX these process requirements can be reused by the following disciplines for their subsequent tasks. Fig. 5 summarizes this with an example of the role requirements of the laminar cooling section.
Based on the results of the requirements modeling the selection of appropriate technical resources has to be supported. Therefore the engineers compare the defined attributes in the role-requirements of the placeholders with the available technical resources. When those resources are part of the unit library, this comparison can be automated. In the next step the placeholders can be replaced by instances of the Unitlibrary. The predefined role-requirements remain with the Internal Elements.
Changes in the project, e.g. expanding the product range, which though leading to new requirements create a discrepancy between the requirements of the roles and of the technical realization exemplarily shown in Fig. 6.
The model-based merging of the resulting
requirements from the process description with the
information of the technical resources contained in the plant
forms the basis for a software based support of
requirements management. As shown in [
A software assisted requirements management based on a neutral data exchange format can lead to a significant reduction of possible mistakes in the plant engineering process, without losing discipline specific tool support.
Within this article an approach for bridging the gap between process and plant description based on a formalized process description is presented. It has been shown how to integrate a semi-formal process description in MS Visio® and how to make the results automatically available in the neutral engineering data exchange format AutomationML. Based on this it was shown how the requirements resulting from the process description can be matched with the properties of the technical resources of the plant model which allows a software assisted requirements management