The Use of Discrete-Deterministic Models in the Development of Software for Controlling Autonomous Electric Power Plants

At present, there is a tendency to move from centralized control systems of power plants to distributed control systems, which reflect a growing need for enhanced flexibility, scalability, and reliability of the systems that have a few hierarchical levels. Existing software frameworks for power plant automation, such as Supervisory Control and Data Acquisition (SCADA) systems, have limitations when applied to Autonomous Electric Power Plants (AEPPs). While SCADA provides reliable monitoring and remote control capabilities, it lacks the adaptability needed to support dynamic structural changes within AEPPs. Furthermore, most existing control frameworks struggle to provide effective solutions for real-time synchronization of diesel-generator units (DGUs) and the efficient distribution of active and reactive loads. Traditional algorithms for generator synchronization and load management are often hardware-dependent and difficult to modify, which limits their applicability in distributed power networks. This lack of adaptability is particularly problematic for AEPPs, where multiple generators operate in parallel and require constant monitoring and reconfiguration based on network conditions.

 Although papers [1, 2] emphasize the importance of distributed systems in modern automation, the specific challenges related to AEPPs (e.g., real-time synchronization of DGUs, load sharing, and adaptability to dynamic configurations) are not addressed. Additionally, the works lacks a formalized framework for transitioning from design models to executable software. In the context of AEPPs, distributed control systems minimize hierarchical layers while improving system responsiveness. However, the adoption of these systems presents several critical challenges. Specifically, developing software for automated control systems (ACS) that can reliably monitor, manage, and synchronize complex generator networks in real-time remains a key issue. This is particularly important given that AEPPs often feature multiple DGUs with varying load demands and power distribution structures, which must be reconfigured dynamically during operation. One of the most difficult stages in the implementation of automated control systems (ACS) is the development of software that not only controls the operational parameters but also adapts to the power plant’s structural changes [3, 4]. These papers explore predictive control for microgrid systems, analyzing key factors like reliability and controllability. It provides insights into load balancing and control under uncertain conditions, which align with some of the challenges in AEPPs. However, microgrids and AEPPs differ in their operational structure, particularly in the synchronization of multiple generators and dynamic load sharing. Those papers do not cover modular software verification or real-time control algorithm synthesis. Operators require precise, real-time information about both plant parameters and system structure, typically visualized through mnemonic diagrams. These diagrams, which use visual metaphors to represent key components, facilitate intuitive control and monitoring. The core challenges this study addresses is the lack of formalized methods for designing ACS software that ensures both adaptability to structural changes and long-term reliability under AEPP-specific conditions.

In the study conducted by Kabbara et al. [5], several advances and future directions for virtualized control in power systems were considered, but it emphasized the need for research into scalable architectures that can handle diverse power system components without performance degradation. Existing methods, described by Kabbara et al. [5], don't sufficiently cover the real-time interaction between virtual components and hardware, leading to uncertainty in operational performance under stress conditions.

A critical review of related work highlighted additional limitations. SCADA systems, traditionally used for top-level control [6, 7] offer reliable monitoring and control but are not designed to support dynamic structural changes in AEPPs. With regard to the AEPP, the ACS should be able to automatically or remotely start and stop DGUs, synchronize the diesel-generators (DGs) with the buses of the main switchboard (MSB), share the active and reactive load between the parallel operating DGs, monitor the status of the AEPP main equipment and others. However, existing solutions for automating DGUs, such as synchronizing them with MSB and balancing active/reactive loads [8, 9] often lack the flexibility needed for the dynamic nature of AEPP operations.

Some researches explored IoT technologies for automating ship operations [10] and vessel maintenance [10], but he application of such technologies in AEPPs remains underexplored. The study of Kamolov and Park [10] is relevant as it demonstrates the potential of IoT to enhance automation. To analyze the reliability of IoT the technique described in the study [11] can be used. However, it leaves open questions about how these technologies can be integrated into AEPP ACS software to support real-time control and monitoring. This study aims to fill that gap by exploring how advanced software design approaches, informed by IoT frameworks, can improve AEPP automation.

As reported by Bayer et al. [12] and Koc et al. [13], Unified Modeling Language (UML) diagrams are widely used in the software engineering to visualize system interactions, but their use in AEPP automation software is under-researched. UML diagrams provide a structured way to model software components, but their application in AEPPs presents unique challenges, such as the need to adapt to evolving plant structures in real-time. However, Koc et al. [13] demonstrated that the application of UML to real-time control systems like AEPPs is not covered. In this case UML, which is a visual language to define and document a system [13, 14], can be used to describe scenarios that express how users use a system, and how different parts of the system interact with each other. Due to the fact that software development for ACS AEPP is a complex process, and there are a number of methods for assessing software complexity [15]. Every aspect of a system or application should be determined to develop software. Existing publications [16-18], highlight the use of UML in various industries, from electromechanical control systems to railway diagnostics, but do not address AEPP-specific requirements. UML also offers cost-saving advantages in software development [19]. But existing researches lacks practical frameworks for using UML in conjunction with discrete-deterministic models to handle the specific requirements of AEPPs. This paper addresses these gaps by proposing a systematic methodology that integrates both tools, offering a more formalized approach to designing reliable, adaptive ACS software.

Worku et al. [20] focused on power management and synchronization strategies in microgrids using real-time control methods. It provides insights into the importance of maintaining voltage stability and load balancing to ensure system reliability. But it does not provide a comprehensive modular software framework or formalized verification process for control systems. This can be addressed by introducing UML diagrams and discrete-deterministic models to develop and verify AEPP software components. A hierarchical control system for reconfigurable solar power plants was considered by Debnath et al. [21]. The issues how power systems can self-adjust to changing operational conditions, aligning with the goals of AEPPs, were discussed. At the same time, that paper primarily focused on solar-based plants and lacks detailed software engineering approaches such as formal verification with UML models.

When developing software for specialized systems like AEPPs, it is crucial to use modeling approaches that facilitate the formalization and quality assurance of software components. As reported by Al-Suod et al. [22], the theory of digital automata offers a robust framework for defining discrete-deterministic software models. UML state diagrams, in particular, can represent the finite state behavior of software components. Then the software being developed will be a network of interacting digital state machines, obtained by composing individual discrete-deterministic models, which lends itself well to formalizing the description of the software operation process. Also, this deterministic modeling approach ensures that AEPP software can be implemented reliably in an object-oriented programming environment.

Existing scientific publications provide useful insights into distributed control, automation frameworks, and modeling techniques, but significant gaps remain regarding their application to AEPPs. In particular, there is limited research on software tools and methods that support the real-time, remote control of DGUs while accounting for AEPP-specific complexities. Currently, the issues of the processes of substantiating, evaluating, and selecting options for developing ACS for specialized purposes lack formalization and hinder the comprehensive consideration of several significant parameters when choosing solutions, as was stated by Lyaskovskiy et al. [23] and Garcia et al. [24], remain unresolved. Therefore, further underscoring the need for systematic, adaptable software design approaches.

The analysis of publications showed that the problems of creating specialized software for automated remote control of DGUs in real time, taking into account the specifics of work in AEPP conditions, are not sufficiently covered. UML is typically used for static design and documentation, and its integration with digital automata for real-time software implementation remains unexplored. Given the fact that information technologies are developing extremely rapidly, publications of other scientists 5-10 years ago on this issue can be considered to have lost their relevance and do not meet modern challenges.

The aim of this research is to address these gaps by developing a structured method for designing ACS software that meets the unique demands of AEPPs. The research focuses on using UML diagrams and discrete-deterministic models to create a software architecture that can adapt to changing AEPP structures. UML state diagrams are used to graphically represent the behavior of each software component. They formalize how components respond to various events and how transitions between states occur. By leveraging these tools, the aim is to enable the seamless transition from conceptual models to code implementation while ensuring software reliability, quality, and cost-efficiency. The results will contribute to the development of more advanced, adaptive automation systems for AEPPs, enhancing the controllability and resilience of power generation processes.

A key challenge in developing ACS software is ensuring that all software components behave predictably under varying operational conditions. To address this, this research adopts discrete-deterministic models, which represent the behavior of each software component as a finite set of states. Each state encapsulates a specific operational condition of the component, while state transitions occur in response to events, such as power fluctuations or load adjustments. This modeling approach ensures that the system can respond deterministically – meaning that every input leads to a predictable output, crucial for AEPP reliability. To formalize these models, UML state diagrams are used. UML state diagrams are visual tools that depict the different states a system or component can occupy and define the transitions between them. In this research, each state diagram corresponds to a specific software module within the AEPP ACS.

The first step in the software development is to decide on the circuit components. Components are understood as graphic symbols and designations corresponding to physical (for example, a generator) or virtual (for example, a text field for displaying generator parameters) elements of the AEPP. Components can be divided into three groups:

• Components that have a connection with other components (“Circuit Breaker”, “Transformer”, “Diesel”, “Generator”, “Induction motor” etc. for drawing up a block diagram).
• A component for communication (“Bus”).
• Components that have no connection with other components.

Figure 1 is a UML class diagram that shows the relationships between core software classes, such as the DGU class, synchronization class, and control buttons, the key interactions between the system’s components, data flows between modules and how commands propagate throughout the system. The software architecture for the AEPP control system follows a modular, layered design to ensure flexibility, scalability, and maintainability.

1.png

Figure 1. Basic class diagram

In Table 2, the symbols used in Figure 1 and the classes designed to perform the functions of monitoring parameters and controlling the AEPP are described. The relationships between classes are inheritance and aggregation. Each component plays a defined role, and their interactions are modeled using UML diagrams to maintain consistency between design and implementation. Each block in the UML class diagram encapsulates a digital state machine whose behavior is determined by its functional purpose. Transitions between the states of the components are triggered by real-time data inputs from equipment sensors and control commands from the operator interface. By using discrete-deterministic models, the software ensures that each DGU follows a precise sequence of operations, minimizing the risk of misoperation.

Table 2. Correspondence of block names on the diagram to components and classes

The DGU class (K2.1.1), and other classes, inherits basic functions from a basic linkable class (K2.1), while the synchronization class aggregates real-time input data from DGUs and the MSB. The Control Button class (K2.2.2) sends commands to DGUs, initiating synchronization or load sharing. For example, when the Power Plant Control Operator triggers a synchronization request through the Control Button, the synchronization class retrieves real-time voltage and frequency values from the DGU and MSB (K2.4, K2.5). If the conditions match, the synchronization process completes, and the DGU transitions to the “Active” state.

The interaction between objects in the system is carried out through messages, among which the following groups can be distinguished:

• messages between the work area and components regarding graphic actions (denoted conditionally as a set of actions $W=\{w 1, w 2 \ldots\}$; these actions are implemented using base classes, so the message group applies only to base classes and workspace.
• messages between the work area and components regarding data exchange (multiple actions $D=$ $\{d 1, d 2\}$); these messages refer to components that provide data exchange with automation controllers in network mode ("Diesel-generator", "Generator", "Automatic switch", "Control button", "LEDs").
• messages between components (set of actions $V=$ $\{v 1, v 2\}$); a group of messages refers to changing the color of the buses and related components when the Automatic switch state changes and displaying the parameters of the generator received during the data exchange.

In Table 2 the correspondence of markings in Figure 1 to components and classes is presented. The purpose of DGU is to generate electricity and maintains power levels during AEPP operation. The DGU component (K2.1.1) interacts with the synchronization component to connect to the main switchboard. The parameters of DGU are voltage (230V/400V), frequency (50/60 Hz), and active power output (100-500 kW). Synchronization system synchronizes DGUs with the MSB by matching frequency and phase angles. The component is represented by the Synchronization button (Control button, K2.2.2) on the user interface, settings panel (dialog box, K2.4, K2.5), and automated synchronization hardware.

The dialog boxes may contain various indicators (K2.2.3 – K2.2.6) are used to show the measured parameters in a user-friendly manner. The software displays parameter updates with a latency of ≤1 second. Updates include generator status, load conditions, and synchronization processes. Control Button (K2.2.2) components, which can be latched (holds state after activation) and non-latched (momentary action), initiates DGUs and induction motors (K2.1.4, K2.1.5) start/stop commands, synchronizations, and DGUs load sharing adjustments. The software should redistribute loads within 2 seconds following the disconnection of a generator, maintaining a load balance error below ±2%. Bus component (K2.3) and Automatic switch (K2.1.6) facilitates communication between DGUs, transformers (K2.1.7), induction motors and the MSB. The Bus component includes multiple color-coded connections to represent different states of communication and power flow.

Figure 2 shows the communication flow and state transitions among components.

The Work Area initiates requests to automation hardware via a communication bus. Data from the DGUs (e.g., power output and frequency) is transmitted to the Load Sharing System and visualized in the operator interface. Upon detecting anomalies (e.g., voltage fluctuations), the Load Sharing System sends corrective commands to the DGUs to redistribute the load dynamically. The system waits for real-time input from DGUs. If a DGU goes offline (“Inactive” state), the system initiates a load redistribution process through the Load Sharing System. Once load sharing is complete, the system returns to normal monitoring mode.

2.png

Figure 2. Interaction between elements of the software

In the mode of control and AEPP parameters monitoring, the software must perform several tasks:

– Data exchange with automation equipment includes transmitting operator commands and reading, displaying, and processing discrete and analog values captured by the hardware;

– Accumulation of statistical data on the load of the communication channel – the amount of bytes transmitted and received per unit of time;

– Accumulation of data about the diesel-generator units operating modes: the average values of the power they generate to the overall load during a specific period.

A unit of data exchange is a transaction comprising a request and its corresponding response – sending and receiving data packets using a serial port. The input influences associated with messages from the operating system during operator interaction with the software, the operation of timers and actions with the serial port, are marked as е1 - switching the software to the mode of power plant control; е2 - switching the software to the mode of the scheme design; е3 - the data packet received; е4 - place the cursor within the component area; е5 - the change in the structure of the power plant; е6 - the timer event; е7 - the load on at least one DGU exceeds permissible ranges; е8 - the synchronization window was opened; е9 - setting values received; е10 - the status of the generator circuit breaker was updated; е11 - the RMS of voltages, frequencies and phase difference between voltages were gained; е12 - changing reference point values; е13 - the control parameters were changed; е14 - the data packet was received; е15 - error when opening serial port; е16 - the synchronization dialog window was closed; е17 - the start of the synchronization process; е18 - the component received the data; е19 - mouse left button click; the input variables corresponding to the result of performing certain actions, as х1 - error in data packet; х2 - the error has been resolved; х3 - the error cannot be corrected without substituting the hardware; х4 - the connection is active: х4.1 - with the at least one display components, х4.2 - with one of the DGU protection components; х5 - the data has been generated; х6 - the request queue contains items; х7 - the data was forwarded to the component; х8 - the timer is active; х9 - for DGU protection, the data acquired by the Load Sharing System is in use; х10 - the data measured independently is used for DGU protection; х11 - the direct condition is met; х12 - the opposite condition is met; х13 - the DGU operates in parallel with other DGUs; х14 - the generator circuit breaker is in the close position; х15 - there are no items in the queue; х16 - database entry is permitted; х17 - displaying of the data packet contents is permitted; х18 - the database connection error; х19 - database connection error fixed; х20 - the system for correcting the diesel revolutions and/or the generator excitation is turned on, and the resulting operations that occur when specific combinations of input factors and variables marked as z1 - add request packets to the queue: z1.1 - Generator parameters (RMS values of voltage and current, frequency, and the power factor); z1.2 - the indicators needed to ensure the functions of DGU protection; z1.3 - close the discrete output; z1.4 - open the discrete output; z1.5 - sync parameters and control configurations; z1.6 - the data about the generator circuit breaker state; z1.7 - the current values of frequencies, voltages, and the phase shift angle between the voltage vectors of the MSB bus and the operating DGU; z1.8 - change synchronization configurations; z1.9 - change control configurations; z1.10 - the state of the section's generator circuit breakers; z1.11 - the data required to calculate the power generated by DGUs operating in parallel; z1.12 - enable corrective measures for frequency and voltage control; z1.13 - disable corrective actions for frequency and voltage regulation; z1.14 - activate the circuit breaker/relay; z1.15 - deactivate the circuit breaker/relay; z2 - queue request removal; z3 - data transfer to the component; z4 - the timer activated; z5 - the data displaying; z6 - the timer disabled; z7 - create a queue for data exchange; z8 - alter the bus color; z9 - dispatch the request data packet to the automation hardware; z10 - send data to a state that initiates the data exchange process; z11 - extract the request from the stack; z12 - initiate a permanent queue for requests; z13 - open the serial port; z14 - close the serial port; z15 - remove the request; z16 - save data about the state of loads and loads of the DGU; z17 - show the data packets content, then the explained behavior of the Work area class in the mode of the power plant control can thus be modeled by the finite state machine $A_8=\{Q, X, E, Z, f, g\}$, where $Q=\{q 0-q 8\}$ - automaton states set: q0 - initial condition; q1 - awaiting the initiation of the data exchange cycle; q2 - pending a reply to the request; q3 - pending the database entry; q4 - database entry; q5 - database connection error; q6 - waiting for synchronization of the diesel generator with the main switchboard buses; q7 - synchronization of the diesel generator with the main switchboard buses; q8 - waiting for control actions to be turned off for frequency and/or voltage control systems; X, E, Z - groups of permissible input influences, input parameters and resulting actions, described above; f and g - state functions and output symbols, presented as a UML state diagram in Figure 5 [25].

The Generator component behavior can be described as a final state machine $A_9=\{Q, X, E, Z, f, g\}$, where $Q=\{q 0-q 7\}$ denotes the collection of automaton states: q0 – the initial condition; q1 – awaiting a response to a request; q2 – data packet check; q3 – there is no connection with automation tools; q4 – transferring data to the DGU protection component; q5 – transmission of data to display components; q6 – waiting for generator parameter values to be displayed; q7 – display of generator parameter values; f and g are state functions and output symbols, presented in the form of a UML state diagram in Figure 6.

5.png

Figure 5. State diagram of the work area class in the AEPP parameters monitoring and control

6.png

Figure 6. UML state diagram of the generator class

7.png

Figure 7. State diagram of the Load Sharing class

8.png

Figure 8. State diagram of the synchronization system class in the monitoring and control mode of AEPP parameters

In the initial state (q0) the component waits for the software to enter the power plant monitoring and control mode. When this event occurs, the parallel execution of several processes begins: data exchange with automation tools (states q1 – q3); simultaneous transfer of Generator parameters obtained during successful data exchange to the indication components (q4) and, if the information flow minimization mode is enabled, to the Protection component of this DGU (q5); displaying Generator parameters in the tooltip window when moving the cursor over the component (q6 – q7).

The behavior of the Load Sharing System component can be described in the form of an automaton $A_{10}=\{Q, X, E, Z, f, g\}$, where $Q=\{q 0-q 11\}$, denotes the states of the automaton. The UML state diagram is shown in Figure 7.

In Figure 7 the states are: q0 – the initial state; q1 – pending a response to a request; q2 – data packet check; q3 – no connection to automation equipment; q4 – checking the section structure; q5 – waiting for the DGU workload to be checked; q6 – waiting to receive the power values generated by each DGU to the total load of the section; q7 – data packet check; q8 – calculation of deviations of real values of DGU loads from ideal ones; q9 – waiting for a response to the command to enable control actions; q10 – data packet check; q11 – no connection to automation equipment; f and g are state functions and output symbols.

When the software switches to the scheme designer mode, the Work area sends a relevant message to the Load Sharing System. When it is received, the component checks for the presence of enabled control actions and, if they are present, sends a command to disable them.

The synchronization system component is a control button and associated dialog box that is displayed when the user clicks it in the AEPP parameters monitoring and control operational mode. The UML state diagram of the synchronization system class presented in Figure 8.

As stated above, due to the peculiarities of the hardware implementation of the synchronization device, when opening a dialog box, information exchange with other automation tools must be temporarily blocked. Then the algorithm of the synchronization system can be represented as an automaton: $A_{15}=\{Q, X, E, Z, f, g\}$, where $Q=\{q 0-q 9\}$, represents the states of the automaton: q0 – initial state; q1 – waiting for data; q2 – data packet check; q3 – no connection with automation equipment; q4 – checking the condition of the generator circuit breaker; q5 – synchronization completed; q6 – waiting to receive values of voltages, frequencies and phase angles; q7 – data packet check; q8 – waiting for the feedback from the generator switch to operate; q9 – no connection with automation equipment; q10 – waiting for synchronization settings to change; q11 – waiting for data about the result of changing the settings; q12 – checking the data packet with the result of executing the command to change the synchronization settings; q13 – waiting for changes in control action parameters; q14 – waiting for data about the result of changing parameters; q15 – checking a data packet with the result of executing a command to change the parameters of control actions; q16 – no connection with automation equipment; q17 – waiting for process of data exchange; q18 –pending a response to a request; functions f and g define states and output symbols.

When the dialog box opens, the state machine goes into states q1 – q3, corresponding to polling the values of the synchronization settings, parameters of control actions for correcting the diesel revolutions period and excitation of the generator. Next, in state q4, the state of the generator switch is polled: if it is closed (the DGU is switched on for parallel operation with the main switchboard buses), the synchronization system displays this situation and goes to state q5, awaiting further user actions. Alternatively, the user can initiate the synchronization process at the hardware level by clicking the appropriate button in the dialog box, after which the processes in the synchronization system are divided into three components: data exchange with hardware (q17 – q18), changing synchronization settings or control action parameters (q10 – q16), generation of queries and display of current values of frequency and voltage differences, phase difference between the main switchboard bus voltage vectors and the generator (q6 – q8).

This research contributes to the development of adaptive ACS software for AEPPs by combining UML diagrams with discrete-deterministic models. The proposed methodology ensures predictable software behavior, smooth design-to-code transitions, and adaptability to changing system configurations.

Based on the analysis of the tasks solved by the ACS AEPP software, the requirements for its functionality were described, which made it possible to determine the operating modes of the software (scheme designer mode and the AEPP monitoring and control mode), the composition of the component library and the requirements for each component. The discrete-deterministic models of ACS AEPP software components were developed using the concept of digital automata. These models enabled the formalization of the analysis and synthesis of control algorithms, ensuring that the behavior of each software component is predictable and systematically defined. The adoption of UML state diagrams as a specification language facilitated a seamless and formal transition from system requirements to algorithmic behavior and corresponding program code, ensuring consistency throughout the development process.

The scientific novelty of this research lies in the integration of discrete-deterministic models with UML state diagrams for AEPP control software. While previous studies have employed these methods individually, their combined application to formalize both algorithm synthesis and software verification in the context of AEPP automation is novel. This approach not only ensures a more reliable transition from design to code but also introduces a methodology for hierarchical and modular software verification, significantly improving the efficiency and accuracy of testing processes for complex, distributed systems. The resulting framework provides a robust, scalable solution that aligns with the latest advancements in control theory and automation, addressing critical challenges in the development of ACS for AEPPs. By addressing the challenges of software reliability, modularity, and real-time control, this study lays the foundation for more advanced automation solutions in AEPPs, meeting the demands of modern power generation. The methodology proposed in this work goes beyond AEPPs and has the potential to influence other domains that require adaptive control systems, such as microgrids, industrial automation, and smart grids. By demonstrating the practical use of UML in tandem with digital automata, this research contributes to best practices in software engineering for complex, distributed control systems.