With some advanced drivers, the scan process differs slightly to that documented within this section. For example, some drivers can broadcast messages at the beginning of a System Scan. Where scanning by a particular driver differs, any differences are explained in the driver-specific documentation.
With direct communications—such as when an outstation communicates with ClearSCADA via a network, radio, or cable connection—a permanent connection is maintained between the ClearSCADA server and each outstation.
For systems that do not use independent connections the server scans one outstation after another on each channel, starting with the outstation that has the lowest address. When the server makes a request for outstation data, it typically establishes communications with the outstation that has the lowest address on that channel. Once the outstation has reported its data, the server requests data from the next outstation on the channel. Once the server has scanned (polled) each outstation in turn on a particular channel, it repeats the whole process, starting once again with the outstation that has the lowest address.
The actual scanning process varies, depending on the protocol. With direct outstations on many advanced drivers, scanning is typically achieved using two scan phases. With many advanced drivers, the driver typically scans each of the outstations on a channel for current data (the Primary Phase of the scan). When each of the outstations have been scanned, the driver then typically scans the outstations again, this time for secondary (logged) data (the Secondary Phase of the scan).
The complete process (retrieval of both current and logged data) is referred to as a System Scan.
The exception to this process is when the ClearSCADA server has not been in, or has regained, communications with an outstation. In such circumstances, the driver typically performs an Establishment Phase scan in place of a Primary Phase scan (see Establishment Phase).
The purpose of the two-phase scanning method is to retrieve the latest data quickly, while helping to prevent those outstations that have a lot of data to report from dominating the communications on a channel.
Normally, system events will primarily be detected during current data extraction, with retrieval of event logs and timed logs (buffers) having secondary importance.
This example illustrates a typical system where the outstations are not independent. A driver scans four outstations that are using a direct channel to communicate with the server. It scans the outstations in ascending address order, starting with the lowest address (in this case, Address 3).
It scans each of the outstations in sequence for current data. This is known as the Primary Phase of the scan.
As each outstation has differing amounts of current data, the time taken to scan each outstation differs.
Once the current point data has been retrieved from the four outstations, the driver scans the outstations for any logged data. Again, the amount of logged data varies per outstation and as such, the amount of time that the driver takes to scan each outstation differs. This part of the scan is known as the Secondary Phase.
For each driver that uses direct communications on your system, you need to specify the frequency with which the driver is to scan each outstation for current data and / or logged data. Depending on the protocol, you specify the required data retrieval or scan intervals on either the Channel Form or the Outstation Form (see the driver-specific documentation for details).