A method and system for validating equipment and process behavior in a technical installation

Abstract

The present invention generally relates to the field of industrial automation and process validation, and more particularly relates to method for validating equipment and process behaviour in technical installation. The method includes receiving one or more signals and input data corresponding to equipment and technical installation, from input data sources. The method includes generating test logics using plurality of action blocks, using the received signals and test data. The method includes creating test types using pre-defined test actions, based on the generated test logics. The method includes creating, one or more test sets (902c) using created test types, by arranging each of test instances in pre-defined order. Method includes validating test sets (902c) corresponding to the equipment and technical installation. The method includes receiving executing test scenarios and generating report comprising test results comprising individual results and aggregated results for test sequences and plurality of test instances.

Description

[0001] A METHOD AND SYSTEM FOR VALIDATING EQUIPMENT AND PROCESS BEHAVIOR IN A TECHNICAL INSTALLATION

[0002] Description

[0003] The present invention generally relates to the field of industrial automation and process validation, and more particularly relates to a method for validating equipment and process behaviour in a technical installation.

[0004] Technical installations, such as industrial plants and automation systems, may comprise a wide array of interconnected equipment, controllers, and communication interfaces that may need to operate in a coordinated and reliable manner. Prior to deployment or during maintenance cycles, it is critical to validate the behaviour of such equipment under simulated or real operating conditions to confirm functional correctness and safety compliance. The validation process typically involves testing each piece of equipment integrated into a simulation platform to confirm correct responses to defined input conditions and expected outputs.

[0005] Testing each equipment integrated into a simulation platform of an industrial plant is an inherently intricate and labour-intensive process. The process requires a high degree of precision and a significant investment of time, as each equipment may need to be individually validated to ensure operational integrity within the industrial plant. Such validation typically involves assessing the response of the equipment to various combinations of input and output (I / O) signals through the manual execution of multiple test scenarios. These tests may require repetition under diverse conditions to verify consistent functional behaviour, which increases the likelihood of human error. Such errors introduce additional complexities and adversely impact the reliability and credibility of the test results.

[0006] Furthermore, the manual nature of testing process results in insufficient documentation of test activities and outcomes. The absence of a systematic approach to record and track test results leads to challenge in generating comprehensive records. The lack of deficiency in systematic documentation limits the ability to perform consistent analysis of test data, identify recurring faults, and detect underlying patterns indicative of systemic issues. Conventional testing methods are typically customized for individual equipment, with corresponding simulation conditions tailored accordingly. The results of such tests are manually recorded using checklists, which is not only time-consuming but also susceptible to inconsistencies, omissions, and human error. Moreover, the conventional manual testing approach imposes limitations on the efficient review and analysis of test data, as the resulting information may not readily aggregable or comparable across multiple test instances or equipment. This lack of data consolidation makes it difficult to maintain a comprehensive overview of equipment performance and hinders timely identification and resolution of operational issues. As a result, the overall effectiveness and efficiency of the testing process are reduced, which may adversely affect the quality assurance and operational reliability of the automation infrastructure within the industrial plant.

[0007] In light of these challenges, there is a need for a method and system for validating equipment and process behaviour in a technical installation.

[0008] Therefore, it is an object of the present invention to provide a method for validating equipment and process behaviour in a technical installation.

[0009] The object of the present invention is achieved by a method for validating equipment and process behaviour in a technical installation. The method comprises receiving one or more signals and input data corresponding to at least one of an equipment and a technical installation, from a plurality of input data sources. The plurality of input data sources comprises at least one of a distributed control system, a simulation subsystem, and data transmitting devices. The distributed control system computerized control system used in industrial settings to monitor and control equipment and processes across multiple locations within a facility. The distributed control system typically includes controllers, sensors, and software to manage operations. The method comprises generating one or more test logics using a plurality of action blocks, using the received one or more signals and test data. Each of the one or more test logics is associated with a plurality of test instances, each test instance comprises one or more test parameters used in the one or more test logics for a run-time value substitution. The test logics refers to the set of rules, conditions, or algorithms designed to evaluate or validate a system or process. The action blocks are modular components or predefined functions that represent specific operations or tasks within the test logic. The method comprises creating one or more test types using pre-defined test actions, based on the generated one or more test logics. The one or more test types are created to simulate and validate one or more operational scenarios of the at least one of the equipment and the technical installation. The method comprises creating one or more test sets using the created one or more test types, by arranging each of the plurality of test instances in a pre-defined order to form one or more test sequences for test execution. The method comprises validating the one or more test sets corresponding to at least one of the equipment and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution. The method comprises executing a plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets. In addition, executing the plurality of test scenarios comprise managing one or more errors detected during the test execution. The method comprises generating a report comprising one or more test results comprising individual results and aggregated results for the one or more test sequences and the plurality of test instances.

[0010] In a preferred embodiment, the method comprises receiving a request for a project creation to initiate a testing process. The method comprises establishing a connection with the plurality of input data sources via a coupling feature for exchanging the one or more signals using one or more protocol. The method comprises obtaining the one or more signals from each of the plurality of input data sources via the established connection.

[0011] In another preferred embodiment, the method comprises managing a testing process by triggering the plurality of test scenarios within the plurality of action blocks. The method comprises orchestrating execution of the one or more test sequences, based on the managed testing process. The orchestration comprises managing a sequence of operations of the one or more test sequences. The method comprises monitoring an execution of the one or more test sequences in real-time. The method comprises displaying intermediate test results on a display, based on the monitored execution of the one or more test sequences. Test Sequences: Ordered sets of test scenarios or actions executed in a specific sequence to achieve a testing objective. The test sequence refers the flow or progression of tests to be performed.

[0012] In another preferred embodiment, the method comprises processing the intermediate test results, by formatting the intermediate test results into a structured output format. The structured output format comprises at least one of logs, performance metrics, and at least one of pass status and fail status of the intermediate test results. The method comprises storing in a database, one or more test outcomes of the executed one or more test sequences in a plurality of formats.

[0013] In another preferred embodiment, the method comprises monitoring execution of the one or more test sequences. The method comprises validating the one or more test parameters with one or more pre-defined thresholds values. The method comprises validating the one or more signals and the one or more test parameters during the test execution to confirm correct configuration and functionality of the test execution. The method comprises testing iteratively the one or more test sequences, through a feedback loop based on one or more test outcomes. The method comprises modifying the one or more test parameters and the one or more operational scenarios associated with the one or more test sequences, based on testing the one or more test sequences.

[0014] In yet another preferred embodiment, the method comprises monitoring execution of the one or more test sequences. The method comprises validating the one or more test parameters with one or more pre-defined thresholds values. The method comprises validating the one or more signals and the one or more test parameters during the test execution to confirm correct configuration and functionality of the test execution. The method comprises testing iteratively the one or more test sequences, through a feedback loop based on one or more test outcomes. The method comprises modifying the one or more test parameters and the one or more operational scenarios associated with the one or more test sequences, based on testing the one or more test sequences. Further, the feedback loop refers to a mechanism where the outcomes or results of a test iteration (e.g., pass or fail, errors, performance metrics) are analysed and used to inform subsequent test iteration.

[0015] In yet another preferred embodiment, the method comprises orchestrating the execution of the one or more test sequences. The method comprises executing the one or more test sequences in at least one of a manual mode initiated by a user and a scheduled mode at predefined times. The method comprises managing substitution of one or more parameter values during execution of the plurality action blocks. The method comprises identifying one or more parameter fields in the plurality action blocks. The method comprises substituting one or more pre-defined values for each of the plurality of test instances, based on the identification.

[0016] In still another preferred embodiment, the method comprises generating a first user interface for coordinating an exchange of the one or more signals from a coupling partner associated with the one or more input data sources. The first user interface displays the plurality of action blocks. The method comprises generating a second user interface for generating the ore more test logics and creating an executable plurality of test instances corresponding to the one or more test parameters. The method comprises generating a third user interface comprising a tree for the one or more test sets, a work area, a tree for the plurality of test instances, and a scheduler for planning execution of one or more test sets. The scheduler is a component in the third user interface that allows users to plan and manage the timing or sequence of test set execution, ensuring tests run according to a defined schedule. Furthermore, the method comprises managing errors. Further, the method comprises detecting at least one of communication errors and validation errors during the test execution. The method comprises receiving feedback from the user to correct the errors before proceeding with the test execution.

[0017] In yet another preferred embodiment, the method comprises the plurality of action blocks comprises internal variables, test instance parameters, basic modules configured to perform functions comprising setting and reading signal values associated with the one or more signals, advanced modules configured to perform functions comprising signal tracing and conditional branching of the one or more signals, and remote control interface modules configured to manage interactions with a simulation environment. The basic modules are components within action blocks designed to execute fundamental operations, such as setting and reading signal values. The advanced modules are components within action blocks that perform more complex operations, including signal tracing and conditional branching. The remote-control interface modules are components that enable communication and interaction between the action blocks and an external simulation environment, enabling control, monitoring, or data exchange with the simulated system.

[0018] Furthermore, the method comprises the basic modules are further configured to perform functions comprising at least one of pausing execution for a specified time, pausing execution until a condition is met, verifying conditions, verifying conditions over a specified period, and resetting signals to an initial state.

[0019] In yet another preferred embodiment, the method comprises the advanced modules are further configured to perform functions comprising at least one of tracing signal values at intervals, stopping signal tracing and storing aggregated values, prompting user acknowledgment, writing data to a file, executing conditional branching based on a condition, looping execution until a condition fails, and setting signal values for a specified duration.

[0020] Furthermore, the method comprises the remote-control interface modules are configured to perform functions comprising at least one of creating a snapshot of a simulation environment, loading a snapshot, adjusting simulation speed, and setting a simulation state. The remote-control interface modules are hardware or software components configured to interface with a simulation environment, enabling control through external systems or user-initiated commands.

[0021] In yet another preferred embodiment, the method comprises the plurality of input data sources comprise at least one of programmable logic controllers, human-machine interface systems, supervisory control and data acquisition systems, field instruments, input / output modules, industrial networks, process equipment, safety systems, historian databases, remote terminal units, programmable automation controllers, process measurement meters, and digital simulation and visualization technologies comprising at least one of digital twins and virtual sensors. In an embodiment, the Human-Machine Interface Systems such as touchscreens and dashboards, enable operators to monitor industrial processes and interact with control systems by displaying real-time data and allowing command inputs or setting adjustments. In an embodiment, the supervisory control and data acquisition systems are software and hardware solutions that remotely monitor, control, and collect data from industrial processes, offering real-time visualization, control capabilities, and historical data logging for large-scale operations.

[0022] Furthermore, the method comprises the one or more signals comprise at least one of operational signals from an operating system and simulation signals corresponding to derivative of real-time conditions associated with at least one of the equipment and the technical installation.

[0023] Another object of the present invention is achieved by a computing system for validating equipment and process behaviour in a technical installation. The computing system one or more user devices, one or more technical installation comprising one or more assets. Further, the computing system communicatively coupled to the one or more technical installations and the one or more user devices via a network. The computing system comprises an equipment and process behaviour validation module capable of performing method steps as described above.

[0024] Yet another object of the present invention is achieved by a computing environment for validating equipment and process behaviour in a technical installation. The computing environment comprises one or more user devices and one or more technical installation comprising one or more assets. Further, the computing environment comprises a computing system communicatively coupled to the one or more technical installations and the one or more user devices via a network. The computing system comprises an equipment and process behaviour validation module capable of performing a method according to method steps described above.

[0025] Yet another object of the present invention is also achieved by a computer program product comprising machine-readable instructions stored therein that, when executed by one or more processor(s), cause the one or more processor(s) to perform a method described above. The above-mentioned and other features of the invention will now be addressed with reference to the accompanying drawings of the present invention. The illustrated embodiments are intended to illustrate but not limit the invention.

[0026] The present invention is further described hereinafter with reference to illustrated embodiments shown in the accompanying drawings, in which:

[0027] FIG. 1 illustrates an exemplary block diagram of a network architecture of a computing system for validating equipment and process behaviour in a technical installation, according to the embodiment of the present invention;

[0028] FIG. 2 illustrates an exemplary block diagram representation of a proposed system such as those shown in FIG. 1 , capable of validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure;

[0029] FIG. 3 illustrates an exemplary block diagram of a process behaviour validation module, such as those shown in FIGs. 1 and 2, configured to validate equipment and process behaviour in a technical installation, in accordance with some embodiments of the present invention;

[0030] FIG. 4A illustrates an exemplary schematic diagram representation of a system architecture capable of validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure;

[0031] FIG. 4B illustrates an exemplary flow diagram representation of a communication sequence between components in a system architecture, in accordance with some embodiments of the present disclosure;

[0032] FIG. 5 illustrates an exemplary sequence diagram 500 representing a test logic sequence for validating equipment and process behaviour in a technical installation, in accordance with an embodiment of the present disclosure;

[0033] FIG. 6 illustrates an exemplary schematic diagram representation of a high-level method for validating equipment and process behaviour in a technical installation, in accordance with an embodiment of the present disclosure;

[0034] FIG. 7 illustrates an exemplary flow diagram representation of a method for validating equipment and process behaviour in a technical installation, in accordance with an embodiment of the present disclosure; FIGs. 8A and 8B illustrate exemplary schematic diagram representations of a user interface and for a test management option to view test set execution status and updates once the test set(s) are executed, in accordance with an embodiment of the present disclosure;

[0035] FIG. 9A illustrates an exemplary flow diagram depicting an interaction process among a process control system, one or more controllers (real and virtual), the plant simulation system, and the rapid testing system, representing communication and testing operations, in accordance with some embodiments of the present disclosure;

[0036] FIG. 9B illustrates an exemplary flow diagram representation 900B of a rapid testing process utilizing a plurality of test scenarios executed and managed through various interconnected system components, in accordance with some embodiments of the present disclosure;

[0037] FIG. 90 illustrates an exemplary flow diagram representation of a test execution process utilizing a test execution system 904c in conjunction with the rapid testing system, in accordance with some embodiments of the present disclosure;

[0038] FIG. 9D illustrates an exemplary flow diagram representation of a test management process utilizing a test management system in a rapid testing environment, in accordance with some embodiments of the present disclosure; and

[0039] FIG. 10 illustrates an exemplary flow diagram a method for validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure.

[0040] Various embodiments are described with reference to the drawings, wherein like reference numerals are used to refer the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide thorough understanding of one or more embodiments. It may be evident that such embodiments may be practiced without these specific details.

[0041] Engineering diagrams are graphical representations used to illustrate one or more components, or assets, structure, and functionality of a technical system or process. These diagrams include various types such as for example, but not limited to, P&IDs (Piping and Instrumentation Diagrams), circuit diagrams, HVAC layouts, and function diagrams, and the like. Each diagram is designed to depict critical technical details on interconnections of a plurality of parts of the technical system, functions of the parts, construction or maintenance details and the like. These diagrams use symbols, text annotations, and lines to represent physical components, electrical connections, piping systems, or control logic. These diagrams are essential for design, installation, operation, and troubleshooting in various engineering disciplines, serving as both technical blueprints and reference documents.

[0042] Throughout the specification, the term "asset”, as used herein, may include a broad range of components, devices, objects systems, instruments, or machinery employed in various industries or technical installations. This includes but is not limited to, industrial machinery comprising motors, gears, bearings, shafts, switchgears, rotors, circuit breakers, protection devices, remote terminal units, transformers, reactors, disconnectors, gear-drives, gradient coils, magnets, radio frequency coils, and the like. Further, the assets may include, such as for example, but not limited to, technical systems comprising turbines, large drives, and other complex systems. It should be understood that the term "asset" should be interpreted broadly to include any component or device or system that generates data which requires analysis within the context of this invention.

[0043] FIG. 1 is a block diagram of a network architecture 100 of a system 102 for validating equipment and process behaviour in a technical installation (not shown), according to the embodiment of the present invention. According to FIG. 1 , the network architecture 100 includes the system 102, one or more equipment / devices and process 104-1 , 104-2, 104-3, , 104-N (individually referred to as the equipment 104 and collectively referred to as the equipment 104), one or more data transmitting devices or data input sources 108-1 , 108-2, > , 108-N (individually referred to as the data transmitting device 108 and collectively referred to as the data transmitting devices 108), a machine / electrical control sub-system 110, a distributed control sub-system 112, a server 114, a database 116, a simulation sub-system 118, one or more electronic devices 120-1 to 120-N (individually referred to as the electronic device 120 and collectively referred to as the electronic devices 120), and digital simulation and visualization technologies 128-1 to 128-N (herein after referred to as digital simulation and visualization technologies 128).

[0044] The electronic device 120 may be associated with one or more users (not shown) and communicatively coupled to the server 114 and the system 102 via a communication network 106. In an embodiment, the electronic device 120 may include, but is not limited to, a Programmable logic controller, machine controlling subsystem, computer numerical control (CNC) control systems, electrical control subsystems, a laptop computer, a desktop computer running third party simulators, a tablet computer, a smartphone, a wearable device, a digital camera, an Augmented / Virtual Reality (AR / VR) device, a metaverse-based device, and the like. Further, the communication network 106 may be a wired network or a wireless network or combination thereof.

[0045] The server 114 may be at least one of, but not limited to, a central server, a cloud server, a remote server, a rake server, an on-premises server, and the like. Further, the system 102 may be communicatively coupled to the database 116 via the communication network 106. The database 116 may include, but is not limited to, factory data, sensory data, historical data, user interactions data, equipment health monitoring data, historical usage pattern data, real-time data, historical energy consumption data, parameters data, test data, any other data, and combinations thereof. The database 116 may be any kind of databases / repositories such as, but are not limited to, relational database, dedicated database, dynamic database, monetized database, scalable database, cloud database, distributed database, any other database, and combination thereof.

[0046] The data transmitting devices 108 may include, but not limited to, Profinet or Profibus communicating devices / equipment, any other fieldbus communicating devices / equipment, industrial protocol (EC, Modbus, DNP etc.) based data transmitting devices, and the like. The equipment and process 104 may include, but not limited to, programmable logic controllers (PLCs), distributed control system (DCS), human-machine interface (HMI) systems, supervisory control and data acquisition (SCADA) systems, field devices, field instruments (sensors, transmitters, actuators), input / output (l / o) modules (modules), communication networks, industrial networks (e.g., profinet, profibus, ethernet), process control and safety systems, process equipment (pumps, valves, motors, turbines), safety systems (emergency shutdown systems, safety instrumented systems), data management and analysis systems, historian databases, Remote Terminal Units (RTUs), Programmable Automation Controllers (PACs), process measurement meters, big data analytics platforms, any other devices / equipment, and combination thereof.

[0047] The digital simulation and visualization technologies 128 may include, but not limited to, simulation tools, digital twins, virtual sensors and actuators, process simulation models, augmented reality / virtual reality devices, any plant 3D visualization including wearable headsets, metaverse based devices, and the like. Further, the system 102, and / or the electronic device 120 may be associated with, but not limited to, a user, an individual, an administrator, a vendor, a technician, a worker, a specialist, a healthcare worker, an instructor, a supervisor, a team, an entity, an organization, a company, a facility, a bot, any other user, and combination thereof. The entity(s), the organization, the facility, and technical installations, may include, but are not limited to, continuous process facility such as chemical, petrochemical. Batch processing industries such as pharma, food and beverages, and discrete manufacturing facilities such as vehicle manufacturing, bottling plant, packaging industries, any other facility, and the like.

[0048] Further, the system 102 may be implemented by way of a single device or a combination of multiple devices that may be operatively connected or networked together. The system 102 may be implemented in hardware or a suitable combination of hardware and software. The system 102 includes one or more hardware processor(s) 122, and a memory 124. The memory 124 may include a plurality of modules 126. The system 102 may be a hardware device including the hardware processor 122 executing machine-readable program instructions for validating equipment and process behaviour in a technical installation. Execution of the machine-readable program instructions by the hardware processor 122 may enable the system 102 to validate equipment and process behaviour in a technical installation. The “hardware” may comprise a combination of discrete components, an integrated circuit, an application-specific integrated circuit, a field-programmable gate array, a digital signal processor, or other suitable hardware. The “software” may comprise one or more objects, agents, threads, lines of code, subroutines, separate software applications, two or more lines of code, or other suitable software structures operating in one or more software applications or on one or more processors.

[0049] The one or more hardware processors 122 may include, for example, microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuits, and / or any devices that manipulate data or signals based on operational instructions. Among other capabilities, hardware processor 122 may fetch and execute computer- readable instructions in the memory 124 operationally coupled with the system 102 for performing tasks such as data processing, input / output processing, and / or any other functions. Any reference to a task in the present disclosure may refer to an operation being or that may be performed on data.

[0050] In an embodiment, the system 102 may be configured to receive one or more signals and input data corresponding to at least one of an equipment and a technical installation, from a plurality of input data sources 108. The plurality of input data sources comprises at least one of a distributed control system 112, the simulation subsystem 118, and data transmitting devices 108. In an embodiment, the system 102 is configured to generate one or more test logics using the plurality of action blocks, using the received one or more signals and test data. Each of the one or more test logics is associated with the plurality of test instances, each test instance (not shown in FIG. 1 ) comprises one or more test parameters used in the one or more test logics for the run-time value substitution. In an embodiment, the system 102 is configured to create one or more test types using pre-defined test actions, based on the generated one or more test logics. The one or more test types are created to simulate and validate one or more operational scenarios of the at least one of the equipment and the technical installation. In an embodiment, the system 102 is configured to creates one or more test sets using the created one or more test types, by arranging each of the plurality of test instances in the pre-defined order to form one or more test sequences for test execution. In an embodiment, the system 102 is configured to validate the one or more test sets corresponding to at least one of the equipment and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution. In an embodiment, the system 102 is configured to execute the plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets. The executing the plurality of test scenarios comprise managing one or more errors detected during the test execution. In an embodiment, the system 102 is configured to generate the report comprising one or more test results comprising individual results and aggregated results for the one or more test sequences and the plurality of test instances.

[0051] For example, the system 102 may receive signals and information from the plurality of input data sources such as the distributed control system (DCS) 112 and / or the simulation sub-system 118. Further, the system 102 may execute the plurality of test scenarios using the test block comprising the plurality of testing modules. The test block includes internal variables and test instance parameters. Furthermore, the system 102 may manage the testing process. The execution module triggering test cases within the test block and managing the sequence of operations to ensure comprehensive test coverage. Additionally, the system 102 may determine and process the test results, formatting the results into a structured output suitable for analysis and review. In an embodiment, the system 102 may generate a report comprising the test results and formalizing test reports, including logs, performance metrics, and pass / fail statuses.

[0052] Furthermore, the system 102 may automate the testing and validation of equipment and process behaviour in the technical installation. The system 102 may receive the request for project creation. Further, the system 102 may establish the connection between the system and external systems via the coupling feature, allowing for signal exchange. Furthermore, the system 102 may create test types by organizing test actions designed to simulate and validate operational scenarios. The system 102 may execute the test sets according to a specified schedule or on- demand request. Furthermore, the system 102 may validate signals between the system and the external systems during test execution. Additionally, the system 102 may compile and display final test results on a test management dashboard.

[0053] Additionally, the system 102 may manage test logic in the technical installation. In an embodiment, the system 102 may generate test logic using various action blocks, where each test logic is associated with multiple test instances, each test instance 452a allowing for the inclusion of parameters for run-time value substitution. Further, the system 102 may handle the substitution of parameter values during the execution of the action blocks. In addition, the system 102 may store the outcomes of test executions in the format suitable for future analysis, reporting, or validation.

[0054] Further, the test block includes basic modules configured to perform fundamental functions such as setting and reading signal values. Further, the test block includes test modules configured to perform functions such as signal tracing and conditional branching. Furthermore, the test block includes Remote Control Interface (RCI) modules configured to manage interactions with a simulation environment. Furthermore, the test set validation includes checking the logical consistency and completeness of the test setup before execution. Further, the test set validation includes managing errors detected during the test execution process, including prompting the user to resolve errors before proceeding.

[0055] In another example, the system 102 may create and organize test types using predefined test actions, with the ability to export test types as templates for reuse in multiple testing projects. In an embodiment, the system 102 may monitor the execution of test sets in real-time, with intermediate results displayed on the test management dashboard. Further, the system 102 may store, in the database 116, the results in multiple formats with a naming convention that includes the date and time of execution. Additionally, the system 102 may generate, via a reporting tool, detailed test reports that include both individual and aggregated results for multiple test instances and actions. FIG. 2 illustrates a block diagram representation 200 of a proposed system such as those shown in FIG. 1, capable of validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure. The system 102 may also function as a computer-implemented system (hereinafter referred to as the system 102). The system 102 comprises processor(s) 202, an accessible memory 204, a communication interface 206, a network interface 208, an input / output unit 210, and a bus 212. The one or more hardware processors 202, the memory 204 are communicatively coupled through a system bus 212 or any similar mechanism. The memory 204 comprises a plurality of modules 126 in the form of programmable instructions executable by the one or more hardware processors 202.

[0056] The one or more hardware processors 202, as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor unit, microcontroller, complex instruction set computing exceptionally long processor unit, reduced instruction set computing microprocessor unit, very long instruction word microprocessor unit, explicitly parallel instruction computing microprocessor unit, graphics processing unit, digital signal processing unit, or any other type of processing circuit. The one or more hardware processors 202 may also include embedded controllers, such as generic or programmable logic devices or arrays, application-specific integrated circuits, single-chip computers, and the like.

[0057] The memory 204 may be a non-transitory volatile memory and a non-volatile memory. The memory 204 may be coupled to communicate with the one or more hardware processors 202, such as being a computer-readable storage medium. The one or more hardware processors 202 may execute machine-readable instructions and / or source code stored in the memory 124. A variety of machine-readable instructions may be stored in and accessed from the memory 204. The memory 204 may include any suitable elements for storing data and machine-readable instructions, such as read-only memory, random access memory, erasable programmable readonly memory, electrically erasable programmable read-only memory, a hard drive, a removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like. In the present embodiment, the memory 204 includes the plurality of modules such as a process behaviour validation module 214 stored in the form of machine- readable instructions on any of the above-mentioned storage media and may be in communication with and executed by the one or more hardware processors 202.

[0058] The storage unit or memory 204 may be a cloud storage or a repository such as those shown in FIG. 1 . The storage unit 204 may store, but is not limited to, factory data, sensory data, historical data, user interactions data, equipment health monitoring data, historical usage pattern data, realtime data, historical energy consumption data, parameters data, test data, any other data, and combinations thereof.

[0059] Further, the process behaviour validation module 214 may be configured to receive one or more signals and input data corresponding to at least one of an equipment and a technical installation, from a plurality of input data sources 108. The plurality of input data sources comprises at least one of a distributed control system 112, the simulation subsystem 118, and data transmitting devices 108. Further, the process behaviour validation module 214 may be configured to generate one or more test logics using the plurality of action blocks, using the received one or more signals and test data. Each of the one or more test logics is associated with the plurality of test instances, each test instance (not shown in FIG. 2) comprises one or more test parameters used in the one or more test logics for the run-time value substitution. Further, the process behaviour validation module 214 may be configured to create one or more test types using pre-defined test actions, based on the generated one or more test logics. The one or more test types are created to simulate and validate one or more operational scenarios of the at least one of the equipment and the technical installation. Further, the process behaviour validation module 214 may be configured to create one or more test sets using the created one or more test types, by arranging each of the plurality of test instances in the pre-defined order to form one or more test sequences for test execution. Further, the process behaviour validation module 214 may be configured to validate the one or more test sets corresponding to at least one of the equipment and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution. Further, the process behaviour validation module 214 may be configured to execute the plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets. The executing the plurality of test scenarios comprise managing one or more errors detected during the test execution. Further, the process behaviour validation module 214 may be configured to generate the report comprising one or more test results comprising individual results and aggregated results for the one or more test sequences and the plurality of test instances.

[0060] In an exemplary embodiment, the process behaviour validation module 214 may be configured to receive the request for the project creation to initiate the testing process, the system 102 is configured to establish the connection with the plurality of action blocks via the coupling feature for exchanging the one or more signals using one or more protocols. Additionally, the process behaviour validation module 214 may be to obtain the one or more signals from each of the plurality of input data sources via the established connection. The action blocks are modular components or predefined functions that represent specific operations or tasks within the test logic.

[0061] Further, the process behaviour validation module 214 may be configured to manage the testing process by triggering the plurality of test scenarios within the plurality of action blocks. Further, the process behaviour validation module 214 may be configured to orchestrate execution of the one or more test sequences, based on the managed testing process. The Orchestration is the control mechanism executed by the system 102 for managing the execution order, synchronization, and coordination of one or more test sequences in a structured and automated manner. The orchestration comprises managing the sequence of operations of the one or more test sequences. Further, the process behaviour validation module 214 may be configured to monitor the execution of the one or more test sequences in real-time. Further, the process behaviour validation module 214 may be to display intermediate test results on the display, based on the monitored execution of the one or more test sequences.

[0062] Further, the process behaviour validation module 214 may be configured to process the intermediate test results, by formatting the intermediate test results into the structured output format. The structured output format comprises at least one of logs, performance metrics, and at least one of pass status and fail status of the intermediate test results. Further, the system 102 is configured to store in the database 116, one or more test outcomes of the executed one or more test sequences in the plurality of formats.

[0063] The plurality of formats may refer to multiple predefined data representations or encodings, such as JSON, XML, CSV, tabular reports, or graphical visualizations, used to store or transmit test outcomes.

[0064] Further, the process behaviour validation module 214 may be configured to monitor the execution of the one or more test sequences. Further, the process behaviour validation module 214 may be configured to validate the one or more test parameters 908 with one or more pre-defined thresholds values. Further, the process behaviour validation module 214 may be configured to validate the one or more signals and the one or more test parameters 908 during the test execution to confirm correct configuration and functionality of the test execution. Further, the process behaviour validation module 214 may be configured to iteratively test the one or more test sequences through the feedback loop based on one or more test outcomes. Further, the process behaviour validation module 214 may be configured to modify the one or more test parameters (not shown in FIG. 2) and the one or more operational scenarios associated with the one or more test sequences, based on testing the one or more test sequences. The iterative testing is the testing methodology in which one or more test sequences are repeatedly executed with updated parameters or conditions based on prior outcomes, enabling progressive optimization or error isolation.

[0065] Further, the process behaviour validation module 214 may be configured to orchestrate the execution of the one or more test sequences. Further, the process behaviour validation module 214 may be configured to execute the one or more test sequences in at least one of a manual mode initiated by a user and a scheduled mode at predefined times. The manual mode may refer a mode of test execution in which the initiation of one or more test sequences is manually triggered by a user through the graphical interface or command input, allowing controlled or on-demand testing. Further, the process behaviour validation module 214 may be configured to manage substitution of one or more parameter values during execution of the plurality action blocks. Further, the process behaviour validation module 214 may be to identify one or more parameter fields in the plurality action blocks. Further, the process behaviour validation module 214 may be configured to substitute one or more pre-defined values for each of the plurality of test instances, based on the identification. The scheduled modes is a mode of test execution in which one or more test sequences are dynamically initiated by the system 102 at predefined times or intervals based on a configured schedule. The orchestration of execution is a structured control and coordination process managed by the system 102 to determine the order, timing, and interdependencies of one or more test sequences across multiple action blocks.

[0066] Further, the process behaviour validation module 214 may be configured to generate the first user interface for coordinating the exchange of the one or more signals from the coupling partner associated with the one or more input data sources. The first User Interface may be a graphical user interface (GUI) generated by the system 102 for coordinating the exchange of one or more signals between the system and the coupling partner associated with one or more input data sources. The coupling partner may refer a system, component, or external entity interfacing with the system 102 for the purpose of exchanging input or output signals, typically involved in data acquisition, simulation, or hardware-in-the-loop testing. The first user interface displays the plurality of action blocks. Further, the process behaviour validation module 214 may be configured to generate the second user interface for generating the ore more test logics and creating an executable plurality of test instances corresponding to the one or more test parameters. The second user interface may refer to a graphical user interface generated by the system 102 for enabling the creation of one or more test logics and for generating a corresponding plurality of executable test instances based on one or more test parameters. Further, the process behaviour validation module 214 may be configured to generate the third user interface comprising the tree for the one or more test sets, a work area, a tree for the plurality of test instances, and the scheduler for planning execution of one or more test sets. The third user interface may refer to the graphical user interface generated by the system 102, comprising the test set tree, the work area for test configuration, the test instance tree, and a scheduler for managing timed execution of test sets.

[0067] Further, the process behaviour validation module 214 may be configured to manage errors. Further, the system 102 is configured to detect at least one of communication errors and validation errors during the test execution. Further, the process behaviour validation module 214 may be configured to receive the feedback from the user to correct the errors before proceeding with the test execution.

[0068] Further, the process behaviour validation module 214 may be configured to the plurality of action blocks comprises internal variables, test instance parameters 426, basic modules configured to perform functions comprising setting and reading signal values associated with the one or more signals, advanced modules configured to perform functions comprising signal tracing and conditional branching of the one or more signals, and remote-control interface modules configured to manage interactions with a simulation environment. The remote-control interface modules may be modules within action blocks configured to handle communication and interaction with external simulation environments, including the initiation, synchronization, and data exchange required for co-simulation or hardware-in-the-loop testing.

[0069] Further, the process behaviour validation module 214 may include basic modules. Further, the process behaviour validation module 214 may be configured to perform functions comprising at least one of pausing execution for the specified time, pausing execution until the condition is met, verifying conditions, verifying conditions over the specified period, and resetting signals to the initial state. The basic module may be functional components within action blocks configured to execute fundamental operations, including setting or reading signal values associated with the one or more signals.

[0070] Further, the process behaviour validation module 214 may include advanced modules that are further configured to perform functions comprising at least one of, but not limited to, tracing signal values at intervals, stopping signal tracing and storing aggregated values, prompting user acknowledgment, writing data to a file, executing conditional branching based on the condition, looping execution until the condition fails, and setting signal values for the specified duration. The advanced module may refer to functional components within the plurality of action blocks, configured to perform complex logic operations such as signal analysis, conditional execution, and user interaction during test execution. The signal tracing may be a process of recording signal values over time at specified intervals to monitor signal behaviour, detect anomalies, or support post-test analysis.

[0071] Further, the remote-control interface modules are configured to perform functions comprising at least one of creating the snapshot of the simulation environment, loading the snapshot, adjusting simulation speed, and setting the simulation state.

[0072] Further, the plurality of input data sources comprise at least one of programmable logic controllers, human-machine interface systems, supervisory control and data acquisition systems, field instruments, input / output modules, industrial networks, process equipment, safety systems, historian databases, remote terminal units, programmable automation controllers, process measurement meters, and digital simulation and visualization technologies comprising at least one of digital twins and virtual sensors.

[0073] Further, the one or more signals comprise at least one of operational signals from an operating system and simulation signals corresponding to derivative of real-time conditions associated with at least one of the equipment and the technical installation.

[0074] In an exemplary embodiment, computing environment comprising one or more user devices, one or more technical installation comprising one or more assets and the computing system communicatively coupled to the one or more technical installations and the one or more user devices via the network. The computing system comprises an equipment and process behaviour validation module.

[0075] For example, the process behaviour validation module 214 may be configured to generate test logic using various action blocks. Each test logic is associated with multiple test instances, each test instance 452a allowing for the inclusion of parameters for run-time value substitution. Further, the process behaviour validation module 214 may be configured to create and organize test types using predefined test actions, with the ability to export test types as templates for reuse in multiple testing projects. For example, the process behaviour validation module 214 may be configured to create one or more test instances from one or more test types in a predefined order for execution to create one or more test sequences.

[0076] For example, the process behaviour validation module 214 may be configured to handle the substitution of parameter values during the execution of the action blocks. A central execution control module configured to orchestrate the execution of test cases, manage test sequences, and compile test results into structured outputs. The process behaviour validation module 214 may execute the test sequence on-demand or the test sequence may be scheduled.

[0077] For example, the process behaviour validation module 214 may be configured to monitor the execution of individual test set in real-time, with intermediate results displayed on a test results dashboard. The process behaviour validation module 214 may validate test parameters against predefined thresholds, coupled with a feedback loop that enables iterative testing and continuous improvement based on previous test outcomes.

[0078] For example, the process behaviour validation module 214 may be configured to store the outcomes of test executions in a format suitable for future analysis, reporting, or validation.

[0079] In another example, the process behaviour validation module 214 may be configured to generate summary test reports that include both aggregated and drilled down individual results for multiple test sets and test instances.

[0080] FIG. 3 is an exemplary block diagram of a process behaviour validation module 214, such as those shown in FIGs. 1 and 2, configured to validate equipment and process behaviour in a technical installation, in accordance with some embodiments of the present invention.

[0081] In FIG. 3, the process behaviour validation module 214 comprise a signal receiving module 302, a signal processing module 304, a test logic generation module 306, a test type creation module 308, a test sequence organization module 310, a validation module 312, an execution module 314, a test monitoring module 316, and a report generation module 318.

[0082] In an exemplary embodiment, the signal receiving module 302 may receive one or more signals and input data corresponding to at least one of an equipment 104 and the technical installation from the plurality of input data sources. The plurality of input data sources comprises at least one of the distributed control systems 112, the simulation subsystem 118, and data transmitting devices 108. The input data includes factory data, sensory data from field instruments, historical data from historian databases, user interactions data, equipment health monitoring data, real-time operational data, parameters data for test configurations, and test data generated during the validation process.

[0083] Further, the signal processing module 304 may process the received one or more signals to extract relevant operational parameters, environmental conditions, and system states associated with the equipment 104 and technical installation. The signal processing module 304 may filter, normalize, and format the input data to ensure compatibility with subsequent testing modules and to eliminate noise or irrelevant information from the data streams.

[0084] Furthermore, the test logic generation module 306 may generate one or more test logics using a plurality of action blocks, utilizing the processed signals and test data. Each of the one or more test logics is associated with a plurality of test instances. Each test instance comprises one or more test parameters used in the one or more test logics for run-time value substitution. The action blocks comprise basic modules for fundamental functions, advanced modules for complex operations, and Remote-Control Interface (RCI) modules for simulation environment management.

[0085] Additionally, the test type creation module 308 may create one or more test types using predefined test actions, based on the generated one or more test logics. The one or more test types are specifically designed to simulate and validate one or more operational scenarios of the at least one of the equipment 104 and the technical installation, ensuring comprehensive coverage of real-world operational conditions and edge cases.

[0086] Further, the test sequence organization module 310 may create one or more test sets using the created one or more test types, by systematically arranging each of the plurality of test instances in a pre-defined order to form one or more test sequences for test execution. The pre-defined order ensures logical flow of testing operations and maximizes the effectiveness of the validation process.

[0087] Furthermore, the validation module 312 may validate the one or more test sets corresponding to at least one of the equipment 104 and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution. This validation process includes checking parameter compatibility, verifying signal mappings, and ensuring that all necessary test components are properly configured. Additionally, the execution module 314 may execute a plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets. The execution of the plurality of test scenarios comprises managing one or more errors detected during the test execution, including communication errors, validation errors, and parameter substitution errors. The execution engine handles the substitution of parameter values during execution, allowing multiple instances of test logic to utilize different parameter values without recreating the test logic.

[0088] Further, the test monitoring module 316 may monitor the test execution in real-time, capture intermediate results, and process test outcomes to determine pass or fail statuses, performance metrics, and operational compliance measurements. The results processing module 316 formats the test results into structured outputs suitable for analysis and review.

[0089] Furthermore, the report generation module 318 may generate a comprehensive report comprising one or more test results including individual results and aggregated results for the one or more test sequences and the plurality of test instances. The report includes detailed logs, performance metrics, graphical representations such as donut charts and bar graphs, and pass / fail statuses for each test component, providing stakeholders with complete visibility into the validation process and equipment performance.

[0090] FIG. 4A illustrates an exemplary schematic diagram representation of a system architecture 400A capable of validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure.

[0091] The system architecture 400A may be configured to automate testing and verification of software components of automation system in the technical installations. The system architecture 400A may be considered as shown in FIG. 4A, which plays a critical role in ensuring the reliability and accuracy of the testing process. Consider, overall system architecture 420a which includes an overall test execution and management module. The execution and management module includes an input data source. The system integrates multiple input data sources such as a Process Control System 7 (PCS7) 402a, a Process Control System neo (PCS neo) 404a, a Totally Integrated Automation (TIA) 406a, Any third-party Engineering System 408, OPC UA Servers 410, OPC UA Client 412, a Rapid prototype Testing (RpT) 414, Simulation Integrated Test (SIMIT) 416a, a simulation product 448a, Any third-party interface 418a ((e.g., IEC, DNP, MOD / TCP). The data sources feed into the system, allowing it to pull relevant information required for testing. Further, the system architecture 400A may include a test block 424a which may be a modular component that houses various testing modules such as basic module 462aa, advanced module 464a, and a Remote-Control Interface (RCI) module 466a, and the like. The test block may include internal variables and test instance parameters 426a, and the like. Further, the system architecture 400A may include an execution module 430a, which may be a central processing unit, orchestrates the entire testing process. The execution module 430a may trigger test cases included within the test block 424a, manages the sequence of operations, and ensures that all relevant test scenarios are covered. The execution module 430a functions as a control Centre for the testing operations. Further, the system architecture 400A may include a summary analysis report and storage module 446a. The results from the test executions are captured and processed within this subsystem. The data is formatted into a structured output, suitable for analysis and review. Additionally, the system architecture 400A may include a reporting tool, which is a tool that compiles the test results into formal test reports, which are output as documents. The reports may include detailed logs 434a, performance metrics, donut charts, bar graphs, and pass / fail statuses, which are crucial for stakeholders in assessing the quality and compliance.

[0092] In an exemplary embodiment, consider, details of execution 450a which includes detailed test and validation operations. The designing and management of test cases include test case selection, which involves choosing specific test cases based on the scenario, automation engineering software version, or other parameters. Further, the designing and management of test cases include test sequence creation, which allows for the creation and management of test scenarios that mimic real-world operating conditions of the automation engineering or software. Further, the system architecture 400A includes feedback loop for continuous improvement and iterative testing processes. Test results 432a and data are used to refine test parameters, scenarios, or even the automation engineering itself. The system may re-run tests based on previous outcomes, ensuring that any identified issues are resolved in subsequent testing rounds.

[0093] In an exemplary embodiment, the system architecture 400A provides a framework for creating and managing test logic using various action blocks. To effectively execute test logic, each test type needs a specific test instance 452a. The test instances 452a allow for the inclusion of parameters, which enable run-time value substitution. Instead of recreating the test logic for different scenarios, multiple instances with varying parameter values may be created. The execution engine 430a handles the substitution of these values during the execution of the action blocks. When a test set 456a is selected for execution, it is the test instance 452a of the test logic that is used, rather than the test logic itself. This approach is necessary because direct use of the test logic would prevent parameter value substitution. Each test logic may have multiple instances 452a, each with a unique set of parameters that may be substituted during the action block execution.

[0094] In an exemplary embodiment, the system architecture 400A may configured to manage the testing process by triggering the plurality of test scenarios within the plurality of action blocks. Further, the system architecture 400A may configured to orchestrate execution of the one or more test sequences, based on the managed testing process. The orchestration comprises managing the sequence of operations of the one or more test sequences. Further, the system architecture 400A may configured to monitor the execution of the one or more test sequences in real-time. Further, the system architecture 400A may configured to display the intermediate test results on the display, based on the monitored execution of the one or more test sequences.

[0095] Further, the system architecture 400A may configured to process the intermediate test results, by formatting the intermediate test results into a structured output format. The structured output format comprises at least one of logs, performance metrics, and at least one of pass status and fail status of the intermediate test results. Further, the system architecture 400A may configured to store in the database 116, one or more test outcomes of the executed one or more test sequences in a plurality of formats.

[0096] FIG. 4B illustrates an exemplary flow diagram representation of a communication sequence between components in a system architecture 400B, in accordance with some embodiments of the present disclosure. For example, the system architecture 400B includes a Process Control System (PCS) 422b, which is connected to a real controller 428b or a virtual controller 426b. The PCS is a system used to monitor and control industrial processes, typically involving hardware and software that manage equipment to ensure processes operate within desired parameters. Further, the real controller 428b may be a physical hardware device that processes sensor inputs and sends commands to actuators. I addition the virtual controller 428b may a software-based simulation used for testing and development without physical hardware. The real controller 428b or virtual controller 426b are represented by a pair of parallel paths, indicating that the real controller 428b or virtual controller 426b may be alternately engaged. The real controller 428b or virtual controller 426b are further linked to a Plant Simulation System (SIMIT) 430b, which simulates the plant environment for testing purposes. The Plant Simulation System 430b is a system that replicates the behaviour of a physical industrial plant in a virtual environment, used for testing and validating control systems and processes without affecting the actual plant. The connection between the PCS 422b and the Plant Simulation System 430b is established via an Open Platform Communications Unified Architecture (OPC UA) server 424b. The OPC UA server 424b is a software component that implements the OPC UA protocol, acting as an intermediary to enables communication and data transfer between systems, such as the PCS and the Plant Simulation System. The OPC UA server enables communication between the PCS 422b system and the Plant Simulation System.

[0097] Further, the Plant Simulation System 430b is depicted as comprising several subsystems. A project management subsystem 414b oversees the overall testing project. A test template library 404b provides predefined templates for various test scenarios. The test template library 404b is a collection of predefined test scenarios or configurations that may be reused or adapted for specific testing needs within the Plant Simulation System. Further, a test design system 406b is responsible for creating and configuring the test cases, while a test execution system 408b carries out the tests. The test design system 406b may be a subsystem responsible for creating and configuring test cases, defining parameters, conditions, and expected outcomes for testing the control system or plant simulation. The execution may be manual or scheduled 410b, depending on the specific requirements. A test management system 412b oversees the entire testing process, ensuring that all aspects are managed effectively and systematically. The interaction between the test execution system 408b and the test management system 412b ensures the tests are conducted according to the specified procedures and timelines.

[0098] In an example, the Plant Simulation System 430b may establish communication with the real controller 428b or the virtual controller 426b via the OPC UA server 424b, without any direct interaction with the controllers. The Plant Simulation System 430b may interface through the SIMIT Interface 420b and a OPC client 418b to design test logics based on the retrieved signals. The test logics are then executed with specific parameters using instances that operate in scheduled or manual execution modes 410b, and the resulting data is stored. The test management system 412b consolidates all the details from the test executions within the testing project. Thus, FIG. 4B illustrates the modular configuration of a test automation and validation environment in the plant simulation system, comprising multiple subsystems such as the test design system 406b, the test execution system 408b, and the test management system 412b, all of which communicate through standardized interfaces with the PCS system 422b and the real controller 426b or virtual controllers 428b via the OPC UA server 424b. In an exemplary embodiment, as represented in FIG. 4B, the request is received to create the project in order to initiate the testing process. A connection is established with the plurality of action blocks via the coupling feature configured for exchanging signals using one or more communication protocols. Signals are obtained from each of the plurality of input data sources via the established connection. The signal receiving module (402B) and signal processing module 404B facilitate the collection and pre-processing of these signals, which are subsequently utilized in generating test logic and coordinating further validation processes.

[0099] In an embodiment, monitoring execution of one or more test sequences comprises validating one or more test parameters against predefined threshold values. The signals and test parameters are validated during test execution to confirm correct configuration and functional behaviour. Iterative testing is carried out through a feedback loop based on test outcomes. Based on the outcomes, the test parameters and operational scenarios associated with the test sequences are modified and refined to improve test accuracy and reliability.

[0100] FIG. 5 illustrates an exemplary sequence diagram 500 representing a test logic sequence for validating equipment and process behaviour in a technical installation. The test logic sequence begins with a test type 502 responsible for initiating the testing process, defined based on test actions 504 that determine the overall nature of the test to be performed. At step 532, within test actions 504, parameter configurations are created to define specific conditions or variables necessary for test execution. The test type 502 initiates step 530 for creation of a test instance 452a, which represents a specific occurrence or execution of a test based on the test type 502 with particular configurations for a given scenario.

[0101] The test instance 452a provides parameter values 510 and proceeds through step 534 where instances are selected for organization into test set 456a. At step 536, the system 102 organizes test instances within the test set 456a, confirming proper sequencing for coordinated execution. The test execution 518 is initiated through step 514 (Select Test sets) and involves parameter value substitution 508, where the system 102 determines specific parameter values 510 utilized for test execution 518. During test execution, the parameter values 510 are substituted into the test environment, configuring the test based on pre-evaluated conditions and performing test action executions where the system is 102 evaluated against predefined parameters.

[0102] At step 540, the system 102 runs test execution 518, implementing actual test procedures and monitoring system behaviour under specified conditions. Upon completion, test results 536 are processed at step 528 where they are stored in test results storage 526. The test results 526 aggregate data from parameter values 510 and generated test outcomes, providing comprehensive documentation. Results are automatically stored in multiple formats (.csv, .txt, .xlsx) within dedicated folders containing timestamps in YYYY-MM-DD HHMMSS format along with test set 456a names, ensuring complete documentation, traceability, and availability for future validation, reporting, and auditing purposes. The test results are dynamically updated and displayed, reflecting the status of test set 456a including execution outcomes indicating pass, fail, or unexecuted states for comprehensive test monitoring and validation.

[0103] In an exemplary embodiment, the test logic sequence 400 includes a test type initialization and test instance creation. The sequence 400 begins with the 'TestType' entity, which is responsible for the initialization of the testing process. The 'TestType' initiates the creation of the 'Testinstance', for a specific test. The 'Testinstance' then undergoes the process of parameter substitution. The substitution step determines the specific parameters that will be used for the test execution. The parameters might include variables or conditions that define the test environment, ensuring that the test is conducted under the appropriate conditions.

[0104] In an exemplary embodiment, the 'Test Execution' entity then takes over, responsible for running the test according to the defined parameters. During this phase, the system 102 substitutes the parameter values into the test environment, configuring the test based on the pre-evaluated parameters. The execution phase involves running the actual test, which is the core activity where the system or component being tested is evaluated against the predefined parameters.

[0105] In an exemplary embodiment, after the test execution is completed, the results are processed. During this phase, the parameters that were used in the test, along with the results generated, are collected and stored in the storage. The 'Test Results' entity then takes charge of storing the results. This storage phase is to store the outcomes of the test are for future analysis, reporting, or validation. The stored results can be used to verify whether the system or component under test met the required specifications or to identify any issues that need to be addressed.

[0106] In an exemplary embodiment, for example, at initial step, the combination of 'Test Action' is employed to create the 'TestType'. This step defines the overall nature of the test to be performed. Within the 'Test Actions', parameters can also be created, setting up the specific variables or conditions necessary for the test's execution. Once the 'TestType' is established, the 'Testinstance' is generated for each test type. Users then provide parameter values for these test instances, ensuring that the test is customized according to specific needs or requirements. During the test execution phase, these provided parameter values are automatically substituted into the test environment, configuring the test setup accurately. As the test is executed, the system dynamically displays the results within the 'Test Results' tab. This tab reflects the status of the test set, including the outcomes of individual test instances and actions, indicating whether they have passed, failed, or have not been run. The test results are then automatically stored in the '.csv' file. Additionally, a results folder is created at a pre-configured path, with a naming format that includes the date and time (YYYY-MM-DD HHMMSS) along with the test set name. This folder saves the results in both '.txt' and '.xlsx' formats, ensuring that all test outcomes are preserved for further analysis and documentation.

[0107] FIG. 6 illustrates an exemplary schematic diagram representation 600 of a high-level workflow 600 for validating equipment and process behaviour in a technical installation, in accordance with an embodiment of the present disclosure. In an example implementation, an automation engineers 604 utilizes the system 102 (e.g., equipment and process behaviour validation module) to manage and execute testing procedures configured to interact with a plurality of external systems and platforms. The process begins with the system 102 interfacing with external systems such as a distributed control sub-system 112, a simulation sub-system 118, and various equipment 104, thereby establishing a communication coupling. The coupling enables integration and bidirectional communication between system 102 and external platforms, including Process Control Systems (PCSs) such as PCS7 402 and PCS neo-404, as well as Totally Integrated Automation (TIA) systems 406 and the like. Signals are acquired from these systems via communication protocols such as Open Platform Communications Unified Architecture (OPC UA) 410 and the SIMIT 626, thereby enabling initiation of subsequent testing operations. In certain embodiments, the test execution may also be initiated by an external test execution trigger 606 configured to activate test logic execution within the system 102.

[0108] Further, upon establishment of communication coupling, the system 102 is configured to generate one or more test procedures. Each test procedure may include one or more test action blocks and associated runnable instances. The process defines the logical structure, execution paths, and operational conditions necessary for conducting meaningful validation activities. The creation of well-defined test procedures ensures that downstream test sets are executable and traceable within live or simulated control environments.

[0109] Further, the system 102 generates one or more test sets incorporating the previously defined runnable instances. The test sets are executed in coordination with real-time communication to and from the distributed control system 112 and / or simulation system 118. During execution, the system 102 transmits and receives test signals to verify functional behaviour of the installation under test. Execution results are automatically generated and recorded for each run, including structured test reports formatted as test files (e.g., Excel or plain text), as indicated by block 618. These results are further compiled into comprehensive summaries, for example, in PDF format as indicated by block 620, and may be exported to third-party test management systems 620a. Additionally, system 102 comprises a test management dashboard 616, which provides a centralized interface for the automation engineer to monitor and evaluate all test outcomes. This interface supports efficient analysis, validation, and resolution of system behaviour by presenting an aggregated overview of testing results.

[0110] In an example implementation, an automation engineers 604 utilizes the system 102 (e.g., equipment and process behaviour validation module) to manage and execute testing procedures configured to interact with a plurality of external systems and platforms. The process begins with the system 102 interfacing with external systems such as a distributed control sub-system 112, a simulation sub-system 118, and various equipment 104, thereby establishing a communication coupling. The coupling enables integration and bidirectional communication between system 102 and external platforms, including Process Control Systems (PCSs) such as PCS7 402 and PCS neo-404, as well as Totally Integrated Automation (TIA) systems 406 and the like. Signals are acquired from these systems via communication protocols such as OPC UA 410 and SIMIT 626, thereby enabling initiation of subsequent testing operations. In an embodiment, the test execution may also be initiated by an external test execution trigger 606 configured to activate test logic execution within the system 102.

[0111] Further, the automation engineers 604 may interacts with external systems to create coupling connections 608, then designs test procedures that include test action blocks and creates runnable instances 610. These runnable instances are organized into test sets for execution 612, with results captured and processed 614. A test management dashboard 616 provides centralized monitoring of all results, while each test set 456a execution produces results in Excel and text files 618. The system exports PDF results of all tests executed 620a from the RpT 414 and may push results to third-party test management tools 620b. Test planning is organized across multiple dimensions including equipment device-wise test plans 624a, process-wise test plans 624b, and I / O unit test plans 624c, with test template export and import capabilities from cloud systems 628 and external system interactions through various industrial protocols 622. FIG. 7 illustrates an exemplary flow diagram representation of a method 700 for validating equipment and process behaviour in a technical installation, in accordance with an embodiment of the present disclosure.

[0112] At step 702, the method 700 includes receiving, by the processor 122, a request for a project creation in a SIMIT Rapid Tester.

[0113] At step 704, receiving a coupling request from the user. Further, the coupling feature of the SIMIT Rapid Tester facilitates the exchange of input / output (I / O) signals between the coupling partner (SIMIT & DCS) and the SIMIT Rapid Tester.

[0114] At step 706, the method 700 includes obtaining by the processor 122signals from the coupling partner via the established coupling. The test actions created using signals fetched from coupling partner. The test actions are designed to perform various tests on the coupling signals, the test procedures may be created using various test blocks mainly divided into Basic, Advanced and RCI (Remote Control Interface) (Only for SIMIT). Evaluates the signals added in test action blocks.

[0115] At step 708, the method 700 includes creating the test instances by the processor 122. The user uses test parameters to create test instances and also create test instance 452a without test parameters for test type.

[0116] At step 710, the method 700 includes creating the test set 456a by the processor 122. By dragging and dropping test instances created in the test type tree into test set center screen. The test set 456a may include test instances of same test type or the combinations of different test types.

[0117] At step 712, the method 700 executing an execution demand or scheduled test execution by the processor 122. The test set 456a in any on-demand or scheduled mode, where the on-demand execution is initiated upon a user activated start command, and the scheduled execution is automatically triggered when the system time matches the predefined schedule.

[0118] At step 714, the method 700 executing validating signals by the processor 122 and parameters during test set execution. The validation of signals or internal variables or parameters added in test action blocks of test actions configured in the test set 456a and evaluates coupling partner signals used in test actions. At step 716, the method 700 further includes a step of checking for any compilation errors after the validation is performed by the processor 122. If compilation errors are detected, the process moves to Step 718 for error handling.

[0119] At step 718, displaying compilation errors and stops test set execution. User corrects the error in test type and follows test set execution.

[0120] At step 720, the method 700 includes checking for any communication error with the coupling partner and any runtime exceptions during execution by the processor 122.

[0121] At step 722, the method 700 includes, by the processor 122, stopping the test set execution and storing intermediate results for the test set 456a when communication errors are detected.

[0122] At step 724, the method 700 includes, by the processor 122, compiling final results and stopping the test set execution when communication errors are detected. The test set execution completes with the results. The test results tab displays the auto-populated results of the Test Set, including test instances and test actions with statuses of Passed, Failed, or Not run. The test results are stored in csv file. The test results folder, created in the configured path with the format YYYY- MM-DD_HHMMSS_<Test Set Name>, saves the results in .txt and .xlsx formats.

[0123] At step 726, the method 700 includes, by the processor 122, displaying the test results on the test management dashboard. Test management dashboard displays the test set execution status.

[0124] In an exemplary embodiment, a user interface for a coordination of signal exchange between the rapid tester and the coupling partner, in accordance with an embodiment of the present disclosure. The coupling feature of the system 102 facilitates the exchange of input / output (I / O) signals between the coupling partner (distributed control system (DCS) 112 or the simulation subsystem 118) and the system 102. The coupling feature ensures the coordination of signal exchange between the system 102 and the coupling partner.

[0125] In an exemplary embodiment, the user interface for a plurality of test blocks comprising basic blocks, advanced blocks, and Remote-Control Interface (RCI) blocks, in accordance with an embodiment of the present disclosure. The test actions within the system 102 are designed to perform a variety of tests on coupling signals, ensuring that the system 102 operates as intended. The test procedures are created using various test blocks, which are categorized into three main groups: basic, advanced, and Remote-Control Interface (RCI), the latter being exclusive to the testing. The test types are to define, design, and assess the functionality of a simulated process plant by sequencing test actions in a logical manner. The test types may be created and organized under the test design tab of the user interface, where the logic for each test type is developed using predefined test actions. Additionally, exporting test types, or exporting them as templates, allows for their reuse across multiple testing projects, thereby enhancing efficiency and consistency across different testing environments.

[0126] Further, the basic test action blocks serve fundamental functions within the testing process. The "Set" block allows for the setting of signal values, while the "Read" block enables the reading of these signal values. The "Wait" block pauses the execution until a specified wait time is over, and the "Wait Until" block pauses execution until a certain condition is met within a timeout period. The "Verify" block checks if a condition is met, and the "Verify Overtime" block extends this verification over a specified period. Lastly, the "Cleanup" block is used to unfix all fixed SIMIT signals, ensuring that the system is reset to its initial state after testing.

[0127] The advanced test action blocks provide complex functionalities. The "Trace" block allows for tracing the signal value at intervals throughout the test execution, and the "End Trace" block stops the tracing and stores the aggregate values of the traced signals. The "Message" block prompts the user for acknowledgment before continuing execution. The "WriteLine" block enables the printing of data or values to a CSV file. The "If" block acts as a branching action block, executing a block only if a specific condition is met. The "While" block facilitates looping the execution until a condition fails. Finally, the "SetOverTime" block sets the value for a signal during a specified time and resets it to the initial value after the duration ends.

[0128] Furthermore, the RCI action blocks, which are specific to testing, provide specialized functions for interacting with the simulation environment. The "Create Snapshot" block allows for creating a snapshot of the product during testing phase, while the "Load Snapshot" block loads a snapshot from testing. The "Simulation Speed" block adjusts the simulation speed within the testing phase, and the "Simulation State" block sets the state of the simulation. The RCI action blocks are essential for managing and controlling the simulation environment, confirming that the test scenarios accurately reflect the intended operational conditions.

[0129] In an exemplary embodiment, the user interface for the test logic to create the test instance 452a executable by the test logic. The test procedure is based on logic. To execute the test logic, the user may create the test instance 452a which serves as the executable for the test logic. In an exemplary embodiment, the user interface comprising the test instances and corresponding test parameters to be executed by the test logic. The test set includes the necessary test instances that need to be executed.

[0130] In an exemplary embodiment, the user interface comprising a test sets tree, a work area, and a test instances tree. Further, the user interface for the scheduled execution of one or more test sets using the scheduler to plan the execution of one or more test sets. Tests may be executed either on demand or through scheduled execution. The scheduler feature allows user to plan the execution of one or more tests, enabling continuous testing and saving both time and human effort. During the test execution process, the test results tab displays the auto-populated results of the test set, including test instances and test actions with statuses of passed, failed, or not run. The test results are stored in csv file. The test results folder, created in the configured path with the format YYYY-MM-DD_HHMMSS_<Test Set Name>, saves the results in .txt and .xlsx formats.

[0131] FIGs. 8A and 8B illustrate exemplary schematic diagram 800A and 800B representations of a user interface for a test management option to view test set execution status and updates once the test set(s) are executed, in accordance with an embodiment of the present disclosure. The test management option provides the test set execution status and updates once the test set(s) are executed. The test management option displays the complete data of total test sets of the project and test instances not included in test set.

[0132] FIG. 9A illustrates an exemplary flow diagram 900A depicting an interaction process among a process control system, one or more controllers (real and virtual), the plant simulation system 430b, and the rapid testing system, representing communication and testing operations, in accordance with some embodiments of the present disclosure. The system architecture may comprise a process control operating system (OS) configured to communicate with both the real controller 428b and the virtual controller 426b. The real and virtual controllers may be operatively coupled to a plant simulation system configured to emulate plant operations. The interactions between the real controller, virtual controller, and the plant simulation system 430b may be enabled via the simulation interface 420b, thereby enabling the controlled simulated testing environment. Communication between the process control OS and the rapid testing system 902a may be established through the OPC client 418b, which enables the process control OS to interface with the rapid testing system 902a via an interface block, the interface block 416b configured to enable data exchange and command transmission between the systems. In an exemplary embodiment, the rapid testing system 902a may include one or more subsystems. A project management subsystem 414b may be configured to supervise and coordinate testing-related activities across the rapid testing environment. A test template library 404b may store a plurality of predefined templates usable by a test design subsystem 406b to generate and configure specific test scenarios. The test design subsystem 406b may be configured to generate test logics based on one or more signals or datasets obtained via the interface block. Additionally, the test design subsystem 406b may interact with the test template library 404b to access predefined test configurations for creating test cases.

[0133] The test execution subsystem 408b may be configured to perform execution of the generated test logics using parameters received from the test design subsystem 408b. The test execution subsystem 408b may support one or more modes of operation, including a manual execution mode 410b and a scheduled execution mode 432b, based on test requirements. A test management system 412b (the term ‘test management system’ interchangeably referred as ‘test management sub system’) may be configured to orchestrate the overall test workflow, confirming correct and systematic execution of tests. The test management subsystem 412b may further consolidate, store, and manage test results generated by the test execution subsystem for subsequent analysis and project documentation. The communication and data exchange architecture may be configured to ensure cohesive operation across all subsystems, with the interface block serving as a key communication bridge between the controller entities and the testing framework, thereby enabling a repeatable, traceable, and controlled testing environment.

[0134] FIG. 9B illustrates an exemplary flow diagram representation 900B of a rapid testing process 1200B utilizing a plurality of test scenarios executed and managed through various interconnected system components, in accordance with some embodiments of the present disclosure. The rapid testing process may be enabled by the test template library 404b configured to store and provide a plurality of predefined test templates. The predefined test templates are configured to be selected and utilized by the test design system 406b for creating one or more test scenarios.

[0135] Further he tests design system 406b may include 416b interfaces 416b block operably coupled to one or more external systems for enabling communication therewith. The interfaces block 416b is configured to receive a plurality of test signals 906, including operational signals from an operating system (OS) 910 and simulation signals from a simulation system 912, the plurality of test signals 906 being used as inputs for the testing process. Furthermore, the test design system 406b may constitute a primary functional module configured to define one or more test scenarios by selecting and incorporating test templates 902b-902n (individually referred to as the test template 902b and collectively referred to as the electronic devices 902b) from the test template library 404b. Each of the selected test templates 902b, such as test template-1 , may comprise a plurality of test objects (e.g., object-1 through object-n) 904b- 904n (individually referred to as the plurality of test objects 904b and collectively referred to as the test objects 904b), each corresponding to a particular component, element, or system functionality being subjected to testing.

[0136] Subsequent to the definition of the test template 902b and associated test objects 904b, the system is configured to receive and process a plurality of test signals via the interfaces block. The test design system 406b further defines one or more test parameters 908 corresponding to the test objects 904b. The test parameters 908 specify operational conditions, values, and thresholds required for evaluating the performance and behaviour of the test objects during test execution.

[0137] The test design system 406b may further comprise the test actions block 504 configured to perform the plurality or the set of test actions based on the defined test parameters 908 and received test signals. The test actions 504 include, but are not limited to, conditional actions (e.g., control structures such as "while" loops), logical operations (e.g., conditional statements such as "if"), value logging functions (e.g., trace functions for recording parameter values), verification operations (e.g., commands such as "verify until," "wait," and "wait until"), data manipulation operations (e.g., commands to retrieve or set values such as "get" and "set"), and simulation control commands (e.g., operations to start or stop tests, adjust simulation speed, or capture snapshots).

[0138] In addition, the integrated execution of test signals, test parameters 908, and the test actions 504 ensures systematic execution of the test scenarios designed within the test design system 406b, enabling comprehensive validation of system components and yielding structured and meaningful test results.

[0139] In an exemplary embodiment, a first user interface is generated to facilitate coordination of signal exchange with a coupling partner associated with one or more input data sources. The first user interface displays a plurality of action blocks that define various operations used within the testing framework. A second user interface is generated to enable creation of one or more test logics and corresponding executable test instances. The test instances are based on one or more predefined test parameters. Additionally, a third user interface is generated, which comprises a hierarchical tree for organizing one or more test sets, a work area for configuring and reviewing test sequences, a tree structure for managing the plurality of test instances, and the scheduler component adapted for planning and managing execution timelines of the test sets.

[0140] In an exemplary embodiment, the first user interface is generated to enable coordination of signal exchange with the coupling partner associated with one or more input data sources. The first user interface displays the plurality of action blocks that define various operations used within the testing framework. The second user interface is generated to enable creation of one or more test logics and corresponding executable test instances. The test instances are based on one or more predefined test parameters. Additionally, the third user interface is generated, which comprises a hierarchical tree for organizing one or more test sets, a work area for configuring and reviewing test sequences, a tree structure for managing the plurality of test instances, and the scheduler component adapted for planning and managing execution timelines of the test sets.

[0141] FIG. 9C illustrates an exemplary flow diagram representation 900c of a test execution process utilizing a test execution system 904c in conjunction with the rapid testing system, in accordance with some embodiments of the present disclosure. The test execution system 904c is configured to monitor and manage the execution of a plurality of test sets 456a-1 to 456a-N (individually referred to as the plurality of test set 456a and collectively referred to as the test set 456a). Each test set 456a, such as test set-1 through test set-n, comprises the plurality of test objects 904b (e.g., test object-1 through test object-n 914), each representing a specific component, function, or scenario subjected to validation within the corresponding test set.

[0142] Following definition of the test sets 902c, execution is performed in either the manual execution mode 410b (the term ‘manual execution mode’ is interchangeably referred as ‘manual mode’) or the scheduled execution mode 432b (the term ‘scheduled execution mode’ is interchangeably referred as ‘scheduled mode’). In the manual execution mode 410b, initiation of test execution is triggered by an operator based on real-time inputs or decisions. Conversely, in the scheduled execution mode 432b, execution is performed automatically at predefined time intervals or according to the predetermined test schedule, thereby enabling flexible test planning and autonomous operation. The interfaces block 416b is operably configured to enable communication between the test execution system 904c and one or more external systems or simulation environments. The interfaces block 416b confirms that relevant data, parameters, and test signals are accurately exchanged during the execution phase. Upon determination of the execution mode, the test execution system 903c proceeds to perform the test execution sequence. The sequence defines an execution order for each of the test sets 902c and corresponding test objects 904b. The execution process is structured to confirms systematic and sequential operation of the individual tests. During execution, the predefined test scenarios are applied to the respective test objects under conditions and parameters defined during the test design phase. This stage enables real-time evaluation of the behaviour and performance of the test objects in accordance with defined functional criteria.

[0143] Upon completion of the test execution process, the resulting data is aggregated and presented via the test results dashboard. The dashboard is configured to provide a consolidated view of the execution outcomes, including status indicators, pass / fail metrics, parameter values, and trend analysis. The test results dashboard enables post-execution review, analysis, and interpretation, thereby enabling validation of system behaviour, identification of anomalies, and data-driven decision-making regarding the tested components or systems.

[0144] FIG. 9D illustrates an exemplary flow diagram representation 900D of a test management process utilizing a test management system 902D in a rapid testing environment 902A, in accordance with some embodiments of the present disclosure. The test management system 902d is configured to oversee and coordinate the entire lifecycle of the testing process. A test dashboard 904d is provided as a centralized interface through which the user may access and monitor various aspects of test planning, execution, and analysis.

[0145] Further, the test documentation 920d module is configured to store and manage documentation related to the testing process, including but not limited to test plans, test cases, and test procedures. The test management system 902d further comprises a test set execution mode 906d selector, operable to configure execution in one of two modes. The scheduled execution mode 432b, in which test sets 902c are automatically executed at predefined times, and the manual execution mode 910b, in which execution is triggered by user initiation.

[0146] Further, the test execution system 904c further enables identification and display of test objects not included 908d in the current test set, allowing for selective execution and scope control. Upon execution, the test set 456a results are generated and categorized by test sets 902c, including results associated with a first test set (e.g., test set-1 results) through an nth test set (e.g., test set-n results). Each test set 456a comprises the plurality of test objects 904b, and corresponding results for each test object 904b (e.g., test object 1 -n results 914n) are recorded and stored for subsequent review. In addition, each test object 904b is associated with a set of test actions, and the results of the actions (e.g., test action 1 -n results) are captured by the test execution system 904c. The hierarchical structuring of test set results 912d-912n, test object results 916d-916n, and test action results 918d-918n enables comprehensive visibility into the functional behaviour of the system under test, supporting detailed diagnostics and quality assurance.

[0147] FIG. 10 illustrates an exemplary flow diagram a method 1000 for validating equipment and process behaviour in a technical installation, in accordance with some embodiments of the present disclosure.

[0148] At step 1002, the method 1000 includes receiving by the processor 122, one or more signals and input data corresponding to at least one of the equipment and the technical installation, from the plurality of input data sources. The plurality of input data sources comprises at least one of a distributed control system 112, the simulation subsystem 118, and data transmitting devices 108.

[0149] At step 1004, the method 1000 includes generating by the processor 122 one or more test logics using the plurality of action blocks, using the received one or more signals and test data. Each of the one or more test logics is associated with the plurality of test instances, each test instance 452a comprises one or more test parameters 908 used in the one or more test logics for the runtime value substitution.

[0150] At step 1006, the method 1000 includes creating by the processor 122, one or more test types using pre-defined test actions 504, based on the generated one or more test logics. The one or more test types are created to simulate and validate one or more operational scenarios of the at least one of the equipment and the technical installation.

[0151] At step 1008, the method 1000 includes creating by the processor 122, one or more test sets 902c using the created one or more test types, by arranging each of the plurality of test instances in the pre-defined order to form one or more test sequences for test execution.

[0152] At step 1010, the method 1000 includes validating by the processor 122, the one or more test sets 902c corresponding to at least one of the equipment and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution. At step 1010, the method 1000 includes executing by the processor 122, the plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets. The executing the plurality of test scenarios comprise managing one or more errors detected during the test execution.

[0153] At step 1010, the method 1000 includes generating by the processor 122, the report comprising one or more test results comprising individual results and aggregated results for the one or more test sequences and the plurality of test instances.

[0154] The present disclosure provides a method and system for validating equipment and process behaviour in a technical installation. The system allows for the creation of automated tests that can be executed repeatedly as needed, without manual intervention. This capability ensures that tests are consistently performed, and results are systematically stored for future reference. By automating the testing process, the system significantly reduces the need for manual testing efforts and minimizes the risk of human errors, thereby improving the reliability of test outcomes.

[0155] Further, the system facilitates continuous validation of automation projects through automated tests. This ongoing validation enhances the overall quality and efficiency of the automation solution, leading to more robust and dependable systems. Additionally, the system allows for the testing of the same actions with different parameter values, accommodating various test scenarios and enhancing the comprehensiveness of the testing process. The system provides a safe environment for continuous validation during virtual commissioning. This improves engineering efficiency and enhances quality and safety by reducing reliance on laborious manual testing procedures. Overall, the advanced automation capabilities of the system lead to increased engineering efficiency, improved quality of results, and a reduction in human errors, contributing to a safer and more effective testing environment.

[0156] While the present invention has been described in detail with reference to certain embodiments, it should be appreciated that the present invention is not limited to those embodiments. In view of the present disclosure, many modifications and variations would be present themselves, to those skilled in the art without departing from the scope of the various embodiments of the present invention, as described herein. The scope of the present invention is, therefore, indicated by the following claims rather than by the foregoing description. All changes, modifications, and variations coming within the meaning and range of equivalency of the claims are to be considered within their scope. All advantageous embodiments claimed in method claims may also be apply to system / apparatus claims.

[0157] List of Reference Numerals:

Claims

Patent Claims:

1. A method for validating equipment and process behaviour in a technical installation, comprising: receiving, by a processor (122), one or more signals and input data corresponding to at least one of an equipment and a technical installation, from a plurality of input data sources, wherein the plurality of input data sources comprises at least one of a distributed control system (112), a simulation subsystem (118), and data transmitting devices (108); generating, by the processor (122), one or more test logics using a plurality of action blocks, using the received one or more signals and test data, wherein each of the one or more test logics is associated with a plurality of test instances, each test instance (452a) comprises one or more test parameters (908) used in the one or more test logics for a runtime value substitution; creating, by the processor (122), one or more test types using pre-defined test actions (504), based on the generated one or more test logics, wherein the one or more test types are created to simulate and validate one or more operational scenarios of the at least one of the equipment and the technical installation; creating, by the processor (122), one or more test sets (902c) using the created one or more test types, by arranging each of the plurality of test instances in a pre-defined order to form one or more test sequences for test execution; validating, by the processor (122), the one or more test sets (902c) corresponding to at least one of the equipment and the technical installation, by determining logical consistency and completeness of a test setup prior to the test execution; executing, by the processor (122), a plurality of test scenarios using each of the plurality of action blocks comprising a plurality of testing modules, based on the created one or more test sets, wherein executing the plurality of test scenarios comprise managing one or more errors detected during the test execution; and generating, by the processor (122), a report comprising one or more test results comprising individual results and aggregated results for the one or more test sequences and the plurality of test instances.

2. The method as claimed in claim 1 , further comprising: receiving, by the processor (122), a request for a project creation to initiate a testing process; establishing, by the processor (122), a connection with the plurality of action blocks via a coupling feature for exchanging the one or more signals using one or more protocols; and obtaining, by the processor (122), the one or more signals from each of the plurality of input data sources via the established connection.

3. The method as claimed in claim 2, further comprises: managing, by the processor (122), a testing process by triggering the plurality of test scenarios within the plurality of action blocks; orchestrating, by the processor (122), execution of the one or more test sequences, based on the managed testing process, wherein the orchestration comprises managing a sequence of operations of the one or more test sequences; monitoring, by the processor (122), an execution of the one or more test sequences in real-time; and displaying, by the processor (122), intermediate test results on a display, based on the monitored execution of the one or more test sequences.

4. The method as claimed in claim 3, further comprises: processing, by the processor (122), the intermediate test results, by formatting the intermediate test results into a structured output format, wherein the structured output format comprises at least one of logs, performance metrics, and at least one of pass status and fail status of the intermediate test results; and storing, by the processor (122), in a database (116), one or more test outcomes of the executed one or more test sequences in a plurality of formats.

5. The method as claimed in claim 3, wherein monitoring execution of the one or more test sequences, further comprises: validating, by the processor (122), the one or more test parameters (908) with one or more pre-defined thresholds values; validating, by the processor (122), the one or more signals and the one or more test parameters (908) during the test execution to confirm correct configuration and functionality of the test execution; testing iteratively, by the processor (122), the one or more test sequences, through a feedback loop based on one or more test outcomes; and modifying, by the processor (122), the one or more test parameters (908) and the one or more operational scenarios associated with the one or more test sequences, based on testing the one or more test sequences.

6. The method as claimed in claim 1 , wherein orchestrating the execution of the one or more test sequences, further comprises: executing, by the processor (122), the one or more test sequences in at least one of a manual mode (410b) initiated by a user and a scheduled mode (432b) at predefined times; and managing, by the processor (122), substitution of one or more parameter values during execution of the plurality action blocks, by: identifying, by the processor (122), one or more parameter fields in the plurality action blocks; and substituting, by the processor (122), one or more pre-defined values for each of the plurality of test instances, based on the identification.

7. The method as claimed in claim 1 , further comprising:generating, by the processor (122), a first user interface for coordinating an exchange of the one or more signals from a coupling partner associated with the one or more input data sources, wherein the first user interface displays the plurality of action blocks; generating, by the processor (122), a second user interface for generating the ore more test logics and creating an executable plurality of test instances corresponding to the one or more test parameters; and generating, by the processor (122), a third user interface comprising a tree for the one or more test sets, a work area, a tree for the plurality of test instances, and a scheduler for planning execution of one or more test sets.

8. The method as claimed in claim 1 , wherein managing errors comprises: detecting, by the processor (122), at least one of communication errors and validation errors during the test execution; and receiving, by the processor (122), feedback from the user to correct the errors before proceeding with the test execution.

9. The method as claimed in claim 1 , wherein the plurality of action blocks comprises internal variables, test instance parameters, basic modules configured to perform functions comprising setting and reading signal values associated with the one or more signals, advanced modules configured to perform functions comprising signal tracing and conditional branching of the one or more signals, and remote-control interface modules configured to manage interactions with a simulation environment.

10. The method as claimed in claim 9, wherein the basic modules are further configured to perform functions comprising at least one of pausing execution for a specified time, pausing execution until a condition is met, verifying conditions, verifying conditions over a specified period, and resetting signals to an initial state.11 . The method as claimed in claim 9, wherein the advanced modules are further configured to perform functions comprising at least one of tracing signal values at intervals, stopping signal tracing and storing aggregated values, prompting user acknowledgment, writing data to a file, executing conditional branching based on a condition, looping execution until a condition fails, and setting signal values for a specified duration.

12. The method as claimed in claim 9, wherein the remote-control interface modules are configured to perform functions comprising at least one of creating a snapshot of a simulation environment, loading a snapshot, adjusting simulation speed, and setting a simulation state.

13. The method as claimed in claim 1 , wherein the plurality of input data sources comprise at least one of programmable logic controllers, human-machine interface systems, supervisory control and data acquisition systems, field instruments, input / output modules, industrial networks, process equipment, safety systems, historian databases, remote terminal units, programmable automation controllers, process measurement meters, and digital simulation and visualization technologies comprising at least one of digital twins and virtual sensors.

14. The method as claimed in claim 1 , wherein the one or more signals comprise at least one of operational signals from an operating system and simulation signals corresponding to derivative of real-time conditions associated with at least one of the equipment and the technical installation.

15. A computing system comprising: one or more processor(s) (122); and a memory 124 coupled to the one or more processor(s) (122), wherein the memory 124 comprises an equipment and process behaviour validation module stored in the form of machine-readable instructions executable by the one or more processor(s) (122), wherein the equipment and process behaviour validation module is capable of performing a method according to any of the claims 1 -14.

16. A computing environment comprising: one or more user devices; one or more technical installation comprising one or more assets; and a computing system communicatively coupled to the one or more technical installations and the one or more user devices via a network, wherein the computing system comprises an equipment and process behaviour validation module capable of performing a method according to any of the claims 1 -14.

17. A computer program product comprising machine-readable instructions stored therein that, when executed by one or more processor(s) (122), cause the one or more processor(s) (122) to perform a method according to any of the claims 1-14.

Images