There are many good open source packages for this purpose, but in this case I had already available Windows machines, so the natural choice was MSMQ.Ĭitect offers a feature called AlarmQueue. A SCADA application is usually quite heavy as it is normally required to process data in a real-time fashion, which doesn’t line up well with remote database interactions which are normally accepting asynchronous patterns and discontinuous access.Ī good choice in cases like this is binding the data source with an asynchronous queuing service, which offers high availability and manages the burden of the remote transactions as delegate. To avoid the problems found with the standard implementation, I had clear that it was necessary to avoid charging Citect with an expensive remote ODBC interactivity. The network environment is not the most straightforward, including VLAN routing and inter-domain connections.Īfter a few weeks of operations, the solution has been decommissioned as the results were unsatisfactory. This standard implementation proved to be quite problematic, especially due to the insufficient performance of the ODBC connection to a remote SQL server against the necessities of a live SCADA instance. This is the Citect standard way to transmit alarm events to SQL server. In all Citect servers, a new SQL device has been created and linked to the database through an ODBC connection.A new Database named CitectAlarms has been created in the DT, containing the desired tables.The saved alarm record scheme needs to contains at least the following fields:Īs first tentative, the easiest way has been tested. This computer is the data target (DT).Ĭollect in DT all the alarms generated by DS in real-time. Citect SCADA servers: 5 Citect 7.2 and 7.4 Citect servers, divided in 3 clusters with two Primary/Standby couples.The system where the application runs is composed by several networked computers with the following roles: In this and the next post I am going to present an application I developed to build such a long term database for Citect Alarms, without purchasing external packages but using only Citect, Windows and. This data is then available for post analysis or reporting purposes. The main feature of these packages is the ability to connect to field data sources, including SCADA, and maintain a long term database of significant process points or alarm events. SCADA application, though, are tailored for short term purposes, so that a new class of applications appeared in the market to overcome this limit. All SCADA packages provide trending and alarm management features.
Often production and reliability departments have the necessity to go back in time and analyse past process data.