THE COMMUNICATION SYSTEM

ipcas
ipConv
 ipConv THE COMMUNICATION SYSTEM

The Motivation
In many areas of industrial activity the problem of having to
exchange data between mutually incompatible sets of commu-
nication terminal equipment presents itself. These sets of equip-
ment possess corresponding data transmission channels to the
outside world, but they mostly work with different communica-
tion protocols.
Hardware and software have a modular design that the indivi-
dual modules can be added if and when required similar to a
modular system.
Due to the employment of standard components, standard ope-
rating systems and the ipLink basic language, further applicati-
ons are possible apart from the protocol converter function,
such as

The number of different protocols in use in the market – in par- • Gateway • Router
ticular in the sectors of power providers or process control and • Communication Concentrator • Bridge
monitoring – is very large for development reasons. • Data Concentrator
Figure c illustrates the ipConv architecture.
There is therefore a high demand for devices which help to solve
such problems.
Protocol Converter:
ipConv ipConv Software
Requirements can vary considerably. In the simplest case (Fig. a)
Application
the connecting of two sets of terminal equipment merely requi-
Protocols Switching Configuration
res the conversion of one protocol to another.

Programming
It gets more difficult if the data from several different substati- ipLink Language
ons (Fig. b) must be collected, processed and transmitted to one
or several monitoring or control stations. Operating Systems
Windows NT QNX Solaris

Control station Control station 1 Control station 2

Protocol A Hardware
PCs Bus Systems Workstations Protocol Converter:
Protocol A ipConv Platform
ipConv ipConv
Fig. c: ipConv architecture
Protocol B Protocol D
Protocol B Protocol C
Substation Substation 1 Substation 2 Substation 3 Thus ipConv, consisting of hardware and software components,
offers a universal system for the solution of many communicati-
Fig. a Fig. b on challenges.
This represents a totally new approach to cost reduction in the
field of communication.
The Solution
Market demand for a universal solution has led us to develop The Application Fields
ipConv.
ipConv is primarily employed by power, gas and water providers,
in the industrial sector, such as the chemical and automobile
Our first and foremost objective in developing ipConv was the
industries, by rail companies and in any other sector requiring
priority of customer benefits, such as safe commissioning, fast
communication between different protocols.
debugging, easy upgrading as well as an optimal price/perfor-
mance ratio.
ipConv can also be applied for various network topologies.
Fault detection and modifications can very easily be carried out
during and after commissioning either on site or remotely (via
modem/phone line).

Intelligent software tools have immensely facilitated and acce-

lerated commissioning and also increased its calculability, i.e.
thus reducing commissioning costs to a minimum and ensuring
that the client’s schedule will be met.

The specially developed programming language ipLink allows to

achieve these development goals.
The Software
• ipLink – the basic language
ipLink is an abstract (not machine-oriented) high-level program-
ming language that has been designed for the simple imple-
mentation of communication protocols.
• Task-oriented
Unlike C or C++ ipLink is not machine-oriented but is rather
geared to task requirements. This quality is achieved by means of
powerful language features that radically simplify the develop-
ment of communication applications.
Since compilation of ipLink is not necessary there is a direct refe-
rence to the runtime system. This facilitates trouble shooting
considerably.
• Reduced complexity of programs
ipLink reduces the complexity of programs greatly. Therefore the
software modules are more compact yet at the same time trans-
parent and as a result much more easily to modify and to service.
• Portability
ipLink supplies a universal operating system and hardware inter-
face and thus renders the application independent of the plat-
form used.
• Internal software structure
The individual protocols have been implemented as ipLink pro-
cesses or ipLink process groups.
An important role is assumed by the node process (Fig. d).
Its function is to receive, process and, if necessary, to transmit
the information from one protocol to other protocols. All data
coming from and going to the node are transferred in the nor-
malized form in case of value or status changes.
The internal software structure of the application contributes
greatly to the universal qualities of ipConv.
Configuration
Protocol A Protocol B
Node
Protocol C Protocol D
Monitor
Fig. d: Schematic diagram of the node process
• Transparency
During commissioning as well as the operation a fast diagnosis
of possible faults is highly advantageous.
For this purpose each protocol allows the whole communication
traffic with the remote terminal to be tracked on various
abstraction levels starting with the normalized data (telegrams
in hexa-decimal representation) to the decoded telegrams (plain
text representation).
The software node records the complete data flow from source
to target.
The information thus obtained can be archived for a longer peri-
od of time. This enables even rare software bugs to be diag-
nosed.
The monitoring program offers interactive link with the node
and current information values be obtained selectively. In addi-
tion, information can also be fed to the node, thus simulating
data blocks.
All information values and states can be checked at any time
and, if necessary (for instance during a testing phase) changed
immediately.
• Configuration of ipConv
The configuration of ipConv can be carried out directly in the
device via an editor or by automatic generation from an Excel
table.
• Documentation
By means of an integrated documentation generator allocation
tables can be generated from the ipConv configuration. The data
transfer can be unambiguously followed with these tables.
The Hardware
• Platforms
Thanks to the compliance with widely used standard compo-
nents such as industrial PCs, SPARC work stations and bus
systems (STD/STD32/PC-104) a wide range of hardware versions
can be used.
• Mass storage device
The SolidStateDisk (Flash) as the mass storage device used gua-
rantees a high level of data integrity (MTF > 1,000,000 h) and
shock resistance.
From the point of view of the operating system, the
SolidStateDisk is treated just the same as a hard disk.
The SolidStateDisk can be easily removed and inserted without
removing even a single screw. This allows fast hardware replace-
ments without reloading the software and configuration. Simply
replacing the flash card is enough.
• Telecontrol Transformer (TCT)
The Telecontrol Transformer is an additional device that allows
the communication between PC and any “not asynchronous“ or
“not UART conform“ protocols. Connection to the PC and to the
communication terminal equipment is effected via RS232/485
interfaces.
The Hardware Configuration
The choice of the right hardware configuration depends largely
on the protocols to be implemented and is adjusted individually
to the respective task requirements. The hardware components
are as a standard housed in an industrial PC (Fig. e).
Technical Data:
The Handling
• Local administration
The local administration of the converter is effected via a serial
interface by means of a monitor program.
• Software installation
The software is installed via floppy disk. In conjunction with
remote administration, the data (software, configuration and
diagnostic files) can also be transfered via the serial interface.

• CE and EMC tested • Remote administration

• power supply: The remote administration package consists of an internal
115/230 V AC, 50/60 Hz, 200 W, modem and the data transmission software.
or optionally This means that suddenly occurring bugs can be remotely dia-
12 V, 24 V or 48 V DC gnosed and remedied quickly and economically.
• 8 – 16 slots passive backplane Changes and upgrades of the software and the operating para-
• redundant power supply (optional) meters can be effected directly via modem and without expen-
• slots: 1 x 3,5“ HH, 2 x 5,25“ HH sive assignments on site.
• lockable
• dust filter • Password protection
Fig. e: Front view with • 19“ housing Access to all administration channels is protected by a password,
open housing cover thus preventing unauthorized access.

Advantages/benefits of the ipConv communication system at a glance

Advantages Benefits
>> Abstract (not machine-oriented) high-level programming –> Fault diagnostic during commissioning
Software language has been facilitated considerably
>> Task-oriented –> Shorter commissioning time
>> The configuration is stored in form of ipLink source text –> Recording of data flow for a defined
(direct reference to the runtime system) period
>> Reduced complexity –> No expensive assignments on site
ipConv – The Communication System

>> Universal operating system and hardware interface, i.e. ope- –> Fast bug identification of even rare bugs
rating system and hardware is independent of application –> Additional efforts and consequently costs
>> Targeted to widely used standard components for connecting an external device for
>> Integrated monitor program for selective feeding and downloading the configuration data are
enquiry of information superfluous
>> Project-specific installation and operating manual –> High operating safety
–> High protection against unauthorized
>> The remote administration (via modem) allows the installation access
Hardware
of software, configuration changes and system diagnostic –> Simple handling
>> Configuration is carried out via an integrated editor in the –> Low development costs
device –> Low maintenance costs
>> The SolidStateDisk as mass storage device (under QNX) –> Low commissioning costs
guarantees a high data integrity MTBF > 1,000,000 h and
shock resistance (max. 2,000 G); replacement without
removing a single screw allows quick hardware changes
without reloading any software
>> Redundant operation (optional)
>> Interfaces:
– Ethernet c e.g. TCP/IP, Sinec-H1
– RS232/485 UART c e.g. IEC 870-5-101, Modbus
– Profibus
– TCT c e.g. Indactic 33, Conitel-2020, Sinaut 8FW (PDM)
 The Application Examples
Control System Task: The protocol converter ipConv is located between
the SAT SCADA system and the Alstom SMAZ-C
RS 232-interface 9600 Baud IEC 870-5-101 system. 50 2-pin commands and their acknowledge-
slave ments as well as 750 indications from 50 medium
voltage protection relays (SG) are transmitted.
ipConv
Protocol Converter
Customer: SAT Systeme für Automatisierungstechnik
DNP 3.0 GmbH & Co, Austria
RS 232-interface 9600 Baud master
Project: Legnica, Poland
Data Concentrator

SG 1 SG 2 SG 3 SG 50

Example 1

Task: The protocol converters ipConv serve for coupling

between a Siemens XMAT station control system and
the overlay control stations.
Control Station #1 Control Station #2
The protocol converters are laid out redundantly and
mutually monitor each other via separate RS 232
Conitel-2020 Harris 5000 connection (R). Communication to the control
TCT TCT stations is executed via different protocols.

Customer: Siemens AG, Germany

(R)
ipConv ipConv
Protocol Converter #1 Protocol Converter #2 Project: CFE Mexico

A
B
XMAT/Sinec-H1
Simatic AG

Example 2

Task: The protocol converter (S1), in one of several

To satellite From satellite
substations, communicates with the RTU via
Indactic 33/41.
Router Router Data from the RTU are converted into the
IEC 870-5-104 protocol and transmitted via satellite
Ethernet IEC 870-5-104 Ethernet IEC 870-5-104 by means of TCP/IP as transport layer to the control
TCP/IP slave TCP/IP master station.
The protocol converter (Z) is directly connected to
the Front End Processor (FEP). For the communi-
ipConv ipConv
cation between the protocol converter (Z) and the
Protocol Converter S1 Protocol Converter Z
FEP each substation is assigned a serial connection.
Indactic 33/41 IEC 870-5-101
master slave Customer: Skydata Inc. – A GILAT Company, Florida, USA
TCT
Project: Manny Canjar, Columbia

ABB Central Unit

RTU FEP

Example 3
Protocol Overview
Extract of the protocols that can be realized on the ipConv platform.

Protocol Configuration Interface/Profiles Protocol Configuration Interface/Profiles

3964R master/slave PCM async Indactic 2033 master/slave PCM sync

ACS master/slave PCM async Indactic 21 master/slave PCM sync
ACS 3100 master/slave PCM sync Indactic 23 master/slave PCM async
ADLC link layer PCM async Indactic 33/41 master/slave PCM sync
ADLP 180 master/slave PCM async ISO 8073 transport layer Ethernet
ANSI X3.28 balanced/master/ PCM async Micro-4F master/slave PCM async
slave Modbus ASCII master/slave PCM async
CDC Type I / II master/slave PCM sync/async Modbus RTU master/slave PCM async
CETT-20 master/slave PCM async NETCON-8830 master/slave PCM async
CETT-50 master/slave PCM async Profibus-DP link layer Profibus
CETT-80 master/slave PCM async Profibus-FMS MMS Profibus
Conitel-2020 master/slave PCM sync Quics II master/slave PCM sync
DNP 3.0 master /slave PCM async RECON 1.1 master/slave PCM async
EFD300/400 master/slave PDM RP 570/571 master/slave PCM async
F4F master/slave PCM async SAT 1703 master/slave PCM async
Fuji master/slave PCM sync Sinaut ST1 master/slave PCM async
FW535/537 master/slave PDM Sinaut-8FW PDM master/slave PDM
GEADAT 90 master/slave PCM async Sinaut-8FW DUST master/slave PCM async
Harris master/slave PCM async Sinaut-8FW PCM master/slave PCM async
5000/5500/6000 Sinec-H1 transport layer Ethernet
HDLC link layer PCM sync Industrial Ethernet
HNZ 66 S XX master/slave PCM async SMSC / EMI PCM async
IDS master/slave PCM async TCP/IP transport layer Ethernet
IEC 870-5-1 link layer PCM async Telegyr 709/709S master/slave PCM async
IEC 870-5-101 balanced/ PCM async Telegyr 809 master/slave PCM async
unbalanced/ Tracec 130 master/slave PCM sync
master/slave UCA II MMS TCP/IP/
IEC 870-5-103 unbalanced/ PCM async PCM async
master/slave Wisp+ master/slave PCM async
IEC 870-5-104 master/slave TCP/IP ZM 20 master/slave PDM
IEC 870-6-XXX TCP/IP, Sinec-H1
TASE.2, ICCP Additional protocols on request

The Contact
ipcas GmbH
Wetterkreuz 17 · D-91058 Erlangen, Germany
Phone +49 9131 7677 0
Fax +49 9131 7677 78
Internet http://www.ipcas.de
E-Mail info@ipcas.de