How do you test and validate the functionality and performance of a DCS system?

The most efficient way of testing DCS engineering is to create a simulation model that represent the field and emulate all DCS hardware with virtual entities. Now with the real DCS engineering, it is possible to do FAT / SAT / Pre commissioning and subsequently operator training and further to operation optimization. This set up also helps when one migrate the DCS to the next upgrade version or undertakes plant modification / expansion. SIMIT in one such software which provides emulated hardware for Siemens brand control system such as Simatic PCS 7 / PCS neo / TIA portal and a field behavior of devices and processes thus enabling virtual commissioning.

Simulation testing is a very important milestone for DCS upgrade or even testing a simple control logic/strategy. The simulation testing is a safe way to ensure the engineering integrity of the developed control logics. Simulation has to be done in stages. First comes the cold simulation in which DCS hardware is checked in isolation, real time scenarios are simulated for redundancy checks, IO Bad fail, Alarm anunciation etc. For the critical control loops we then use the end to end approach for a hot simulation wherein the complete loop is simulated end to end using mA source at the field end. This way each and every component is tested from the sensor right to the HMI. Simulation should be made part of MOC procedure and PSSR.

The reputable DCS OEMs provide Simulation (Soft Controllers) or Test Mode before assigning production licenses or even offer Virtual Machines depending on project size and commercial agreement. It helps System Integrators to do programming before delivery of DCS hardware which usually take couple of months.

Simulations create a virtual environment to mimic real-world scenarios, allowing you to observe how the system behaves under various conditions. For instance, simulating emergency shutdowns or extreme process variations helps verify if the DCS responds as expected. This ensures that the DCS can handle complex situations without compromising safety or efficiency.

FAT of DCS can be segregated into four different stages as below. 1. Hardware Verification Test: In this test, validation of each components of DCS includes Controllers, Firewalls, IO Cards, FTA, Barriers/Isolators, Power supply(AC/DC), TBs, PS, Cabinets.& Consoles 2. Hardware Functional Test: This test includes redundancy of Controller, IO cards, IO link, firewall, Battery Back-up, Power supply, Controller loading, network load, scan time, sync., Communication test, etc. 3. Process field devices / Loop test: It includes checking of Wiring, Loop, Signals, Isolator/Barrier/relay wiring, Earthing, Alarms & ranges. 4. Logic Check: Checking of all logics in the DCS based on the Control narratives, Schematics & descriptions. Graphics & etc.

I use Excel based sheets for carrying out FAT following best practices and IEC 62381. Testing includes: - AI/AO/DI/DO Testing or can be instrument specific such as PID Loop, Analyzers, Shutdown Valves, Motors - Network Testing - DCS Workstations - SIS loop (Cause and Effect) - Functional Test (HMI Graphics, Faceplates, Alarms, Trends, Setpoints etc.) - Impact of Controller, Power Failure - Punch List and there can be more things depending on Master Documents Register (MDR). SAT is also most same except it is done on site and more of testing live instruments, integrating with 3rd party packages.

FAT (Factory Acceptance Test) is carried out in order to demonstrate that the system and its components function properly, that manufacturing, assembly, configuration and software generation are done correctly and that system performance is in compliance with the approved functional specifications and relevant documents. The same should be also carried out for DCS.The main objective of the FAT are normally carried out during the final part of the design and engineering phase before the final installation in the plant. During FAT customers can “touch and feel” the equipment while it is in operational mode before it ships.

FAT/Factory acceptance test is an important milestone in any Automation project particularly DCS. Factory acceptance gives the end user an opportunity to assess the system provider's supplied items. For a DCS it may be divided in the following: 1) Hardware Checks & Functional testing; 2) Quality inspection of control/marshalling cabinets and wiring; 3) Power Supply and Redundancy test; 4) Approved BOM verification 5) Software recovery and restoration tests 6) IO testing of Control loops 7) HMI verification 8) Verification of consoles and associated anunciator panel 9) Network devices and firewalls testing 10) Cybersecurity Implementation checks 11) Access control verification at pre defined levels. 12 Cabinet grounding/Earthing system test

SAT is carried out as: - FAT completed - Proper installation (all system components including controllers, I/O cards, marshalling racks, power supplies, Operating/Engineering stations/Server, Network Switches) - Automation system powerup and download of correct software including SAT Plan/Schedule, Report, and Punch List documents. Mostly Contractors/System Integrators perform FAT/SAT/SIT using pre-approved checklist following SOPs, Vendor Manuals and best practices (IEC 62381).

SAT or SITE Acceptance test as the name suggests is a thorough verification that is conducted at the end user site once all DCS installation has been completed. This is an opportunity where end-user can perform thorough inspection of the system in connected state. This includes end to end wiring checks, field devices communication, power and earthing checks, loop verifications. The purpose of FAT is to validate DCS installation with respect to the design specifications. A well designed and documented SAT on the other hand ensures that how the system will perform in the real plant environment.

SAT is a test that is conducted at the plant after the installation and inspection of the DCS components. The purpose of the SAT is to verify that the DCS components function properly in the actual plant environment and interface correctly with the process equipment and instruments. This test is consists of four main parts : (1) Inspection & testing of DCS Hardware (2) Testing of DCS application software. (3) Inspection & testing of DCS marshalling cabinets & consoles (4) Integration test with various package PLC systems.

The team in charge of Factory Acceptance Testing (FAT) of a Distributed Control System (DCS) is made up of Quality Assurance (QA) specialists, systems engineers, test technicians and often includes customer representatives. This collaboration is essential for a detailed assessment of the DCS, ensuring compliance, performance and alignment with customer expectations prior to implementation. The involvement of cross-functional experts is crucial to address technical, operational and usability aspects during the TAF process. Expert knowledge of the process plays a key role at this stage.

SAT is, generally speaking, repeat of FAT at the customer/client premises. In brown field projects where the existing/old system is in operation, SAT proivdes an opportunity to test and validate the new system before it is put in service. In addition, this activity provides direct comparison with the existing control philosophy, verify if it is replicated in new system and allows the project team to fine tune. Some important aspects related to SAT include: Control/rack room space allocation, power distribution, preparation & hookup of test panels, implementation and testing of approved modifications, 3rd party hook-ups (BOP PLCs, Gov, etc.), cybersecurity measures (if remote control is required by Vendor) and patches/updates installations.

Loop testing shall be done in order to check , whether the required signal is terminated at required terminal, whether that terminal is connected to correct card, installed at correct chasis and tag is configured at correct channel. Whether the configured tag in control system is giving response as desired with correct alarm and tripping points with exact control or trip functions. Loop checking shall be done from the field by simulating the instruments and check its response on the operator station.

Loop testing focuses on individual control loops within the DCS. By isolating and testing each loop independently, you can identify and address issues related to control algorithms, instrumentation, and feedback loops. This could include verifying the accuracy of sensor readings, the responsiveness of actuators, and the overall stability of the control loop.

To run all the functionality tests according to the Sequence of Operation or the Functional Description of the system, a SAT test procedure or an Operational Qualification (OQ) test document should be prepared. This OQ includes the description of the tests, the expected results, and the units where the test must be carried out. The OQ document must be a standalone document so the people who carry out the test don’t need any other technical documentation such as P&IDs, Functional Description, and electrical drawings. The professionals who run the tests check the related checkboxes when a test is done. A tracker can be also added to the OQ to estimate the remaining time of the tests.

Functional testing of a Distributed Control System (DCS) is a crucial step to ensure the system operates correctly and safely. It involves verifying that the DCS performs its intended functions as specified in the design requirements. Some typical functional tests conducted on a DCS include: 1. Control Logic testing. 2. Sequence testing. 3. Alarm testing. 4. Operator interface GUI testing. 5. Communication testing.

conduct functional testing to ensure that each component of DCS system perform its intended functions. it will include testing of controllers, I/O modules, networking etc..

Component testing is the way to identify the issues at the module level, so defects are captured at the early stage for each module and hence reduces the efforts of both developers and testers while testing the entire application

DCS functional test is an important milestone and is normally executed during SAT. Key steps to consider in DCS functional testing are: 1) Document and Test Plan development; 2) Establishment of a controlled test environment that could closely simulate the actual operating conditions wherever possible. 3) Hardware testing 4) Redundancy and Failsafe testing 5) 3rd Party communication testing 6) Control loop/logic testing and simulation 7) Display verification on HMI and Alarm management checks 8) Verify that logging, historization is being done as per configuration 9) Control loop tuning checks 10) Scenario tests (Startup/Shutdown/Normal Plant/Emergency) 11) Response time testing to command and inputs where applicable.

These days control system needs continuous testing without interrupting the operations of any production plant. Therefore Distrubuted Control Systems may also need a Continuous Condition and Control Monitoring System (CCCMS) to test its functions. The CCCMS can be used to test LOOPS, FUNCTIONS, PERFORMANCE and SELF DIAGNOSIS upto modules level testing to detect faults as early as possible. If a redundant system is installed and a fault may be diagnosed in a system then the CCCMS can be used to take decision to switch operations towards that other redundant system seuqentially as per design and logic to prevent outage and production of the Plant.

DCS Performance is a crtical design input which is defined by client in RFQ (e.g., loading of controllers or CPU idle time) and finalized in Functional Design Specification (FDS). Important thing to remember is that Performance of the marshalling components is equally important to test. These tests may include: CPU loading, IO loading, behaviour/Performance in case of failure of a redundant CPU/IO Module, power supply loading and redundancy checks, network loading and redundancy, HMI Performance with 3rd party software (e.g., AV, Office etc.), data reterival from Historian by multiple clientn impact/Performance in presence of cybersecurity hardware (e.g., Firewall, IPS/IDS or UTMS) etc.

One important area you have not covered is Alarming. Alarming can drive an operator crazy but it usually should save him. Alarms should be tracked/logged automatically, when it came in, when it was acknowledged and when it went away. ( Log also if it was masked) Balance has to be found between a sufficient number and too many where the operator is always in alarm and misses an important alarm.

Consider conducting a detailed HAZOP before finalising the DCS control engineering philosophy. A multidisciplinary team comprising of process, operations staff and control engineers should be formed to identify potential hazards and operational problems that could be introduced through DCS functioning. These may include risks such as instrument failure, IO Bad philosophy, burnout selection, communication failure, cybersecurity breach, alarming etc. Analyze the existing safeguards and suggest additional control measures in case of identified gaps. Validate all these measures during the DCS testing phase.

there are a lot of area that we can add here like integration testing, component testing, network performance testing, redundancy testing, security testing, alarm and event testing.

Once the control loop has been checked, started up, commissioned, and tuned, it is time to establish the baseline performance benchmark. Also, since control loop performance will degrade over time due to process changes, valve performance issues, and loop tuning changes, for example, it is beneficial to check the loop performance periodically. In addition, this “performance history” can be helpful when setting up predictive maintenance for your critical loops.