Information Technology Reference
In-Depth Information
In model-based development processes, models are refined towards executable ap-
plications by use of model transformations but also manual development work with the
models. Such processes often enable automated processing of bulk design information
and are aimed at automatic code generation but can also aid analysis, understanding and
documentation of the system.
In addition to analysis of models and automating error-prone development phases,
another approach to improve the quality of systems and applications could be to inte-
grate the use of simulations to model-based development. Especially, simulations could
be used to facilitate the manual development work of developers by enabling, for exam-
ple, comparisons of alternative design decisions. In their previous work, the authors of
this paper have created and prototyped a preliminary approach to transform functional
models conforming to the UML Automation Profile (UML AP, see [12],[6]) to simu-
lation models conforming to ModelicaML [13]. The concept was presented in detail
by Vepsalainen et al. [19] and its purpose is to facilitate control system development by
enabling automated creation of simulation models of controlled manufacturing systems.
In the process, the simulation models of controlled systems are composed by creating
and integrating a ModelicaML simulation model of the control system to an existing
ModelicaML model of the process to be controlled. The focus of the paper was in
basic control functionality, e.g. feedback and cascade control structures, and the ability
to support simulation of both platform independent and platform specific functions.
However, according to, for example, our discussions with professionals of industrial
control domain in Finland, an important and tedious part of development of control
applications is related to interlocking or constraint control functions.
Interlocks could be characterized as non-safety-critical safety functions. They are
often aimed to prevent deviation situations from occurring or the instrumentation from
being misused, such as, to prevent pumps from running dry or to be started against
closed pipelines. Interlocks do not need to be developed according to safety standards
because safety is usually ensured with separate safety systems. However, because ac-
tual safety systems are often designed to ensure the safety in a simple manner, e.g. to
shut down the whole processes, they should not be activated unless absolutely neces-
sary. Another goal of interlocks can thus be seen in keeping the system in its designed
operating state in order to improve the availability and productivity of it. To achieve this
goal, interlocks can be more complex than actual safety functions because they do not
need to meet the strict requirements of safety standards.
The development of interlocks is, however, difficult. This is because of both the
complexity of the functions and because they are specific to applications and thus cannot
be re-used similarly as, for example, control functions (e.g. parameterizable function
blocks implementing control algorithms) can be. The actual logic, how to keep the
system in its designed operating state and protect the devices, is dependent on both
the controlled process and the control approach for controlling the plant or process.
Another reason for the difficulty is that interlocks may originate from several sources.
For example in industrial processes, part of the interlocking needs may originate from
process design whereas others originate from hydraulics and electrics design. Because
of the separate sources, they may have unpredictable cross-effects to the controlled
system. This is another good reason for using simulations.
 
Search WWH ::




Custom Search