Next Generation Factory Acceptance Test: April 2012

Download as pdf or txt
Download as pdf or txt
You are on page 1of 7

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

net/publication/224341544

Next Generation Factory Acceptance Test

Article · April 2012

CITATIONS READS

3 753

2 authors:

Mario Hoernicke Jürgen Greifeneder


ABB AG Corporate Research Germany Luebeck University of Applied Sciences
82 PUBLICATIONS   122 CITATIONS    50 PUBLICATIONS   217 CITATIONS   

SEE PROFILE SEE PROFILE

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

Arbeiten des VDI/VDE GMA Fachausschusses 6.11 zu Themen der Virtuellen Inbetriebnahme View project

Information Models and Architectures for Modular Plant Concepts in the Process Industries View project

All content following this page was uploaded by Mario Hoernicke on 22 May 2014.

The user has requested enhancement of the downloaded file.


Next Generation Factory Acceptance Test

Mario Hoernicke, Jürgen Greifeneder

Testing will become more important than ever. The more complex a process plant be-
comes, the more complex and comprehensive tests are required to prove the automa-
tion system’s correctness. Thus, during today’s engineering process, extensive facto-
ry acceptance tests (FATs) are indispensable. Excessively so, the automation systems
hardware is only partly present on the shop-floor, because most of it is directly sent
on site. Therefore, the FAT needs to be based upon a virtual imitation of the control-
lers, fieldbusses and subsystems. In conjunction with an increasing geographic dis-
tribution of engineering activities and a rising shortage of available engineers, the
FAT becomes a very time-consuming and longsome procedure that cannot prove the
system correctness entirely. The project “Next Generation FAT” aimed to identify the
improvement potential in FAT, in order to investigate new methods and tools that
ease the preparation and execution of it.

ured according to the engineering data. Addi-


Today’s FAT procedure
tionally, the emulation PCs have to be config-
ured to fit into the automation system net-
FAT of today’s process plants is an essential work and fit the needs of the emulation.
part during engineering. It is very important 2. FAT Execution
to perform the majority of the logic tests dur-
Once the preparation of the FAT has finished,
ing that phase, because time in the subse-
the actual tests can be performed. Usually the
quent commissioning is much more expensive.
test engineers read through a test specifica-
Meaning, the more tests are done during FAT,
tion and perform the tests manually. By forc-
the less effort is required in commissioning.
ing I/O variables, unplugging cables or pro-
In general, the FAT procedure can be divided voking special situations [2] the automation
in three phases (Figure 1): system, especially the control logic, is brought
1. FAT Preparation into defined states and the behavior of the
complete system is observed. Often, test se-
During the preparation phase, the hardware is
quences are implemented in 61131-3 and per-
staged on the shop-floor. It is configured like
formed on the controllers [3] to ease the
it is done later in the real plant and hereby
preparation of scenarios and to automate their
prepared for the FAT. But usually, only sample
recreation. The results of the observation are
parts of the hardware are present, [1], and
manually documented in a test report.
therefore, the missing hardware needs to be
imitated by virtual pendants that manifest the 3. FAT Deconstruction
same logical behavior. When the hardware is After the test execution, the FAT environment
cabled and the emulation of the missing parts is deconstructed. The implemented test se-
is executed on emulation PCs, both, the quences must be removed from the engineer-
hardware and the emulation, must be config- ing tools [3], the hardware must be sent on
site, the emulation must be stopped on the test of the communication is done in commis-
emulation PCs, and their configuration must sioning. The development of a “Generic CI”,
be switched back to the state before the FAT. customizable for the subsystems to be con-
nected, would have large advantages. The
signal exchange between controllers and sub-
systems could be tested during FAT based on
a complete virtual environment.
2. Harmonization of Emulation Tools
The diversity of controllers and subsystems
that are used in today’s process automation
systems and distributed control systems (DCS),
leads to a large number of emulator types.

Figure 1: FAT Procedure


This procedure is repeated for every FAT of
every plant.

Discovered Improvement Potential

The FAT procedure as it is done nowadays is a


very manual process. A lot of effort is required
for the preparation and afterwards the decon-
Figure 2: Emulators for FAT
struction of the test environment. Additionally,
the test execution, including the documenta- There are emulators for fieldbus systems, e.g.
tion, is very manual and requires high effort. SIMBA [6], there are emulators for Field Con-
trol Systems (FCS), e.g. Foundation Fieldbus
During the project, the FAT-workflow has
[4], for substation automation, controllers and
been investigated and the following improve-
I/O simulation, etc. (see also Figure 2).
ment potentials have been discovered.
1. Communication Between Emulators
For each controller type and a few subsystems,
e.g. Foundation Fieldbus [4] or IEC61850 [5]
networks, emulation tools are available. The
problem is that the controller emulator and
the subsystem emulator do not communicate
with each other, as the communication inter-
faces (CI) are not emulated. This leads to ad-
ditional effort for creating proprietary tools Figure 3: Structure of an Emulator
and connections between the emulation tools.
Each of those needs to be configured manual-
If the communication characteristic is more
ly according to the engineering data. Addi-
complicated or a large number of signals are
tionally, for each tool one or more Ethernet
exchanged, it is usually not emulated and the
interfaces must be attached to the PC hard-
ware, corresponding IP addresses need to be a faceplate or checking if the words on the
configured and adjusted according to the au- faceplates fit into the corresponding boxes are
tomation system network requirements and examples for those. An example for a very
require, because of the large number of in- simple test workflow is shown in Figure 4.
stances, a lot of processing power. Every By automating only those simple tests, a large
emulator shows the same generic structure, saving potential is expected.
see Figure 3. Thus, the harmonization of the
configuration and orchestration of those tools
would have large advantages: the configura-
The Next Generation FAT
tion could be done automatically and in a
similar manner for each emulator, the tools
could be started and orchestrated from a sin- During the project, the described improve-
gle point of access and the manual configura- ment potential has been tackled in three
tion of the network and the adoption of the working packages – each for one of the po-
emulation PCs – according to the needs of the tentials discussed before.
automation system network – could be auto-
WP 1. A Generic CI Emulation
mated, as well.
During the first working package, a generic CI
3. Management of Test Procedure
emulator has been prototypically developed
The most obvious part with saving potential is that forwards signals from the AC800M (Soft-)
the test execution and documentation. There controller to the subsystem emulation and
is a lot of potential to partly automate tests, vice versa. The concept is based on the OPC
automatically document results and provide interface and has been developed and proven
an environment to perform regression tests. for feasibility by implementing specific CIs for
Foundation Fieldbus and IEC61850.

Figure 5: Generic CI Concept


Based on the OPC interface, the values of the
variables are exchanged, whenever a change
of a value has been recognized (Figure 5).
Additionally, the generic CI is delivered as a
Figure 4: Test workflow to statically
class library and provides a very simple SDK
check if all I/O variables are correctly
for embedding it into a subsystem emulation
assigned
tool. The configuration of the variable map-
Besides the logic tests of the automation sys- ping is done based on a XML file that needs to
tem, there are plenty of tests that are very be generated by the specific CI, since the
simple and can be done in a static manner, mapping needs to be created in a specific
without having a dynamic simulation in behind. manner for each subsystem.
Checking if a value is correctly transferred on
WP 2. Emulator Framework Those workflows got categorized towards
The harmonization of emulation tools used their requirements concerning both, automa-
during FAT has been the second task. For that tion potential (respectively manual work) and
reason, a framework that is able to embed information sources.
emulation tools has been conceptual and pro- In the third step a concept for the test execu-
totypically developed. Based on the VMWare tion got developed (cf. Figure 8). The chal-
Workstation virtualization environment, a con- lenge of this was that selection, configuration,
cept to automatically deploy and configure execution and documentation of test work-
emulation networks has been developed, see flows have to be highly automated – and ac-
Figure 6. For more information see [7]. cepted by both, the test engineers and the
customer.

Figure 6: Deployment Concept of the Figure 8: Basic Verification Engine con-


Emulator Framework cept

Additionally, the framework has been tightly From the test engineer’s view, the new tool
embedded into the process control environ- will enable him to systematically create and
ment 800xA, but is open enough for a fast store test cases, define test workflows and
adoption to other DCS or ECS (electrical con- assign workflows to testees, select test work-
trol system) environments, see Figure 7. flows from a global list and apply them to one
or several testees, store test results and gen-
erate test reports automatically and run even
complete test setups (or parts of it, e.g. up to
a given point) for real and virtual testees on
local and/or distributed equipment. The con-
cepts and methods will be further developed
and proven for feasibility in a follow up re-
search project in 2012.

Figure 7: Emulator Framework embed-


ded into 800xA Environment Customer and ABB Internal Benefit
WP 3. Verification Engine
The management of test procedures has been
The improvement potential that has been dis-
the third task. The work focused on the doc-
covered during that project has been directly
umentation and generalization of FAT test
put into working packages that should solve
workflows (an example is shown in Figure 4).
those issues.
The main benefit that has been made visible effort and eventually provide a defined proce-
is the very short preparation time for the FAT. dure for testing DCS and process control envi-
With the harmonization of the emulation tools ronments.
and the development of a framework includ- With a management tool, as described in WP
ing automatic deploy mechanisms and a single 3, the test engineers finally have a tool that
point of access, the entire virtual emulation guides through the FAT. The benefit here is
network can be generated with only a few that every test execution and every result can
mouse clicks. With such a fully virtual envi- be documented automatically in a standard-
ronment the saving during commissioning can ized manner. This again reduces the manual
be up to 80% according to [8]. effort in FAT.
Additionally, staging hardware on the shop-
floor for dynamic logic testing is not required
anymore. The hardware, controller, fieldbus- Conclusion
ses, etc. can be sent directly on site without
shipping it to the in-house testing site and
afterwards to the plant. This saves shipping Engineering procedures move into a direction
costs and administrative overhead. which more and more decouples hardware
from software and progressively deploys DCS
Another benefit is the possibility to work on
and ECS on private clouds, because of their
the same virtual environment from different
easy scalability and life cycle maintenance [9].
locations. The emulator framework supports
the usage of the virtual automation system The steps described in this contribution are
within a geographically distributed engineer- therefore new, but natural steps to move for-
ing team. Since it bases on virtualization infra- ward with the technology for FAT and engi-
structure, backup, restore and packaging pro- neering. The trends: virtualization, separation
cedures for entire virtual automation systems of hardware and software in engineering and
are possible. Recreation of test beds and re- automation of tests, have been addressed and
gression testing is quite easy. evaluated for their usage in FAT within geo-
graphically distributed engineering teams. The
By providing a generic solution for CI emula-
described technologies have been proven for
tion, the test engineers are now able to per-
feasibility and evaluated by the project team.
form tests of the automation system in its en-
tirety. The connection and mapping of varia- The emulator framework as base for a dynam-
bles between the control system and the sub- ic and scalable environment is a technology
systems can be tested and the logical paths of that eases the creation of virtual FAT scenari-
signal values can be demonstrated and proven os. Combined with the test management tool
for correctness. Hence, the quality of the au- to guide the engineers through the test pro-
tomation system increases. cedure and automatically document the test
results, the solutions described in this contri-
Finally, the verification engine working pack-
bution provide a comprehensive and complete
age discovered various possibilities to auto-
procedure for the Next Generation FAT.
mate tests during FAT. Plenty of test cases
are done in a static manner and do not re-
quire the knowledge of specific specifications
of the process and automation system. Their
automation would additionally reduce the FAT
Customer References

ABB Oil, Gas and Petrochemicals [1] Hoernicke, M.; Weemes, P.; Hanking, H.: The fieldbus out-

side the field – Reducing commissioning effort by simulating


Foundation Fieldbus with Soft FF. ABB Review, 2012-01,

Contact Zürich.

[2] Greifeneder, J.; Weber, P.; Barth, M.; Fay, A.: Simulations-

basierte Steuerungsfunktionstests: Generierung von Simula-


Mario Hoernicke
tionsmodellen auf Basis von PLS-Engineering-Systemen.
phone: +49(0)6203-716266 atp-edition, 2012.

e-mail: [email protected] [3] Barth, M.: Automatisch generierte Simulationsmodelle ver-

fahrenstechnischer Anlagen für den Steuerungstest. Disser-

Jürgen Greifeneder tation an der Helmut-Schmidt-Universität / Universität der

Bundeswehr Hamburg, Institut für Automatisierungstechnik,


phone: +49(0)6203-716222
Fortschritt-Berichte VDI, Reihe 20, 2011.
e-mail: [email protected]
[4] Hoernicke, M.; Bauer, P.: Emulation Dezentraler Steue-

rungslogik – Ein Konzept zur Emulation von Foundation

Fieldbus. Submitted to atp-edition, 2012.

[5] Maeda, T.: A testing environment – ABB’s comprehensive


suite of software testing and commissioning tools for substa-

tion automation systems. ABB Review Special Report


IEC61850, 2010, Zürich.

[6] SIEMENS Industrial Technologies: SIMBA Profibus – Hard-

wareplattform, für die Echtzeitsimulation am Profibus im Si-

mulationssystem SIMIT. Broschüre.

[7] Hoernicke, M.; Greifeneder, J.: Virtuelles Emulatoren

Framework – Konzept zur domänenübergreifenden Integra-


tion heterogener Emulatoren. Submitted to atp-edition, 2012.

[8] VDI Nachrichten 2011-11-25, Nürnberg: Notebook stemmt

tonnenschwere Maschinen und Anlagen.

[9] Dix, M.; Stich, C.M.; Gitzel, R.: Use of Virtualization on the

Life Cycle of Process Control Systems. atp International, Ol-

denburg Industrieverlag, Ausgabe 1, 2008.

View publication stats

You might also like