Our initial contact with SCADA systems was through Advantech's VisiDaq software, in combination with input/output (I/O) devices connected to a Bus. This particular approach treated the I/O devices as signal sources, executing serial read and write cycles across the entire list of devices, with limitations on the maximum communication time both per device and for the overall cycle.

Although the stability of the Bus could be affected by various factors, causing anomalies, the signals eventually reached the computer. There, through the software, each signal was routed either to a Script Block for further processing or directly to a graphical element for visualization.

The graphical control elements could be linked to Script Blocks, other elements of the graphical user interface, or directly control a device's output. Correspondingly, the outputs of Script Blocks could feed into other Script Blocks, graphical elements, or device outputs.

This primitive form allowed for the creation of systems with a limited volume of signals, due to the overhead of the communication cycle between devices and the computer. Despite the difficulties, this approach proved that using a computer for implementing automation and SCADA can be just as reliable as solutions based on programmable logic controllers (PLCs).

It soon became apparent that off-the-shelf software packages were excessively bulky, with a plethora of features that were often unnecessary. They presented usability issues, hardware dependency, and bugs that could not be immediately fixed, while upgrades or patches could render an installation non-functional.

These problems highlighted the need for the development of independent software, tailored to the actual requirements of each project.

The implementation of our solutions in Santorini was a decisive step in identifying latent risks and effectively addressing them. Despite the presence of 2kV optical isolation on the device inputs and efforts at electromagnetic shielding for protection against lightning strikes, the essential solution was achieved through a combination of varistors and fuses. Varistors, under normal conditions, exhibit high resistance, which drops drastically when the applied voltage exceeds a predetermined threshold, causing a short circuit. Although this protects the device, it could potentially destroy the cable or the sensor. For this reason, a circuit was designed that allows for normal operation, while in the event of an overvoltage, it causes fuses to blow, safely interrupting the circuit.

This approach made the devices resilient to storms, limiting damage to easily identifiable and replaceable fuses. This enhanced protection increased the complexity of the materials per signal input, with additional connections and wiring in the panel. Recognizing the need for standardization in a timely manner, an integration board was designed and manufactured to incorporate all the necessary voltage distribution and protection circuits, reducing the internal panel wiring to fewer than 30 connections. At the same time, external connections were standardized using detachable terminal blocks.

Another critical issue that was addressed was the absence of a true earth ground in the installations, with the ensuing challenges due to potential differences relative to an undefined reference point. Furthermore, the harsh weather conditions, corrosive environment, volcanic activity, high sun exposure, temperature, humidity, and dust are significant factors that could potentially affect the system's operation. For all of these, appropriate prevention and protection measures have been taken.

While searching for modern approaches to device interconnection, it was found that using networks with TCP/IP support resolves the problems of Bus-type connections. Signal collection via an OPC Server offers the ability for simultaneous communication with multiple devices in a short amount of time. However, the use of TCP/IP (e.g., Modbus/TCP) in combination with an OPC Server did not prove sufficient for devices with a potential for connection loss, such as wireless ones, especially concerning the automatic management of disconnection and reconnection.

Although serial communication over TCP/IP with one device at a time offers stability and bandwidth savings, the goal remained simultaneous, parallel communication. Thus, it became clear that the management and restoration of communication had to be fully controlled by the software, using multi-threaded processing. This approach proved to be particularly effective in the simultaneous management of I/O devices.

Leveraging the capabilities of modern networks (Ethernet, Wi-Fi, fiber optics, VPN, Bridging, Routing, etc.) allowed for the creation of stable and scalable structures, with the ability to connect a large number of devices over extended geographical areas.

During the development of SCADA systems, the need arose to unify the management of inputs and outputs, regardless of their origin, under the general concept of "signals." This approach allows for software reuse for the efficient processing of a large volume of signals. PLCs process signals as data structures, applying logical and mathematical operations.

Ultimately, signals represent physical quantities in an electrical form. The first necessary action is the conversion of electrical values into physical units of measurement. The signals are classified into states based on levels (e.g., Very Low, Low, High, Very High), creating five distinct states. This categorization allows for the automatic triggering of events and the visual representation of states through a color scale or animation.

By defining five time delays (one for each state), a signal that remains in a specific state for a predetermined time can automatically trigger a sequence of actions. Thus, without the need for programming, it is possible to create SCADA and automation at the level of a physical quantity or state, simply by filling in parameter tables.
 

In the context of investigating the operation of programmable logic controllers, PLC emulation software was developed and integrated into the system. For experienced users, a scripting capability in STL or JavaScript is available. The scripting system functions as a virtual PLC, with the SCADA signals as its inputs and outputs.

Each signal is available as a raw value, as a transformed physical value, and as a logical state, based on the defined thresholds. The scripting outputs can directly control devices or other SCADA signals. The system takes into account the connection status of the devices, avoiding the execution of commands on unavailable devices. Additionally, the devices themselves can execute safety actions through their own logic.

Just like a physical PLC, the software PLC (SoftPLC) executes the code cyclically, with faster cycles than the SCADA, ensuring immediate response. A simple computer can manage complex scenarios, while additional software controllers, such as signal integrators, timers, and PID controllers, have been incorporated into the SCADA environment.

The basic philosophy behind the integration of each subsystem is to balance simplicity and complexity, guided by functionality and the avoidance of redundant elements. In the early versions up to 6.0, the choice of a simple and strictly necessary web subsystem ensured the required stability and security. However, the growing user demand for more features, without sacrificing usability, led to the development of a more advanced embedded HTTP Server.

The new server supports modern responsive design technologies, allowing seamless access and interaction with the system from any device—be it a mobile phone, tablet, or desktop computer. This approach enhances interoperability and accessibility, while maintaining the unified software architecture, without dependencies on external packages or third-party platforms.

The integration of web capabilities into the SCADA system is not limited to data presentation but extends to management, supervision, and remote configuration, offering a complete and flexible operating environment for the end-user.