HIMA Open System

Benefits of open Standards in Safety Engineering and in Safety
Applications
Dirk Hablawetz
HIMA Paul Hildebrandt GmbH + Co KG
68777 Brühl
Hermann Schnetzler
Linde AG
82049 Hoellriegelskreuth
Automation projects are executed today below greater and greater costs and time pressure.
The realization times for plants become conditional by the global competition. Often the
vendor is confronted with more or less complete requirements. Unfortunately, changes in the
specification at a late time are already standard. At this time, a very high flexibility is asked in
system engineering.
The wish of every automation engineer ,no doubt, are systems and devices those are to be
tailored perfectly to his needs and settings and additional easy to use. A dream? Not whole!
Openness is at this point the keyword.
Open Systems
Openness is the concept and the basis for interoperability. A component from one vendor
can replace a similar component of another vendor. Easy, possibly without any expenditure.
In order to achieve this all components must be based on industrial standards accepted
broadly. This standards may be formal – approved by a governing body such as IEC, IEEE,
DIN – or de-facto through market forces. De-facto standards are protocols widely used that
almost everyone is familiar with them. If you look around you meet different standards e.g.
EN50170 (Profibus), IEEE802.3 (Ethernet), Interbus, IEC61131-3 and so on. But also
Windows NT and ist components like COM/DCOM, OPC (OLE for Process Control), ActiveX
are so widely used that they are in fact de-facto standards in industry.
Open systems in the process automation must satisfy the following requirements:
• Base on industry standards

• Maximum interoperability of diverse components
• Easy integration of components of multiple vendors
• Easy communication in heterogeneous environments
• Shared common database
• Easy customization and extension (Scalability)
• Open application program interfaces
• Application software is independent of the used hardware
A such openness provides all participants with the possibility to bundle the suitable systems
and components up for their needs. An integrated overall system is finally with the best
components available at the market. Clearly defined interfaces allow the flexible adaptation
__________________________________________________________________________
Benefits of open Standards in Safety Engineering and in Safety Applications
CUIG/TÜV – Symposium „SafeControlTech“, Munich, December 14 and 15, 1999
page 1 of 14
of the system in case of changing conditions or requirements for a working plant as well as
not foreseeable future orders or requirements.
Today modern control systems already resemble "software control systems”and are
characterized by a object-orientated common database. Devices rather software objects then
real hardware. Only through the consequent use an the adherence of accepted standards
make a seamless communication in this kind of DCS possible. To share data is crucial to
open systems.
Figure 1: open control system (picture © by Control Magazine)
Openness also means effectiveness. Every manufacturer can concentrate completely on its
focus, its core competence, and therefore make its product or module the best available to
the market. Customer or system integrator in turn can concentrate on capability of the entire
system without special knowledge of functionality of every single component. This means
useful sharing of jobs for everyone’s advantage.
Additionally, the possibility to choose the best available product on the market guaranties the
user not to fall in the “Lock-In”-syndrome. The user is not longer dominated by special
technologies from one vendor, no matter if this technology fits to his further installations or
not.
Openness allows easier in-house standards, e.g. preconfigured templates, because this can
be done without any consideration for hardware or device specific peculiarities. In the most
cases it is possible, despite of a supplier change, to integrate the new module or device in a
existing system and to keep the former investment.
__________________________________________________________________________
page 2 of 14
• Beside all the technical advantages open systems offer much more topics to the user in
the process industries:
• Lower product costs
• Lower engineering and integration costs
• Lower maintenance costs
• Lower training effort
• Increased performance from rapid improving technologies.
Safety Systems and Openness

Witch kind of influence will the trend to open systems have to safety system?
PES (Programmable Electronic Systems) based on very sophisticated technologies, caused

by the special requirements for safety. This system are really propriety the exact opposite of
openness. On the other hand safety systems will be a much closer part of the overall
automation system in a process plant and the users demand towards a homogeneous
operating desktop will increase. An idea fully compliant with the targets and characteristics of
open systems.
In reference to safety systems there are some requirements:
• Encapsulation of the safety functions

• Nevertheless
- Transparency into the safety system
- Interfaces compliant to industry standards
- Homogeneous Engineering
This requirements are fulfilled by standard interfaces. The use of industry standards outside
of all safety functions to provide the same characteristics outwards compared to a non safety
open system.
Achieving an open system architecture in communication and engineering should be

explained. The example is a HIMA H41q/H51q-System. This System based on the HIMA
HIQuad Technology allowing to encapsulate the safety functions on a board and provide an
inherent safety for every module up to AK6/SIL3. (see article in ...).
OPC
Using OPC as a communication interface is essential for open systems in the process control
(more information’s concerning OPC see http://www.opcfoundation.org )
First, larger and smaller companies worldwide work together in the development of an
(single) standard for communication for the Window NT the today’s de-facto standard in
modern process control systems. Current DCS support a client/server architecture, one of
the basics for open systems. OPC based on the COM/DCOM-Technology of Microsoft
represent a software-interface, allowing (without any big effort for the user) interchange of
data between different systems. OPC take the function of a software-bus including all
management functions. It works independent from used hardware. Our experience shows
that OPC support a data access with no configuration. Data, transmitted via OPC, are
marked by a number of attributes, which provide information’s about Quality, Quantity,
Status, ... . Not only the isolated numbers of a variable are important but also the described
__________________________________________________________________________
page 3 of 14
characteristics. A technique, known from the object-orientated world of software, moved into
the automation technology and bring all the advantages with one.
Under this aspect OPC offers brilliant opportunities to link every OPC-Specification compliant
devices. At the example of the HIMA OPC server, this technique should be illustrated.
The HIMA OPC-Server (a small package of software) runs on Windows NT based Computer
no matter if it is a IPC, a DCS-workstation or even a rack PC. The OPC Server is via an
Ethernet linked to the HIMA H41q/H51q-PES. All internal variables (system- and program-
variables) of a HIMA-H41q/H51q-System can be made available by the Ethernet interface.
All variables, represented by OPC items, have the following attributes:

• Name
• Type
• Value
• Quality
• Timestamp
This attributes may interpret by the OPC partner. Therefore, the HIMA OPC-Server offers a
full transparency to the safety system.
Figure 2: HIMA OPC server
As already mentioned OPC works according to the client/server principle. The OPC server
place all available data to all other partners disposal. Any OPC clients can access
Consequently, all available data are made available by the OPC server to all participants.
Any OPC-Clients (control systems, SCADA-system, ...) can now access to a virtual data
pool of the HIMA-SPS without any limit. The HIMA OPC server supports a variable browsing
so that the data pool can "investigated" from client side.
__________________________________________________________________________
page 4 of 14
Figure 3: OPC client
On the OPC client side the items can be summarized to OPC groups representing special
technological units e.g. a pump control, valve control and visualization, .... A strongly
equipment-specific viewpoint is possible.
The real parameterization which date will be used on which place could be done with an
easy reference link oft the Items between the OPC server and the client by drag and drop
OPC-Clients can access several OPC servers simultaneously, that are, OPC groups can be
compiled for the respective case of application from the most different devices and systems
in the net. Updating the data can occur both cyclically and event-oriented. OPC nodes will
automatically recognized and registered and reregistered as well. Thus a simple replacement
of systems is possible. The mentioned parameterization can occur on the fly.
In the practical use one HIMA OPC server can accumulate the data of different HIMA
Systems in a distributed safety network and make them available from a single point. This
can also come with full redundancy for high available requirements.
__________________________________________________________________________
page 5 of 14
Figure 4: HIMA network with common redundant OPC interface
Applications confirm the simplicity in project planning and the reliability in practice. Numerous
test with all leading providers of DCS- and SCADA-Systems showed, that a link-up by OPC
immediately functioned.
Since OPC works on a logic level, each OPC system an integral component in the overall
system. Consequently, the demand of open systems on a central data pool is met on logic
level, each can access all information of the system. The configuration decreases to the
necessary data reference.
In such a way, costs for engineering and commissioning of communication which are not an
unimportant part of the project planning costs today can be limited to a minimum.
These qualities certify OPC as communication standard of the future for Windows NT. OPC
guarantees Interoperability at a full volume.
Open Engineering Process

A further example shall illustrate that open control is not only limited to the communication
level. By means of the open engineering process the consistent storage of data and the
minimization of working steps is possible. Due to the use of systems being in conformity with
IEC 61131-3 a consistency with respect to the scope of languages is nearly obtained, leading
to a multiple use of the so-produced logic. A further possibility of the open control is the
standardization of the function planning as well as the creation of the logic itself. Taking the
logiDOC/32-system as example and the experiences made at Linde AG a further aspect of
the open control will be illustrated in the following. Here, it should be mentioned that the
engineering package of the HIMA-systems ELOP II-NT and logiDOC/32 is data-compatible.
During project handling of process plants the engineering of instrumentation-specific safety

equipment and the preparation of logic diagrams in particular are an important step for a safe
plant operation.
__________________________________________________________________________
page 6 of 14
The engineering activities during project handling can roughly be divided into:
• Safety-specific classification by the Safety Department

• Function planning by Process Engineering and Conceptual Engineering Departments
(basic)
• Completion of the function planning with signal conditioning by the Instrumentation
Department (detail)
• Specification and procurement of the hardware
• Loop planning
• Operator interface and recording
In the following, the aspect of the function planning willl be described in detail:
Function planning is created as a by-product when preparing P&IDs. Tag numbers are
connected with symbols and provided with corresponding remarks. Logic symbols are rarely
used for such connections. By means of that representation functional links and a safety-
relevant classification are defined, but no detailed logic functions and equipment-specific
design.
Figure 5: P&ID detail
Task
Function planning means:
Conversion of a technical requirement to a standardized document, legible by third

parties without necessary explanations.
The technical requirements concern the controlling of the operation sequence and safety-
relevant binary control functions and interlocks. Package units procured by subcontractors
__________________________________________________________________________
page 7 of 14
shall mostly be considered. Such package units do often contain a considerable quantity of
control equipment such as e.g. compressors, boilers and reactors, which must be integrated
in a total concept.
Methods and Tools

For function planning very different methods are used, depending on standard practice in
companies and technical sections.
• Narratives
They are often used, if operation sequences are concerned or if the
understanding for ”logic links”is missing.
They are mostly discussable and not unambiguous and less suited as
template for safety-relevant applications.
• Cause and Effect Chart
This kind of function description is often required by customers and is best
suited for a quick survey and a "quick test". Such charts are, however, less
suited as basis for programming, as even with comprehensive comments a
definition of functions without any discussions is rarely possible.
• Logic diagram on the basis of function blocks
In Europe, this kind of task description is already a de facto standard and is
based on the symbol definitions according to IEC 61131-3, ISA S5.2, or
previously DIN 40719.
Nowadays, logic diagrams are still established with tools at choice. The field of such tools is
ranging from hand sketches via office tools to CAD equipment and SPS-system-related tools.
The use of tools at choice aggravates the re-usability, the combination of information to a
total concept and will be the cause for errors and lacking productivity.
Thus, an engineering system for logic functions with the following criteria is required:
• Functional contents and graphics acc. to recognized standard (IEC 61131-3)

• Graphic user interface
• Multi-use system (Work group support)
• Document and revision management
• Simulation capacity without special hard firmware (target system independent
test)
• Open for data import from instrumentation planning systems, meaning integration
capacity to such a system (shared data)
• Open for target systems, i.e. transfer to the target system without new
programming
Function Planning at LINDE

LINDE uses with logiDOC/32 a function planning system which fulfills the above-
requirements and which, referring to the above said, delivers the conceptual conditions. So-
called "resource-types", which enable the transition to the target system without
programming are existing for different target systems. These systems include the HIMA-
systems for which no conversion expenditure is required, as logiDOC and ELOP II-NT are
data-compatible.
__________________________________________________________________________
page 8 of 14
Function planning starts with the definition of the project structure which, on one hand, is
defined by the requirements of the IEC 61131-3 and, on the other hand, by structure of the
plant to be controlled.
Due to the fact that not only the safety-relevant functions are established with logiDOC, but
also the logic diagrams for logic links and sequential controls, which are implemented in the
DCS, there will be in a first step two program sets in one resource each.
Figure 6: Structure acc. to IEC 61131-3
__________________________________________________________________________
page 9 of 14
A typical structure for an emergency shutdown system (AVS/ESD) will contain several
libraries with the corresponding blocks and logic diagrams for the individual plant sections.
Figure 7: Project Structure in logiDOC
The structure contains all objects, which are required for planning, in particular libraries with
the standard blocks acc. to IEC 61131-3, i.e. libraries with user blocks and objects for project
documentation.
The object-based system permits the creation of templates. Thus, structures and properties
of the individual objects are tailored to typical applications and must not be established anew
for each project.
__________________________________________________________________________
page 10 of 14
The next step is the creation of basis logic diagrams. In this stage, the functions are defined
acc. to process engineering aspects, without considering the equipment specific design.
The variables, represented as tag numbers, required for that purpose are read from external
engineering systems via import functions or, for integrated systems, directly transferred to
the logic diagrams from the shared data.
Figure 8: Example Basic logic
In this stage, the maintenance of a uniformly continuous logic convention is the most critical
problem. Such a problem occurs then, when the functions of different suppliers shall be
combined. The most simple solution of that problem is the requirement that the describing
text to the variables describes the true condition (logic "1") at the inlet and outlet of a function
plan, without considering the system-relevant design.
An encapsulation of functions in function blocks with clearly defined I/O-level is a further
possibility.
__________________________________________________________________________
page 11 of 14
For detail planning, the basic diagrams are completed by functions to the signal conditioning
and signals for alarm giving and recording are added. The just said is performed by means of
software in the following example by evaluation of analogous signals.
The signal conditioning is usually made in separate logic diagrams, in order not to disturb the
representation of the core logic and to avoid errors by editing.
If the basic diagrams are compact, closed function units, a capsuling in blocks should be
considered.
Figure 9: Example Detail logic
The blocks for the signal conditioning are user blocks; their "internal logic” has certainly been
established with standard blocks, in order to guarantee a continuous simulation and a
possible use in the target system.
__________________________________________________________________________
page 12 of 14
Figure 10: Example internal logic of the motor module
Figure 11: Example Internal Logic of the Limit Block

__________________________________________________________________________
page 13 of 14
The simulation of all the closed logic diagrams in the accustomed working field is an
important element in planning sequence. A recognition of errors in time saves time and thus
costs.
It has proven that in particular for sequence controls the quality of the planning can be
increased by project-accompanying offline-simulation. The increase in quality of the planning
is not only obtained by the detection of errors, but also by the "easy" method being able to
test control variants per simulation.
LINDE is using logiDOC as working tool since one year.

The use of such planning systems requires a structured working method, being of course a
handicap at start and at sporadic use only. The thinking in strict logic structures and function
blocks is for some users a troublesome reasoning. The just said is certainly a reason for the
popularity of cause and effect digrams.
The acceptance by the users is, however, quite positive.
Some complete projecting from Basic-FUP to the implementation of the target system had
been performed with success.
Summarizing, the following criteria are considered to be important for the successful use of
logiDOC:
• Quality assurance by the application of pretested modules

• Knowledge stored in users' libraries
• Efficient engineering by network capacity and multi-user capacity with projectable access
control
• Independence of target system
• Integration in our future instrumentation planning system
Summary
The presented and illustrated examples have cleary shown how systems of different
manufacturers can be combined when consequently using industrial standards. Besides the
simple exchange of data the open control in the engineering process permits the re-usability
of once projected function units. The advantages are obvious.
Open systems are actually already used in plants for revamping or other extensions.
__________________________________________________________________________
page 14 of 14

HIMA Open System

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

HIMA Open System

Încărcat de

Drepturi de autor:

Formate disponibile

Benefits of open Standards in Safety Engineering and in Safety

• Base on industry standards

Figure 1: open control system (picture © by Control Magazine)

Safety Systems and Openness

PES (Programmable Electronic Systems) based on very sophisticated technologies, caused

In reference to safety systems there are some requirements:

• Encapsulation of the safety functions

Achieving an open system architecture in communication and engineering should be

All variables, represented by OPC items, have the following attributes:

Figure 2: HIMA OPC server

Open Engineering Process

During project handling of process plants the engineering of instrumentation-specific safety

• Safety-specific classification by the Safety Department

Figure 5: P&ID detail

Conversion of a technical requirement to a standardized document, legible by third

Methods and Tools

• Functional contents and graphics acc. to recognized standard (IEC 61131-3)

Function Planning at LINDE

Figure 6: Structure acc. to IEC 61131-3

Figure 7: Project Structure in logiDOC

Figure 8: Example Basic logic

Figure 9: Example Detail logic

Figure 11: Example Internal Logic of the Limit Block

LINDE is using logiDOC as working tool since one year.

• Quality assurance by the application of pretested modules

S-ar putea să vă placă și