ICSS works on industrial communications from architecture design through commissioning and on-site diagnostics. The objective is not merely to establish a connection: measurements, states, alarms, setpoints and commands must be transmitted using the correct representation, consistent quality, controlled timing and safe behaviour when communication is lost and then restored.
This approach combines knowledge of protocols with understanding of control systems and the process. It follows information from the signal or field device through the controller, HMI, historian or dispatching system, and then verifies the actual effect of a command on the plant.
Protocols, networks and systems covered
Work covers the following protocols and architectures:
- Modbus RTU and Modbus TCP over RS-232, RS-485 or Ethernet links between control systems, PLCs, gateways, meters, analysers and auxiliary equipment.
- IEC 60870-5-101, IEC 60870-5-103 and IEC 60870-5-104 for remote control, exchanges with dispatching centres and certain electrical equipment.
- DNP3 and mixed architectures combining several remote-control protocols.
- ICCP/TASE.2 for exchanges between power plants, control centres and energy-management systems.
- OPC and interfaces with historians or data-processing systems such as OSIsoft PI.
- Profibus and communication with analysers, PLCs or third-party equipment.
- ALSPA P320-specific networks and interfaces, including FIP, EPL, F8000, F900, S8000 and Contronet, together with
CSS-F,CSS-Ggateways and associated equipment. - Ethernet networks, firewalls, routers and remote access where they contribute to the availability or security of industrial communications.
This list is not exhaustive. A real architecture frequently combines several hardware generations, multiple suppliers and successive conversions. Diagnostics must then consider the behaviour of every layer, not only the protocol visible at one endpoint.
Design, integration and commissioning
ICSS can define exchanges, implement them in the control system and validate them with the other parties involved. Depending on the requirement, the work includes:
- Analysis of interface documents, point lists, addresses, data types, scales, units, quality information and timestamps.
- Definition of commands, acknowledgements, position feedback, watchdogs and permissive conditions.
- Creation or modification of variables, exchange tables, gateways, function blocks, supervisory logic and operator displays.
- Preparation of simulators, test files or import tools to make repetitive operations reliable and automated.
- Point-to-point tests, command tests, link losses, reconnections, switchovers and returns to normal operation.
- Commissioning in coordination with the dispatching centre, third-party equipment supplier and operations teams.
Diagnose the complete communication chain
An apparent communication loss may originate in wiring, electrical adaptation, a serial port, Ethernet network, address table, incorrect word order, a gateway, controller logic or the system consuming the data. Conversely, a link reported as active may carry frozen values, invalid quality information or commands that are no longer processed by the active controller.
Diagnostics correlate system logs, timestamped events, communication states, Ethernet captures, serial frames, disconnection tests and process observations. Depending on the case, ICSS uses protocol analysers, simulators such as ASE2000, network captures and oscilloscopes to check both the protocol layer and the physical signal.
Redundancy, recovery and data quality
Two interfaces do not guarantee genuinely redundant communication. It is necessary to verify which device is master, which controller accepts writes, how the standby path is monitored and under which conditions it takes over. Values read from a standby controller may remain consistent through internal synchronisation even though commands sent to that same controller are not executed.
ICSS therefore checks reads, writes, validity states, data freshness, watchdogs, master election and automatic recovery after a fault separately. Tests cover the different combinations of interface loss, controller switchover, gateway restart and network reconnection to identify silent failure modes.
Modbus blocks and dedicated tools
When equipment is not correctly supported by existing functions, ICSS can develop or revise the required blocks in ALSPA P320. Modbus blocks have been developed for SINEAX AM3000 and Metrawatt A2000 energy meters, and for AMI pH/Redox, sodium, cation-conductivity and acid-conductivity analysers. They manage the appropriate Modbus functions, sequences of multiple requests, slave detection, fault counters, output validity and recovery after communication loss.
On ALSPA controllers, these developments can integrate with the system block MBEM and the MBSC sequencer to prevent concurrent requests and cleanly share an interface between several devices. Integration goes beyond reading registers: it includes conversion of received words, byte order, signed and unsigned types, single- or double-precision IEEE 754 values, scaling and preservation of the available precision.
At Kwinana, this approach improved communication reliability with several meters and analysers, then processed double-precision energy indexes in a controller without 64-bit real numbers. A conversion library was developed to retain resolution usable by the control system, HMI and PI system without an intermediate calculation degrading the value.
Examples of recent work
Hulu Terengganu: restoring IEC 104 exchanges
At the Hulu Terengganu hydroelectric power plant in Malaysia, the two CSS-G gateways connecting the ALSPA P320 Series 6 system to the national control centre no longer started correctly. Diagnostics showed that points removed from the HMI database remained in the IEC 60870-5-104 configuration files. This inconsistency stopped the gateway processes after start-up. ICSS compared the different database versions, corrected and aligned the files on both interfaces, restored network wiring to the dispatching equipment and prepared validation of the remaining points and parameters requiring alignment.
Sohar 3: analysing Modbus exchanges between ALSPA and Ovation
At Sohar 3, analysis of exchanges between ALSPA MFC3000 controllers and Emerson Ovation revealed several different behaviours behind an architecture described as redundant: reading was possible from a standby controller, but commands were accepted only by the master; communication was lost after online loading; some interfaces did not recover automatically; and the standby path was not continuously monitored. On the gas turbines, the configuration of Hilscher gateways providing bidirectional copying of Modbus TCP registers was also backed up and reverse-engineered to understand the mapping, link monitoring and limitations of the existing redundancy.
Angostura: ICCP coexistence and a new IEC 104 architecture
At Angostura, ICSS analysed data losses and master switchovers on an ICCP architecture used by the AGC, then prepared a new IEC 60870-5-104 chain. A redundant, virtualised ALSPA supervisory system was integrated into the Controcad database, with two gateways, an HMI database dedicated to external exchanges and a signal-list import tool. The added logic separately verifies watchdogs, master identity, power-setpoint freshness and consistency between both paths before selecting the data sent to the control function.
These projects illustrate the same method: understand the effective architecture, reproduce the fault, distinguish network availability from the functional validity of exchanges, and then correct the chain without masking the cause. Further examples are presented on the Projects and case studies page.
Other references
The historical references below complement the recent work:
- Cycofos: diagnostics of the chain connecting an ALSPA P320 Series 5 system to PI over IEC 104, through a
CSS-Ggateway and redundant Matrikon OPC servers. - DK6: extension of OSIsoft PI exchanges from 2,000 to more than 10,000 points.
- Los Humeros: design, testing and commissioning of a redundant dispatching link combining
OPC,IEC 104andDNP3. - Kwinana: redundant
DNP3link for remote load control, diagnostics of Modbus exchanges with the supplementary firing system, and integration of new Modbus equipment. - GTX and CCPP22: implementation of load control from the dispatching centre over IEC 104.
- Kureimat: diagnostics of Modbus and
IEC 101links, and implementation of cybersecurity measures. - Terga and Flevo: diagnostics of exchanges with the
EgatrolandTurbotrol turbine controllers through ALSPA gateways. - Tzafit: resolution of communication problems with various PLCs and third-party equipment during commissioning.
- Niehl III: interfaces over
Profibuswith analysers,Modbuswith another unit, andIEC 101with the dispatching centre, automated exports and network security improvements.
Expertise particularly suited to ALSPA P320
In-depth knowledge of ALSPA P320 makes it possible to work simultaneously on the Controcad database, controllers, communication blocks, ALSPA HMI, gateways and legacy networks. ICSS can trace the origin of an exchange, modify its generation, develop missing processing and check its propagation through the complete system. This expertise is equally valuable when ALSPA must communicate with Emerson Ovation, Siemens, ABB, Schneider, dispatching systems or specialised equipment.