Swistec

1

Swistec‘s RKS-family is a consistently-desi-gned series of ripple-control systems with a homogeneous software and hardware design. It meets all customer requirements - from the activation of a single transmitter to the admi-nistration of big centralized as well as de-cen-tralized ripple-control systems.

The RKS-family consists of the following products:

RKS-12: local control unit

RKS-16: centralized ripple-control unit

RKS-870: de-centralized ripple-control unit

This brochure can only give a first impression of the capabilities of the systems.

To complete this, we also offer:

Flyers on existing projects.

Free-of-charge demos of our technologies.

Obligation-free lending of an evaluation system.

The following features of the hardware and software of all centralized and de-centralized systems does not dependent on the unit size:

Of course, all of Swistec‘s ripple-control units and systems support all commonly used conventional ripple-control telegram structu-res.

Tele-programming of ripple-control recei-vers via ripple-control telegrams in accor-dance with DIN 43861-301 does not only support generating of the telegram structure. The software is designed in such a way that the administration of how the receivers are programmed and independently switch AF-ripple-control receivers is transparent for the user at all times.

Due to the modular hardware structure both the RKS-16 as well as the RKS-870 can be extended according to increased require-ments.

Each unit level provides interfaces to external dispatching systems.

Ripple-Control SystemsConsistently designed hard- and software for centralized and de-centralized systems

Concepts of our systems - Page 2 Redundancy strategies - Page 3 Comparison: centralized / de-centralized control unit structures - Page 4 Software performance features - Page 5 Software options - Page 8 Homogeneous technology for heterogeneous ripple-control systems - Page 10 Interfaces to dispatching systems - Page 12 Hardware performance features - Page 13

Swistec

Although RKS-16 and RKS-870 are based on the same hardware as well as software com-ponents, there is a fundamental difference in the system setup as soon as 2 or more transmitters are involved. This difference increases with an increasing number of trans-mitters:

In case of structures with a central control unit, all ripple-control transmit-ters are controlled by this one control unit (RKS-16) - which can be doubled for redundancy purposes - via output and transfer of ripple-control gating signals. (Fig. 2)

Swistec already successfully installed units from the RKS-family in entirely centralized or decentralized as well as in mixed systems

- partly even in very big systems.

Fig. 2: Centralized control unit RKS-16

RKS-870

tele-control terminal station �(FWK-870)

Area A

UW UW UWRKS-12 RKS-12 RKS-12

LAN

transmitter�1 ... n

transmitter�1 ... n

transmitter�1 ... n

work stations mobilework stations

IEC 870-5-101

Frequency� 1

Bit Pattern I

Area B

UW UW UWRKS-12 RKS-12 RKS-12

transmitter�1 ... n

transmitter�1 ... n

transmitter�1 ... n

Frequency� 2

Bit Pattern II

dial-up network

(of 5 possible ones) (of 5 possible ones)

VFT

VFT

VFT

VFT

VFT

VFT

transm. � 1

transm.� n

transm.� 2

PC - Server

Direct gating

In case of structures with decentralized control units (RKS-870), a local control unit (RKS-12) generates the actual ripple-control gating signals (also called bit patterns). Here, the central control unit takes over the central mode of operation and the coordination of the local control units. (Fig. 1)

The RKS-870-system offers a special advan-tage since it can accommodate mixed sys-tems that are especially suited for transition periods. As is depicted in Fig. 1, the tele-con-trol terminal station can also control ripple-control units via conventional direct gating.

Therefore, a RKS-870-system can be desig-ned in an identical way to Fig. 2 as a central system and during the ongoing operation with simple changes to the configuration be transformed into a system that transmits tele- control telegrams to decentrally installed local control units. This transformation can be done line by line, as soon as the transmission tech-nology as well as the locally installed local control units RKS-12 are available.

Concepts of our Systems

2

process control unit (PA)

LAN

work stations

transmitter 1

VFT

VFT

mobilework stations

transmitter n

VFT

VFT

transmitter 2

VFT

VFT

dial-up network

RKS-16 PC - Server

Fig. 1: De-centralized control unit RKS-870

Swistec

Swistec

Setup of a local control unit LANIn general, control units of the generation RKS-16 / RKS-870 can be networked via local area network (LAN), in which case the communica-tion in accordance with TCP/IP uses Ethernet

- either copper lines or fiber optic cable.

LAN allows for:

networking of multiple work stations to one ripple-control unit. A maximum of 6 work stations with individually different access rights have already been installed at a control unit. Depending on the access rights, either work station can serve programmers and / or users.

setting-up a completely redundant backup system. Work stations as well as the connection of ripple-control processes follow the principle of (n-1) redundancy. (Fig 3)

data export to other systems (e.g. export of operation times to MS-EXCEL™ via office-LAN).

By using adequate transmission technologies (WAN, ISDN or modem) the system can be accessed remotely. Via this remote access the standby service can completely observe and conduct the ripple-control activities from any location. In addition, our customers have the option of having us maintain their systems via remote access.

Generally speaking, the option of a (n-1)-red-undancy (so called „vertical redundancy“) already exists in a decentralized system (RKS-870) due to the system‘s extendable setup. The term „vertical redundancy“ is visu-alized in Fig. 1. In case of a communication line or server PC component failure, those local control units RKS-12 that are effected by the failure are taking over the ripple-cont-rol operations for the connected ripple-control transmitters. Since the time schedule of the RKS-12 reflects that of the master control unit, only spontaneous operations of the master control unit are lost.

For central systems, a „horizontal redun-dancy“ within the master control unit and an additional n-1-redundant backup system is recommended. (Fig. 3)This way a complete backup in case of a cen-tral system failure is guaranteed.

Transmission problems can be eliminated by either setting up a redundant backup system or by using the independently operating RKS-12 local control units. The latter combines the advantages of both systems since a potential failure of a single RKS-12 does not interfere with the other ripple-control operations.

Redundancy Strategies

3

process control unit (PA)

LAN

work stations

transmitter 1

VFT

VFT

mobilework stations

transmitter n

VFT

VFT

transmitter 2

VFT

VFT

dial-up network

RKS-16 / redundantPC - Server�RKS-16 - Server

PA - Standby

PC routing techn.�RKS-16 - Standby

RKS-12

...

...

...

...

...

Fig. 3: Redundant control unit RKS-16

Swistec

Advantages centralized version less requirements regarding transmission technology (in most cases 50 Baud chan- nels are sufficient).

simplified search of errors on the trans- mission routes since measure-wise AF - telegrams can be tracked easier.

easier administration and handling of system technology.

Advantages de-centralized version system-immanent redundancy - even in cases of complete damage of transmis- sion lines.

redundancy of transmission lines is unnecessary.

with lesser system time in the master system (i.e. without a backup server) a (n-1) redundancy of the complete system is achieved.

Comparison: Centralized / De- centralized control unit structures

4

A challenge of the decentralized system setup is the way data and software is illustrated and handled in the local control units that are installed in different locations. Especially with a larger amount of local control units a change in schedule so far meant quite some work. In the RKS-870-system, this disadvantage has been compensated for by potent software. The software of the RKS-870-server observes each change in the data of the master sta-tion whether the RKS-12 or the emergency schedule that is administered by the RKS-12 is concerned. If so, the configuration is auto-matically matched with the data within the RKS-12 and updated online. (Fig. 4)As a consequence, with the help of sophis-

ticated software-tools all tasks - from the complete administra-tion of the RKS-12 to updating of software

- can be conducted from the master sta-tion, making local handling unneces-sary. The other way around there is also a multitude of operation messages from the RKS-12 that are avai-lable in the master sta-tion. These operation messages allow for a complete overview of the operation modes and occurred errors.

In addition, the complete telegram transaction can be tracked and analyzed online. (Fig. 5)

This feature can already be used at a mini-mum transfer rate to the local control units of 300 Baud.

Fig. 5: Monitoring telegrams with protocol analysis

Fig. 4: Matching data between RKS-12 and master station

Swistec

Swistec

Software Performance Features

5

Each interference with the system is object-ori-ented: the user selects an object of his choice by mouse-click and the system responds by offering him, depending on his access rights, the available tasks.

Example for the programming of a control room station

1 The GUI shows the status of the program-med commands. Depending on the selected transmitter, these can be determined individu-ally for specific areas. The main task of the RKS-16 (which is the automatic control of a ripple-control day in accordance with the given schedule) is con-stantly illustrated graphically.

2 Symbols for transmitters as well as sub-stations guarantee for a clear indication of error messages and the selection of transmit-ter-based states within the system.

In addition to the graphically illustrated processes on the screens of the PC all opera-tion-based data are depicted in an excerpt of the protocol.

Due to screens that can be designed indivi-dually the operating software as well as pro-gramming software offer a maximum of flexi-bility so that specific customer requirements, based on the various setups of ripple-control systems that our customers work with, can be met.

Since there are numerous different screen designs only a few of them can be illustrated to give a brief overview.

The software offers comfortable tools for a graphic user interface (GUI) that can easily be designed. The monitor size is the only limi-tation. In some cases with more complex sys-tems not all relevant data can be presented on one screen. However, the software offers the option to build sub-screens by arranging boxes (objects) that symbolize specific ripple-control commands or ripple-control transmit-ters. In these boxes, for which the user can define colors as well as sizes, the respective states of the commands or transmitters can be signaled.

Fig. 7: Example for a user interface with ripple-control commands arranged in sub-screens

Fig. 6: Example for a user interface with all ripple-control commands arranged on one main screen

3

3

2

1

2

Swistec

6

Archival of operationA record of all operation-relevant incidents that goes back to the first day the system has been used is stored in the archive. With its search and filter mechanisms the archive is a very powerful tool for long-term evaluations of likely sources of problems in a ripple-control operation.Data can either be stored on optical or magnetic media. Thus allowing for a continuous yet paperless storage.

Message signallingError and warning messages can be triggered from various sources within a ripple-control process such as: error messages of ripple-control transmitters, faulty impulses in the power supply system, messages of the local control units or internal messages of the main station as well as external messages that are reported via digital or analogue inputs of the master unit or a sub-unit. For each possible message, its behavior can be defined in detail.

Each message can:

be registered in the archive.

be visualized with an icon on the user interface either with a different color or in blinking mode.

be visualized with an icon of a transmitter or a local control unit on the user interface

as long as the message is appointed to a transmitter or a local control unit.

trigger a message window on the monitor with messages that can be specified individually. These message windows are sorted by priority and point of time. Up to 7 messages can be displayed at the same time. Should there be more than 7 messages, these would immediately be listed in a message list and also displayed successively, after an individual confirmation, according to their priorities.

be signaled for central gong or alarm units via an alarm output (separate honk impulse and continuous signal: failure).

depending on the message‘s priority, various acoustical signals can be triggered via an internal soundboard. All current messages are also listed in a message list in which they can be confirmed.

Time AspectsIn addition to the visualization of the general process a main task of a ripple-control main unit lies in the independent execution of the ripple-control schedule. The ongoing development of the time aspects is an especially important element of an AF- ripple-control system‘s schedule.

The most diverse contracts need to be rea-lizable. That is why the RKS-software offers easy to use constructions that let the user e.g. create the last day of a month (often connec-ted with maximum provisions) as well as all even/ odd months or any time frame that shall be declared as a condition.

Fig. 9: Time aspect - calender days

Fig. 8: Options of message signalling

Swistec

Swistec

Due to the enormous variety of the created time functions, even the most complex custo-mer requirement can be satisfied.

In order to avoid a continuous manual main-tenance of the data, the RKS-systems auto-matically calculate flexible holidays, thus the data only needs to be defined once - when the system is set-up. (Fig. 10)

All conditions in the system are referenced by obvious names so that the user can recognize the conditions‘ meanings easily. This guaran-tees that despite the 1,200 possible different conditions they remain recognizable.

Entry of ripple-control-dataExtensive ripple-control operations can be defined by the object „ripple-control com-mand“. Of course all conventional ripple-cont-rol-telegram-patterns are supported.The telegram structure, consisting of address respectively prefix group and executive sec-tor can be defined and assigned comfortably. (Fig. 11)

Basic data such as priorities and operating privileges need to be defined. (Fig. 12)

Area-oriented ripple-control units are gaining more and more importance as one con-sequence of technologically merged utility companies. This means that for certain con-trol tasks the transmission area is limited to a specific sub-group of the total amount of

Fig. 10: Time aspect - Holidays

transmitters that are used within the system. This enables a control unit to deal with the often necessary mixture of different transmis-sion patterns.

Transmission time entries are also control task-oriented, thus resulting in a clear structure. In addition, the merely time-oriented listing of all ripple-control commands is visualized in the „daily program“-window. Due to extensive analytical mechanisms the

user can gain insight in any given ripple-con-trol day including the analysis of all defined time-related conditions.Presently, the system supports up to 8,000 processible ripple-control objects respectively transmission time entries.

Fig. 12: DK-Basic data

Fig. 11: DK-Address programming

7

Swistec

Software Options

Operating Time MeterThe operating time meter, also called ON-time meter, records and sums up the duration in which the respective ripple-control object is activated (on).This function can either be necessary for invoicing or statistics.

For each ripple-control object the software offers two meters that store and sum up the operating time (e.g. separate for high and low tariff) during different periods of time. (Fig. 13)

These stored operating times can be summed up, displayed and printed out daily, monthly, annually as well as exported to MS-EXCEL® for further handling.

The RKS-870-system also makes use of the vertical redundancy of the decentralized tech-nology. Should the main unit fail the data will be recorded by the RKS-12 sub-units. As soon as the main unit is operational again the operating time during the failure will be copied from the sub-units.

Energy ControlTraditionally, ripple-control technology is being used for energy supply optimization.

The new requirements for agreements regar-ding schedules and their compliances that are based on the „Verbändevereinbarung II“ as well as the changed situation of the market that is reflected in spot markets and power trade exchange markets lead to newly formu-lated requirements for the control tasks of the AF-ripple-control-systems.

Very different types of contracts and cus-tomers need to be administered by energy control. In addition, it needs to be ensured that schedule agreements and changes to desired values can be exchanged via various interfaces to trading and other commercial systems. Naturally a main focus lies on the safety of Intranet and similar connections.

The software module „Energy Control“ serves as a means for:

recording of load data - either via coun-ting impulse or analogue input.

visualizing of load data for short term as well as long term analysis.

predictions of energy consumption and warnings of load peaks.

load control, e.g. reduce power or influ-ence consumer.

An additional control over the entered data as well as warning messages in case of incorrect data input are of course part of the software‘s numerous features.

Fig. 13: Programming screen operating time meter

8

Swistec

Swistec

measurements that can calculate loading steps respectively release times based on definable algorithms. (Fig. 15)

Various boundary conditions such as substi-tute values in case of lacking measurements or different ways of calculating average respectively equivalent temperatures are obviously included in the software.

Additionally, analogue control respectively cal-culation of equivalent temperatures gets used where load predictions need to be generated and no external prerequisites are given.

Independent of the calculation of temperature ranges analogue control offers the possibility to directly perform switching actions depen-ding on whether values taken at analogue inputs have been exceeded or fallen short.A classical example is the regulation of street lights based on brightness measurements when threshold control cannot or should not be directly transformed by external photo cells. Currently up to 7 parallel analogue controls within one unit can be activated - each selec-ting out of a maximum of 12 temperature ranges.

Tele-programming of AF-ripple-con-trol receiversAs long as ripple-control receivers are mainly used as a substitute for timers the daily sen-ding of time-rigid switch commands via the ripple-control-system is superfluous. Using tele-programmed ripple-control receivers in accordance with DIN 43861-301 makes sen-ding of all time-rigid ripple-control transmissi-ons unnecessary without limiting the flexibility and the energy-control options which have made ripple-control a profitable means of energy control.

The software clearly presents the program-ming of ripple-control receivers (Fig. 14)and allows for transmissions of programming data. The user can change switch times that are stored in the receivers without having to worry about the telegram structure of tele-control commands, program switch commands or time synchronization commands.

The transmitters‘ independently switching tasks and the tasks of the directly controlled receivers are equally displayed in schedule lists. Thus enabling an optimal survey over the actual existance of on / off states in the net.

Analogue controlAnother traditional task of ripple-control sys-tems is the control of temperature-dependent heating systems. The main unit‘s software offers the tool „Analogue control“ which consists of multiple temperature and wind

Fig. 14: Insight in tele-controled ripple-control receivers

Fig. 15: Analogue control

9

SwistecHomogeneous ripple-control routing tech-nology for administrating heterogeneous ripple-control systems

Central command for all service areas

Central list of messages

Main archive

Central administration of the time schedule

Simultaneous selection of regional detail handling

Fusions of energy suppliers as well as an increasing centralization of network manage-ment to lesser locations present new tasks for ripple-control routing technology:

support of various networking areas that can be equipped with heterogeneous receiver and transmitter technology.

ripple-control technology that is open to future complex expansions of service areas.

easy to use and well structured tools that support users in more and more complex sur-veillance and control tasks.

Especially the first aspect has already been solved with Swistec‘s ripple control technology in various projects: e.g. different types of bit patterns such as Semagyr, DECABIT® and multifunction are controlled by one control unit in either shared or separated transmission areas.

Swistec has already been installing systems of up to 120 transmitters for quite some years.

Why put even more effort into developing system technology?

10

Swistec

Swistec

In the standard ripple-control routing techno-logy the master control unit only supports one central tele-control terminal station. Therefore ripple-control transmissions with different types of bit patterns could only be transmitted one after the other.

However, the market has new and important needs, such as:

1. The various limitations resulting e.g. from special tariffs or heterogeneous ripple-control technology may prevent the integration of ripple-control transmissions into a shared time schedule.

2. Even in non-redundantly set-up systems a failure of the main tele-control terminal station does not affect all service areas of the ripple-control routing technology.

3. A failure in one part of the network (e.g. repeatedly occurring reply error of control receivers) does not effect other parts of the network.

4. In a network routing station or on remote user stations it is desirable to have and maintain a separate PC for each area / ripple-control unit.

As a reaction to these needs Swistec enhan-ced the ripple-control routing technology, giving management a qualitatively new free-dom to plan the integrative use of ripple-con-trol technology.

The following aims have been achieved:

With a shared user interface the control room personnel can observe the most impor-tant functions of the system at one glance.

Failures of the ripple-control technology in one service area do not affect the process control of the other service areas.

Although all service areas are administe-red by separate ripple-control processes it is possible to conduct actions that influence the complete ripple-control technology. Examples are: Triggering of lighting commands Load shedding Transmitter blockage.

Despite of a shared user interface and the option to manage all ripple-control processes from one PC the basic processes for each service area are modular. This leads to the following advantages: New service areas can be integrated into the existing system without having to change the database of parameters of reliably wor-king processes.

It enables the user to make long-term plans since later spatial or organizational changes do not affect the other service areas.

Of course these options also exist on remote user stations that can be subject to individual limitations depending on the service areas that they control.

11

Swistec

Interfaces to dispatching systemsSimplified operations push the integration of ripple-control management in dispatching management. There are various paths of which Swistec has already mastered nume-rous in its customers‘ projects. Some of which shall be described below:

Window management within the dispatching system For triggering a ripple-control process via the interface (monitor/keyboard/ mouse) of the dispatching system a window stacking order (e.g. via the X11-process) or the software of a RKS-client can be run as a task on an interac-tive terminal of a dispatching system. The second option however is not a real inte-gration since the RKS-software and the dis-patching system‘s software need to be ope-rated in the same way. This solution is easy to realize and is certainly designed for ripple-control requirements in an optimal way.

Communication interface in accor-dance with IEC-870-5-101Due to the standardized IEC-870-5-101 format it took only a few ripple-control-spe-cific extensions during the past few years to develop interfaces to PSI AG‘s dispatching systems PSIcontrol, SIEMENS AG‘s SINAUT-Spectrum and STS GmbH‘s Prins. For these, the main aspect has always been that both systems (the dispatching as well as the ripple-control system) have to be able to run inde-pendently of each other. This means that the ripple-control tasks with all its special features need to be operated by the ripple-control unit. The administration of the various time conditions and special func-tions (e.g. for street lights) can be handled with the control-unit tools that have been continuously extended during many years on a separate control position of the ripple-cont-rol unit. Nevertheless, all operational actions (such as triggering of manual transmissions, blocking and unblocking of ripple-control transmit-

ters, etc.) can be initiated on the dispatching system’s interface. In addition, switching com-mands can also be triggered and controlled with optimization algorithms of the dispat-ching system.

The advantage of this concept is the indepen-dent, autonomic ripple-control activity with the option of its integration into the user interface and the design of the dispatching system. The software has been specifically designed for ripple-control needs so that ripple-control units can be programmed as needed.

LAN-Integration as „ripple-control switching element“This only in cooperation with the guidance system manufacturer PSI in various projects realized solution offers a maximum of integra-tion of ripple-control in system dispatching technology. However, it also requires a com-plete representation of the ripple-control pro-cess in the guidance system since the ripple-control technology does not have any own operating or programming options anymore. The traditionally high percentage of costumer-specific solutions in ripple-control technology leads on the one hand to a rather high amount of integration work that should not be unde-restimated. On the other hand, however, it offers the best possible integration results.

A potential disadvantage of completely inte-grated solutions can be the fact that ripple-control operations are depending on the avai-lability of the system dispatching technology because ripple-control technology requires a higher operating availability than system dis-patching technology.

12

Swistec

Swistec

Conditions of our developmentSince 1993 there are various laws in place within the European Community that all technical equipment must meet. These so called EMC-guiding rules let the manufactu-rer decide whether he wants to fullfill them to the degree that his technical equipment is not affected at all or does not get harmed respec-tively destroyed when tested.

Swistec‘s equipment, unless noted otherwise, fulfills the requirements to the degree of its technical equipment and therefore the ripple-control processes will not be affected. This enhances availability as well as relia-bility. Depending on the requirements that themselve depend on the system‘s setup ALL levels that are listed in the guiding rules are fulfilled.

Ripple-control processes require very specific hardware and software features as far as the ripple-control process control unit is concer-ned since e.g. the duration of ripple-control pulses respectively telegrams that depends on the frequency of the network have to be handled. These requirements cannot be met sufficiently by standard components.

As a consequence, more than 10 years ago Swistec decided to develop and maintain its own hardware in-house. This guarantees a longterm availability of all units which is a well justified demand of our customers.

Installation of unitsThe ripple-control specific hardware of the described systems RKS-16, RKS-870 and RKS-12 is concentrated in the components RKS-16 central process control unit, FWK-870 and RKS-12.

Depending on the requirements these can be manufactured either as single or double row 19“ racks in which power supplies, radio clocks and the ripple-control specific units of Swistec can be installed.Due to the flexible 19“-rack system each unit can be assembled individually with respect to the specific requirements.

Hardware Performance Features

13

Fig. 17: RKS-12 with LCD-panel and GPS-receiver

Fig. 16: RKS-16-PA or FWK-870 with ISC-1

Fig. 18: CPU-360 with LAN-interface

Swistec

Also, all in- and output units have in- and output modules that can be plugged-in so that various characteristics can be achieved and modules can easily be replaced should this be necessary. Output modules for example have double current outputs, semiconductor relays, electro-magnetic relays or V24-modules.

In order to offer the best possible conditions for EMC-testing that is also conducted while developing new products, Swistec conducts all its line-related measurements in its own testing laboratory that is equipped with cali-brated instruments. All field-related measu-rements are conducted in cooperation with contracted certified laboratories.

Requirement-oriented features:In addition to the previously described fea-tures the in-house development of all units allows for an optimal set-up that is designed to meet real-life needs:

Each unit has a small LED-display consisting of 16 two-colored LEDs thus enabling a clear overview over various conditions such as con- ditions of all in- and outputs or unit-internal functions (e.g. „emergency time-table active“, „synchronization of network is missing“, etc.) on the hardware itself.

14

May 2006Technical data may be subject to changes. All trademarks are registered trademarks of their owners.

Fig. 20: LED- display

Fig. 21: XIO with 16 DI /DOFig. 19: CPU-332 with 8 ripple-control transmitter interfaces

Swistec

Graue-Burg-Str. 24 - 26D - 53332 Bornheim

Phone: (+49) 2227 9171-0Fax: (+49) 2227 9171-41e-mail: info@swistec.deVisit our website: www.swistec.com

Gesellschaft für Prozeß- rechneranwendungen mbH