Historical Synchronization

The task of the historical Synchronization is to transmit selective historical data, which are written to the database (Oracle) of the locale system (subsystem), to the central database of the central system within a narrow time frame using a database connection. The subsystem or several subsystems and the central system together form a distributed system.

This requires that:

  • All subsystems and the central system use RDB archiving.

  • The relational databases of the central system and of the subsystems have the same schema user name and password in order for the database link to work properly.

  • All archive groups from subsystems also exist at the central system and the names are identical.

  • An installation of the historical synchronization has been performed.

There is a hierarchical structure of the involved WinCC OA Systems. The configuration takes place at the subsystem level, whereby a configuration at the central system level is also necessary. Subsequently the subsystems establish a local connection to the central system, which summarizes all subsystems' data at the central system level (see figure below).

Figure 1. Architecture

In order to make a consistent data transmission to the central system possible, all needed configuration data for a value is synchronized. That means that a data point element together with the data point, data point type and system (to which the value belongs to) is created in the central system by the subsystem. The definition of the archive parameters (online time, maximum size and number of archives, storage size, periodic control of archive switch-overs) is not synchronized because it is intended, that these configurations can differ on the systems. So for example, the local archiving can be limited to 1 week of data - at supervisory level, the data will online be stored for 1 year.

The synchronization is always initiated at the subsystem, never at the supervisory system. The synchronization operation runs in the background. Synchronization can be either triggered automatically, which is the default, or manually. Manual mode may be useful, if the system has a heavy network load after reconnecting, thus the operator can wait for the system to reach a stable state (e.g. switch back from low bandwidth link to high bandwidth network), and then start the synchronization manually. This way he can assure that the bandwidth needs of the synchronization will not effect the normal operation of the system.

A synchronization of archiving at the central system is not supported. Historical data is only written on the subsystems. All data, which the central system receives, comes by synchronization from the subsystems.

Selection of data for synchronizing

The archive group of a data point element defines whether the values of the data point element are forwarded to the central system or not. Thus, the data point elements have to be selected and grouped accordingly. Grouping takes place in WinCC OA as follows:

  1. Select an existing archive group, whose data shall be forwarded to the central system, or create an new archive group for this purpose (see RDB archive group settings).

  2. Configure the archive group at will (see Configuration). Thereby it is important that the Forwarding check box is ticked.

  3. Open the WinCC OA PARA and add an _archiveconfig to these data point elements, whose values shall be forwarded.

  4. Select from the combo box of the archiving panel this archive group, which was selected/created in step 1.

Alarms

The is an important restriction with alarms. There is only one alarm group in any WinCC OA system, you cannot create further ones. Therefore you can only decide to transfer all alarms or none. There is no possibility to select some alarms to be transferred, some not.

Normal operation at a site

RDB writes the historic data in bulks into the database.

  1. Every bulk gets a bulk-ID and is written to the status table. The bulk-ID is needed for recovery in the case of failure and is - combined with the system-ID - globally unique.

  2. All updates or inserts on the elements as well as removal of elements are communicated to the center database, if the elements belong to a group with ticked Forwarding checkbox (see Configuration). If there is any trouble with the network connection to the center, the data will wait in the queue till the connection is open again.

  3. All alarms and values coming from WinCC OA are first inserted into the local history tables and then also moved to a queue from where they are sent to the center database, if they belong to a group where forwarding is set.

  4. The site marks the transmission as done or as failed. The subsystem writes the corresponding status to its own synchronization status table as well as to the table of the central system.

Operation in the case of failure at a site

If the connection between subsystem and central system is lost, the data are collected at subsystem level. After reconnecting the central system, the data will be synchronized from the subsystem to the central system (up to the specific maximum archiving time implicitly defined on the subsystem, e.g. 1 week). Usually the synchronization starts automatically. As the system will have a heavy network load after reconnecting, the synchronization can be also started manually giving the normal operation of the system high priority.

Any time interval where there is no connection to the supervisory system is recorded on the subsystem. After reconnection the automatic synchronization starts automatically. After completion, the corresponding entry is deleted (or marked as already transmitted).

Failed Transaction

  1. All data, which was tried to be forwarded, can be still found in the queue. From there transmission is tried again regularly until it will succeed. A database job is responsible to reactivate these failed transmissions.

  2. In the synchronization table the bulk is marked as failed, which implicitly means that it is "still to be sent".

  3. The job regularly tries to re-send data. The shorter the job interval is defined (which happens during setup), the sooner a job will detect a fixed connection.

  4. All data that has been written into the LASTVAL-table and to the queue are sent to the other site. On success the queue is emptied.

  5. In the case of successful transmission the normal operation is to be continued.

Error detection and synchronization are carried out automatically.

If the connection between the subsystem and the central system was interrupted during the data transfer, a lock is set and the following error message in the log viewer is issued:

PVSS_II.log:WCCOAui (1), 2009.07.01 12:44:35.936, CTRL, SEVERE, 76, Invalid argument in function, Error in the Query!, ORA-01591: Sperre wird von unterbrochener, verteilter Transaktion 6.23.223960 aufrecht gehalten.

Normally, the lock is released as soon as the connection can be re-established. If this is not the case, the following must be done:

1. Query the Pending Transaction with "SELECT FROM LOCAL_TRAN_ID DBA_ PC_PENDING";

2. Rollback of the Pending Transaction with the found transaction ID, for example: rollback .8.178692 force '1 ';

Operation at the central system

Every site writes its data to the central system. There is no need for a database link from the central system to the subsystem, as all traffic is initiated by the subsystem, the center only operates in a passive way.

Manual synchronization

It is possible to turn the automatic synchronization off, which means that the job never empties the queue. Automatic synchronization is the default, manual synchronization is only needed in exceptional cases.

In the Synchronization Panel at a site (subsystem) the user can trigger synchronization manually provided that automatic synchronization is turned off.