The hard drive disk controller will be the limiting factor on most systems depending on the number of tags data logged.
The actual number of tags that can be Data Logged by a SCADA node is dependent on:
· Processor Speed (CPU Speed)
· Hard Disk Access Time
· Processor Load (due to other tasks like scripts, schedules, communications, calculation tags).
· Scan Rate of the Communication Port
A guideline is 500 tags/second for a 1.8 GHz Pentium IV processor. If your Scan rate is every 3 seconds, then you could data log about 1500 tags. Increasing the deadband to reduce the number of changes/second could increase this number of tags data logged. These assume the worse case scenario that there is no deadband or that the tags exceed the deadband every scan cycle.
500 tags/second scan rate
1000 tags / 2 second rate
2000 tags / 4 seconds rate
The use of a deadband will result in recording only significant changes, effectively reducing the number of value changes recorded per scan (and increasing the number of Tags that can be data logged).
If you are Data Logging more than 1500 tags on a SCADA node, you should consider using multiple SCADA nodes or using SAN, NAIS or other Disk Cache to speed up Disk Controller Access times by the SCADA node PC.
Real time trends never store data on the hard drive.
Data Log Trends record Data to the Hard Drive of the SCADA Node.
Log to ODBC (Analog Tag Log, Discrete Tag Log, System Log, Action Log and Alarm Log) record data to an ODBC Database on the hard drive of the Project Node (an Access Database by default, named BwPData.mdb via the DSN named bwPData_Access).
Data Log Trend records 10 bytes per sample on the SCADA node. If you are sampling 1000 tags every 1-second and you are using NO deadband, then it will be:
500 tags * 10 bytes/sample * 1 scan/ sec * 3600 samples/hour * 24 hours/day * 30 days/month * 1/1024 *1/1024 *1/1024 = 12 Gigabytes in a month.
500 tags * 10 bytes/sample * 1 scan/ sec * 3600 samples/hour * 24 hours/day * 365 days/year * 1/1024 *1/1024 *1/1024 = 146.9 Gigabytes in a year.
500 tags * 10 bytes/sample * 1 scan/ sec * 3600 samples/hour * 24 hours/day * 1/1024 *1/1024 = 412 Megabytes in a day.
If a deadband is used, it will be less. If you assume the tags exceed deadband only 50 percent of the time (every 2 seconds), it will be
12 * .5 = 6 Gigabytes / month / 500 tags
146.9 * 0. 5 = 73.5 Gigabytes / year / 500 tags
412 * 0. 5 = 206 Megabytes / day / 500 tags
If a 5 second scan time is used:
500 tags * 10 bytes/sample * 1 scan/ 5 sec * 3600 samples/hour * 24 hours/day * 365 days/year * 1/1024 *1/1024 *1/1024 = 29.4 Gigabytes in a year.
The Maximum file size of an Access Database is 2 Gigabytes.
The Log Data Maintenance feature in WebAccess will archive Data Log Trend files to a network folder or mass storage device AND will ERASE files that are older than a user-defined period on the local hard drive of the SCADA Node. Log Data Maintenance will also archive and delete expired (old) records from the ODBC Log databases on the Project Node. (See Log Data Maintenance for a description of Automatic Archiving and Maintenance of Data Log Trend Files). The Log Data Maintenance will prevent your disk drive from filling up if used properly. In the above examples, if Log Data Maintenance were set for 30 Days would require only 9 Gigabytes of Disk space for data log trend files for 500 tags.
Data Log Maintenance will copy expired Data Log Trend files daily to the archive media. No file compression is used in version 3.0. In the above 500 tag examples:
412 Mega Bytes /day / 500 tags / sec assuming every tag changes every second with no deadband for Data Log Trend files.
Data Log Maintenance will also create Access Database files daily for expired records from the ODBC Logs; up to 6 files daily: System Log, Action Log, Alarm Log, Analog Tag Log, Discrete Tag Log and Text Tag Log, as selected by user. If the SCADA node is off line, then a data file will be created the next day the SCADA node is running at the record time, containing data from the previous day(s).
The minimum size is 64 Kbytes per daily ODBC file. (6 x 64Kbytes = 384 Kbytes / day minimum). The maximum is hard to calculate for System, Alarm and Action Log.
Action Log (bwActionTable - bwPData.mdb) 220 Kbytes / 500 Operator Actions
Alarm Log (bwAlarmTable - bwPData.mdb) 4200 Kbytes / 20,000 Alarms
Analog Tag Log (bwAnalogTable - bwPData.mdb) 29,900 Kbytes / 370,000 Value changes
Discrete Tag Log (bwDiscreteTable - bwPData.mdb) 14,200 Kbytes / 250,000 State changes.
Text Tag Log (bwTextTable - bwPData.mdb) 4200 Kbytes / 20,000 changes.
There is no Archive restore or Playback feature in version 4.0. An Archive restore and playback is scheduled for a future release. Users can manually copy Data Log trend files (second X, minute M and hour H files) back to the SCADA node to view archived data. Archived ODBC files are easily opened using Access.
Typical size of the WebAccess Node subdirectory (WebAccess Program files) for a combined Project/SCADA node is 29 Megabytes.
Typical Size for a WebAccess Client Subdirectory (Program files only) is 6 megabytes.
Typical Size for the InetPub\wwwroot\broadweb subdirectory on the Project Node is 7 megabytes.
You have to make an estimate of the number of graphics on the SCADA Node, Project Node and Clients. Assume 200 Kbytes/graphic, 20 tags per graphic and 300 graphics
300 graphics * 200 Kbytes/graphic * 1/1024 * 2 = 5 Megabytes in /bgr and 5 Megabytes in DRW = 10 Megabytes
Around 32 Megabytes is required for all the default symbol libraries, widgets and system drawing files on the Project Node and SCADA node(s).
The entire Symbols and widgets are not downloaded to the Clients. Only the individual symbol or widget is downloaded to a client if it is requested while using DRAW. Similarly, only the individual Graphic File(s) requested by a Client is downloaded and cached on the Client PC.