The Development of a Malleable Model for Critical System Supervision Integration

Abstract

Critical systems, in which failure and malfunction may result in severe human, environmental, and financial damages, are essential components in various sectors and particularly in energy domains. Although undesirable, integration error problems in the supervision of critical systems do occur, incurring significant expenses due to an operator’s subjective analysis and hardware topology failures. In this work, a malleable model design approach is proposed to formulate and solve the integration error problem in critical systems’ supervision in terms of reliability. A real hybrid power plant (HPP) case is considered for a case study with simulated data. A method framework with an informal approach (C4 diagram) and formal approach (hierarchical colored Petri nets) in a radial spectrum is applied to the HPP supervision design. In using formal methods, a formulation and solution to this problem through structured, scalable, and compact mathematical representations are possible. This malleable model is intended to guarantee the functional correctness and also reliability of the plant supervision system based on system software architecture. The outcomes suggest that the malleable model is appropriate for the energy domain and can be used for other types of critical systems, bringing all the benefits of this methodology to the context in which it will be applied.

1. Introduction

Critical system engineering focuses on blending human skills with information technology (IT)-enabled technical systems to achieve societal and industrial objectives since the failure and malfunction of these systems may result in severe human, environmental and financial damages [1,2]. In essence, critical systems are crucial technological backbones that require rigorous design, development, and testing processes to ensure their correct operation. In this context, the supervision of these systems has a fundamental role as it provides the needed information in order to make decisions correctly and in a timely manner.

Critical systems are essential components in various sectors like aerospace, banking, and manufacturing and particularly in energy domains. For example, a hybrid power plant (HPP) is a kind of critical system, which can be understood as a physically coupled power-generating facility that converts primary energy (for example, wind, photovoltaic, and storage assets) into electrical energy. Typically, an HPP is composed of two or more types of renewable energy sources (RESs) operating as an integrated system and is considered a compelling option for meeting the high load demands for electrical energy in an intelligent way.

The operation of an HPP is considered complex due to its number of elements, such as assets, transducers, local controllers, and data servers, which interact with each other or with the HPP’s environment, with distinct properties that arise from these interactions [3]. In addition, the occurrence of uncertainties during the operation related to economic, political, technical, regulatory, environmental, resource availability, social, and climate aspects can result in serious problems of generation stability and power quality [4]. Therefore, the adequate integration of an HPP automation system is mandatory to guarantee plant supervision and control.

Although undesirable, integration error problems in the supervision of critical systems occur. Reports validate that inadequate handling by an unqualified operator leads to incidents in supervisory control and data acquisition (SCADA) systems, as seen in the Enbridge Incorporated pipeline rupture on 25 July 2010 [5]. Research findings suggest that 30% of all incidents on SCADA systems are attributable to internal staff [6]. Moreover, essential authentic data for evaluating threats posed by operator errors in a SCADA system are not accessible to the public due to privacy concerns, making this type of problem difficult to detect.

Thus, a way to address this type of problem is through reliability studies (reliability is the attribute of a system performing its intended function appropriately for a specified period of time or in a defined environment without failure). In the energy domain, reliability is one of the most significant properties of power plants, wherein problems related to it can have a negative impact on energy supply and security. Currently, traditional reliability modeling approaches such as the reliability block diagram (RBD), fault tree analysis (FTA), and Markov analysis (MA) are widely employed in energy system reliability studies and evaluations [7,8].

An RBD is a graphical representation of system’s reliability that breaks down complex systems into series, parallel, and mixed configurations of blocks representing components. The main advantages of this method are the following: providing visual representation, which aids in understanding the system architecture and dependencies; enabling quantitative analysis, which allows for the calculation of system reliability, component reliability and availability; and versatility for modeling various system configurations and scenarios. The main limitations are the following: the possibility of oversimplifying interactions between components; static representation; the method not accounting for dynamic behaviors or interactions during maintenance; and the fact that the management of large or complex RBDs can be challenging.

FTA analyzes potential failure modes in a system by constructing a tree-like structure starting from top-level system failures down to basic causes. The main advantages are the following: it provides a systematic approach to identifying and analyzing potential failure scenarios; it captures dependencies and interactions among events leading to system failures; and it provides quantitative and qualitative analysis options (probability and importance analysis). The main limitations are the following: the method requires detailed knowledge of system failure modes and event relationships; complex analysis may require significant time and effort; and the method assumes events are independent unless explicitly modeled.

MA models system reliability over time using state transitions based on probabilistic rules, capturing dynamic behaviors such as component degradation and repair. The main advantages are the following: it provides dynamic modeling of system behavior over time; it accounts for transitions between operational, failed, and repair states; and it quantifies steady-state probabilities and performance metrics (availability and reliability). The main limitations are the following: the method requires accurate estimations of transition probabilities; complexity increases with larger state spaces and more intricate system behaviors; and its initial setup and validation can be time-consuming.

In a nutshell, an RBD provides a static view of system reliability and configuration, FTA offers a systematic approach for analyzing specific failure scenarios, and Markov analysis models dynamic system behavior over time. Usually, applications are used in a complementary way: RBDs can inform FTA by defining system architecture, while MA can utilize FTA results to refine state transitions.

However, these approaches incorporate subjective analysis because they are typically performed manually by reliability engineers, whose skills and experience play a considerable role in determining the functional correctness of the system (functional correctness is the characteristic of a system to attend to its specification). Moreover, these methods are dependent on hardware topology, whose different types of configuration (simple cascading, redundant cascading, ring, star, and hybrid) change the reliability rate and make it difficult to flexibly adjust the system. As the integration and complexity of current energy systems develop, reliability engineers find it increasingly challenging to understand the actual behavior of the systems, with it being more likely to contain errors in the results, which reduces the reliability assessment’s accuracy.

In this context, a critical system must be extremely reliable and maintain this reliability as it evolves, without incurring exorbitant expenditures. Due to this, there is a need to build a proposal solution that does not depend on the operator’s subjectivity nor on the hardware topology in order to guarantee functional correctness and reliability during supervision. Over the years, many researchers have already contributed to the field of systems reliability modeling [9], and software-based reliability analysis is considered “the need of the hour”. Recently, Mamdikar et al. [10] employed the UML model conversion into the Petri nets (PNs) for the nonfunctional requirement analysis of critical systems. The dynamic behaviors and state-transition probabilities of the system are used to obtain the reliability accuracy. However, the methodology is based on the hardware failure having limitations of a broader system performance evaluation.

Thus, a solution based on system software architecture is a promising trend of research in software engineering, in which it is made possible for engineers to work with logical diagrams and causal relationships in different spectra using the malleable modeling concept [11]. The ideal degrees of abstraction, strictness, and granularity for a malleable model may be achieved with an adaptable blend of informal diagramming and formal modeling. However, this tendency does not indicate a methodological approach for complete implementation of a malleable model, as it deals with this topic from an informal (informal methods are more qualitative than quantitative and frequently base their conclusions on the recommendation of experts) to a formal (formal methods are mathematically strict techniques for specifying, developing, analyzing, checking, and validating software and hardware systems) perspective and vice versa, without gathering the best aspects of all spectra of the integrated way to be applied for the supervision system development.

In this work, a malleable model design solution is proposed to formulate and solve the integration error problem in the critical systems supervision, considering all automation layers of an HPP real-unit test case. To present the proposed methodology, a C4 diagram is used as an informal approach, with logical modeling with hierarchical colored Petri nets (HCPNs) used as a formal approach, which are powerful tools in the plant supervision design.

The novelty of the proposed method lies in its software approach instead of human subjective analysis and hardware-topology-dependent approaches, thereby enhancing adaptability. In this case, adaptability is associated with the possibility of changing the procedure that constitutes the informal and formal approaches but without changing the method framework of the malleable model regardless of the nature of the system being designed.

By utilizing a malleable model for all automation layers of a critical system, the method surpasses traditional representations, showcasing a new perspective to evaluate the reliability for critical systems. Moreover, the utilization of a malleable model enables the application of a formal methodology, allowing for the representation of the dynamic behavior of critical system supervision in a succinct, detailed, straightforward, structured, and pragmatic manner. Conducting formal analysis, performing validation, and checking methods is crucial to ascertain and assess the functional correctness and reliability of the specified framework.

To do so, the remainder of this work is organized as follows. In Section 2, the theoretical reference is described. In Section 3, the methodology is detailed. In Section 4, a case study is explained. In Section 5 and Section 6, the main discussions and conclusions are presented.

2. Theoretical Reference

A critical system requires a high level of reliability to ensure safety and efficiency. Research in the area of critical system reliability emphasizes the importance of hardware topology and operator skill to making decisions. However, there is growing concern regarding the lack of studies addressing the reliability of these complex systems from a software perspective, with researchers looking to work on domain-specific problems to improve reliability metrics and approaches. Overall, this work highlights the crucial role of software in ensuring the reliability, functionality, and safety of various critical systems.

Software architecture can be defined as the high-level structures of a software system, including the software elements, their relationships and properties, and the practices used to select, define, or design these structures. An overview of software architecture is used at the beginning of a project life cycle to demonstrate the logical and physical data flow of the critical system under development. Specifically, software architecture is subject to changes due to operational decisions made over the course of the project. From this perspective, a malleable combination of informal diagramming and formal modeling may allow for the correct levels of abstraction, strictness, and granularity for the supervisory system. Thus, a malleable model is presented in Section 2.1.

2.1. Malleable Model

According to Jongeling and Ciccozzi [11], malleable modeling is a flexible and bidirectional interface between the static and dynamic behaviors of a software system, regardless of the technology applied. Malleable models allow engineers to benefit both from the advantages of informal diagramming and from the benefits of formal modeling simultaneously while also supporting detail-level adjustment for specific uses.

In the malleable model, there is fluid movement along and across the two spectra shown in Figure 1: the horizontal spectrum, which transitions from informal to formal modeling, and the vertical spectrum, which shows the level of diagram abstraction, ranging from showing less detail to more detail.

As the information from the critical system to be supervised is processed between different subsystems and operators, defining an approach based on componentization helps design the automation software architecture prior to its implementation and deployment. To further explore this concept, the C4 diagram informal approach is described in Section 2.1.1.

2.1.1. C4 Diagram Informal Approach

By definition, a C4 diagram (context, container, components, and code) is built upon the traditional UML [12,13]-based diagramming process. This model is a simplified version of the UML to help software development teams describe and communicate software architecture, both during up-front design sessions and retrospectively when documenting an existing codebase [14].

A generic C4 diagram comprises four levels of architecture diagrams as follows:

• Level 1 (software system context diagram): the highest level, referring to definitions of the key elements of the system under consideration;
• Level 2 (container diagram): the intermediate level, with descriptions of function and relationships among subsystems;
• Level 3 (components diagram): the intermediate level, with abstractions of the components needed for each container;
• Level 4 (code diagram): the lowest level, referring to diagram code described in the previous levels using appropriate language close to that of the actual implementation.

In order to illustrate the link among these levels, a C4 diagram example is shown in Figure 2. In this diagram, the detail increases by level and creates an abstract concept in which the objective is to expand the detail as the level increases.

In Level 1, the software system under development is shown. In this level, the way the software system relates to the world in terms of the people who use it and other software systems with which it interacts is also considered. In Level 2, the main diagram is indicated. Depending on the project, this diagram can be the first one to be developed. It has the capacity of expanding and collapsing its contents to reveal its inner workings and components. In Level 3, an internal element of the container is disclosed after unpacking. This diagram should map container abstractions, showing the components that comprise the container without providing much detail about how they work. In Level 4, as the developer unscrambles the component diagram, the coding of elements inside the component diagram will be expressed [15].

Although Level 4 can be considered optional in a C4 diagram, the integration of dynamics modeling in automation software architecture can be made possible by the malleable model’s application. By modeling parts of the data from the informal diagrams, this information becomes accessible for the understanding of the automation system requirements and definition of new operational strategies. Therefore, the use of a formal approach is interesting for creating models in this circumstance. To do so, hierarchical colored Petri nets were chosen as the formal approach due to the features described in Section 2.1.2.

2.1.2. Basic Principles of Hierarchical Colored Petri Nets Formal Approach

Colored Petri nets (CPNs) are a formal method using graphical modeling language to specify concurrent systems, combining control structures described by Petri nets and data manipulation executed by a programming language [16,17]. A depiction illustrating the fundamental graphical components of CPNs along with their respective attributes is presented in Figure 3.

In this figure, a place is represented by a circle with an initial marking (INITIAL MARKING NAMED), a place data type (TYPE OF PLACE), and an identification (NAME); the arc constitutes an arrow and an expression (EXPRESSION), which evaluates to a multi-set (a multi-set is a variant on the idea of a set in which each of its elements can have more than one occurrence, in contrast to a set) or a single element. A transition is defined for a rectangle with a guard ([ ]), which is a Boolean expression that evaluates to a true or false value, a delay expression (@+) which must be a positive integer, and code segments (input()). The input pattern lists the variables that can be used in the code action (output()); the output pattern lists the variables to be changed as a result of the execution of the code action (action()); and the code action is executed as a local declaration in an environment containing the variables specified in the input pattern. When the code action has been executed, its result is applied to bind the variables in the output pattern.

CPNs are composed of two distinct types of nodes, places and transitions, which are interconnected by arcs. Given the restriction that arcs cannot establish direct connections between nodes of the same type, they are required to link place nodes to transition nodes and vice versa as network bipartites. The input places for a transition are all places with an arc directed from the place to the transition, whereas the output places for a transition are all places that have an arc directed from the transition to the place.

Any distribution of tokens (a CPN’s variable components are named tokens; they reflect the value of a condition and are shown inside a place) over these places will represent a configuration of the net called marking. The initial marking is determined by evaluating the initialization expressions. In an abstract sense relating to a CPN diagram, a CPN transition may fire if it is enabled, i.e., if there are sufficient tokens in all of its input places. When the transition fires, it consumes the required input tokens and creates tokens in its output places according to the arc expression. Firing is a single, uninterruptible step. CPNs change from one state to another when a transition “fires”. The assignment of labels to individual places involves a collection of elements from the set of colors associated with the place (if a color set is built up from other color sets, it is called compound (product color set, record color set, list color set, union color set, subset color set, and alias color set); if not, it is named simple (unit color set, Boolean color set, integer color set, large integer color set, real color set, time color set, string color set, enumerated color set, and index color set)). The utilization of multi-sets is essential to accommodate situations in which multiple tokens possess the same color (in a CPN, tokens have a data value associated with them. The data value associated with a token is known as the token color).

By formal definition [16,17], CPNs are given by a nine-tuple ($\Sigma$, P, T, A, N, C, G, E, I), which satisfies the following properties:

• $\Sigma$ is a finite set of non-empty color sets (types).
• P is the finite set of all places.
• T is the finite set of all transitions.
• A is the finite set of all arcs such that P ∩ T = P ∩ A = T ∩ A = ∅.
• N is the node function such that N: A → P × T ∪ T × P.
• C is the color function such that C: P→$\Sigma$.
• G is the guard expression function such that G: T→ Expr (Expr is the set of expressions provided by the CPN’s ML inscription language which specifies declarations and net inscriptions. This language is an extension of the functional programming language Standard ML) and ∀ t ∈T: [ Type(G(t)) (Type(e) is the type of an expression e∈ Expr, i.e., the type of Var(e) (the values obtained when evaluating e)) = Bool ∧ Type(Var(G(t))) ⊆$\Sigma$].
• E is the arc expression function such that E: A→ Expr and ∀ a ∈A: [ Type(E(a)) = C(p(a))_MS (the subscript MS denotes the multi-set of the associated place) ∧ Type(Var(E(a))) ⊆$\Sigma$], where p(a) is the place of N(a).
• I is the initialization function such that I: P→ Expr and ∀ p ∈P: [ Type(I(p)) = C(p)_MS].

In a CPN, a small circle is used to denote the current marking of a specific place, accompanied by an integer indicating the quantity of tokens present. Additionally, a text string is positioned alongside the circle, containing a multi-set that displays the various colors of individual tokens and their corresponding coefficients. The standard practice involves excluding the circle and text string for places devoid of tokens. Each token within a given place is required to exhibit colors belonging to a predetermined category, enabling differentiation between colored tokens. The color sets can be identified through declarations, which are articulated using CPNs’ ML, a specific language cited in the literature [18].

Enabling the incorporation of complex markings results in an increase in the complexity of movements within the PNs. To describe this more complex situation, more elaborate arc expressions are needed. It is no longer sufficient to have an integer specifying the number of tokens which are added/removed. Instead, arc expressions which specify a collection of tokens—each with a well-defined token color—are needed. In this context, the functionalities of a high-level programming language and the organization of modules are linked to PNs, resulting in the emergence of the hierarchical colored Petri nets (HCPNs).

HCPNs were created to facilitate the interconnection of multiple individual CPNs in a formal manner, thus enabling a well-defined semantic framework that allows for formal analysis. HCPNs support a method for defining sets of places so that anything that happens to each place in a set also happens to all the other places in the set. The places are then functionally identical. Such places are called fusion places, and a set of fusion places is a fusion set. Moreover, HCPNs use substitution transitions to implement the hierarchy. A substitution transition is a special kind of transition that itself does not fire; instead, it contains a subnet that defines the behavior that takes place instead. Each of the HCPNs has the capability of being transformed into a non-hierarchical CPN that is behaviorally equivalent, and conversely, the reverse transformation is also possible. The fundamental principles and analytical approaches applied in non-hierarchical networks can be extended to HCPNs as well [16,17].

In summary, a CPN module can be expressed as a four-tuple ${\Sigma }_M$ = ($\Sigma$, $T_{sub}$, $P_{port}$, $PT$), where

• $\Sigma$ = $(P,T,A,C,V,W,G,E,I)$ is a non-hierarchical CPN.
• $T_{sub}$⊆T is a set of substitution transitions.
• $P_{port}$⊆P is a set of port places.
• $PT$:$P_{port}$→$(IN,OUT,I/O)$ is a port type function that assigns a port type to each port place.

Meanwhile, HCPNs can be expressed as a four-tuple ${\Sigma }_H$ = $(S,SM,PS,FS)$ [19] in which

• S is a finite set of modules. Each module is a CPN module s = (($P^S$, $T^S$, $A^S$, $C^S$,$V^S$, $W^S$, $G^S$, $E^S$, $P^S$), $T_{sub}^S$, $P_{port}^S$, $P{T}^S$), and it is necessary that ($P^{S_1}$∪ $T^{S_1}$) ∩ ($P^{S_2}$∪ $T^{S_2}$) = ∅ for all $s_1$, $s_2$∈ S such that $s_1$≠$s_2$.
• $SM$: $T_{sub}$→S is a submodule function that assigns a submodule to each substitution transition. It is required that the module hierarchy is acyclic.
• $PS$ is a port-socket relation function that assigns a port-socket relation $PS\left(t\right)$⊆$P_{sock}\left(t\right)$×$P_{port}^{SM\left(t\right)}$ to each substitution transition t, and it is required that $ST\left(p\right)$ = $PT\left(p^{\prime }\right)$, $C\left(p\right)$ = $C\left(p^{\prime }\right)$, and $I\left(p\right)\langle$〉 = $I\left(p^{\prime }\right)\langle$〉 for all $(p,p^{\prime })$∈$PS\left(t\right)$ and all t∈$T_{sub}$.
• $FS$⊆$2^P$ is a set of non-empty fusion sets such that $C\left(p\right)$ = $C\left(p^{\prime }\right)$ and $I\left(p\right)\langle$〉 = $I\left(p^{\prime }\right)\langle$〉 for all $(p,p^{\prime })$∈$fs$ and all $fs$∈$FS$.

In the context of applying PNs in system engineering modeling, the presence of intricate business logic requirements can result in a significant expansion of the state space of a network system, making the process of simulation and performance enhancement exceptionally challenging. The utilization of an HCPN formalism, incorporating fusion place, port/socket place, and substitution transition (also referred to as aggregated transition), offers a structured approach to addressing this challenge by diminishing the state space’s complexity. Essentially, a comprehensive large-scale CPN model can be segmented into multiple subnets, facilitating a more manageable and thorough analysis.

When constructing an executable HCPN model, the generation of full state spaces is possible in accordance with the firing rules. These state spaces, portrayed as a directed graph, encompass all feasible executions of the model through nodes representing reachable markings and arcs indicating occurrence-binding elements. Consequently, within these comprehensive state spaces, one can not only identify all attainable states but also track all alterations in state. This comprehensive analysis enables the validation and assurance of critical system properties like liveness (the liveness property of PNs refers to the ability of the system to ensure that all transitions can eventually occur, preventing deadlock or livelock situations), boundedness (the boundedness property of PNs refers to the condition wherein the net has limitations on the number of tokens that can be present in each place, ensuring a finite state space), and fairness (fairness in PNs is a crucial property ensuring actions in the system model are starvation-free, that is, no component is delayed indefinitely in a composed model, promoting effective reuse and composability checking through PN transformations and analysis techniques).

From the C4 diagram concepts and the HCPN theory, it is possible to understand the methodological approach proposed for malleable model development in the context of critical systems supervision, as described in detail in Section 3.

3. Methodology

The proposed methodology in this work is presented by means of a schematic diagram illustrated in Figure 4. At the top part of this diagram, an ellipse identified as “SUPERVISORY SYSTEM” can be observed, which represents the “OPERATOR’S SKILLS” and the “HARDWARE TOPOLOGY” proposed in the literature, in order to address the reliability of critical systems under these perspectives. Additionally, the “SOFTWARE” perspective can be noticed as an intersection between these perspectives, and it is still an academic gap that requires contributions with efficient solutions focused on this topic.

In the middle part of this diagram, a zoom of the “SOFTWARE” ellipse can be seen. Usually, in the context of software development, there is a continuous and direct flow that starts from “SPECIFICATION”, goes through the “REQUIREMENTS” definition, and reaches the “PROJECT” development. The purpose of this work is to insert a block called “MALLEABLE MODEL” into this flow, represented by a dashed red ellipse.

At the bottom part of this diagram, a zoom of the “MALLEABLE MODEL” ellipse can be viewed. Inside this ellipse, there is a flowchart that represents the malleable model developed in this work. Initially (BEGIN), an “INFORMAL APPROACH” is used to describe the supervision system componentization, allowing for a static comprehension of the physical components and their connections in the software architecture. As a consequence, a “FORMAL APPROACH” is built to link the dynamic behavior modeling of the critical system with the respective component obtained in the software architecture. Then, validation and checking are accomplished in a formal way in order to guarantee that the requirements are strictly met. If there is a “FAULT” (NO) and an adjustment is needed, a return to a previous step is performed and the method goes after the following steps. Otherwise, if there is NO FAULT (YES), the supervision system project can be achieved (INFORMAL APPROACH) and the method is ended (END).

As a malleable model, it is also proposed in this work to flow by in a new spectrum, namely, the radial spectrum, i.e., from the informal diagram with minimal deployment documentation to strict modeling with extensive dynamic analysis and vice versa, according to Figure 5.

The detailed steps of building the malleable model in a radium spectrum are shown in Section 3.1. For the implementation of this model, the C4 diagram and HCPNs were chosen as the informal and formal approaches, respectively, due to the features described in Section 2.1.1 and Section 2.1.2.

3.1. Malleable Model Framework

The method framework is composed of three steps, as shown in Figure 6. Initially, the software system functional requirements are defined in an informal way (STEP 1) based on the C4 diagram, as well as the system context diagram, the container diagram, and the component diagram, which are built.

Consequently, in a formal way (STEP 2) based on HCPNS, the basic component elements to model are identified; the casual relations of each identified element are analyzed; each identified element is modeled; the complex models are composed from each identified element model; these complex models are integrated in a global model; and finally, the global model is analyzed.

After analyzing, if any fault occurs, a return to a previous step is necessary. Otherwise (STEP 3), the global model is inserted into the code diagram, and then the code diagram as an application programming interface (API) is deployed. The supervision system consistency must be guaranteed during the development, obtaining architectural diagrams and strict models in both forward and backward directions.

An understanding of how to run the malleable model, particularly STEPS 2 and 3 of the proposed framework, is possible from the coding techniques, which are explained in Section 3.1.1.

3.1.1. Coding Techniques

A block diagram of the system entity interfaces to be modeled using HCPNs is shown in Figure 7. In a general way, the proposed approach interacts with the critical system to be supervised as follows: “CRITICAL SYSTEM” data are acquired via the utilization of Boolean logical functions. In sequence, the “MALLEABLE MODEL” also provides supervision to the “SUPERVISORY SYSTEM”. In this particular scenario, fired transitions lead to the retrieval of data from a crucial system, with the purpose of assessing the necessity for decision making. The collection of data from the critical system is carried out on a one-by-one basis. Additionally, a transition occurs in HCPNs, which are converted into subnetworks, which are organized into networks in a methodical and expandable manner for the purpose of articulating and addressing the modeling issue in a formal way.

For example, the pre-condition of the operating state of a device in the critical system can be modeled by a place in the HCPN. A token positioned in a specific place signifies the current status of the pre-condition. This token is determined by the events linked to the pre-condition, serving as a Boolean logical function that becomes active upon the occurrence of any related event. Consequently, a Boolean logical function represents a tool tied to the required pre-condition for guiding decisions on the device, as delineated in Equation (1).

$$y_n=x_{n1}+x_{n2}+\cdots +x_{nm}$$

(1)

where y is the pre-condition variable; x is the event associated with the pre-condition; n is an integer number associated with the needed respective pre-condition; and m is an integer number of the events to which it is linked and that are associated with the corresponding pre-condition.

The activation of the Boolean logical function indicates the existence of a token at the corresponding place specified by this pre-condition. Certain occurrences linked to the “status” of the representation hold significance. These occurrences play a crucial role not only in supplementation but also in ensuring the reliability and safety of the representation.

On the other hand, the Boolean logical function for the transitions is according to Equation (2).

$$z_r=y_1+y_2+\cdots +y_s$$

(2)

where z is the transition variable; y is the pre-condition variable; r is an integer number associated with the respective transition, which acquires information from the critical system; and s is an integer number connected with the corresponding pre-conditions to which they relate.

If any pre-condition remains unsatisfied, it is imperative that an automatic block alarm be triggered, as every pre-condition is essential for initiating the proposed approach in the HCPN. Once all pre-conditions have been met, the proposed approach can commence. As a result, the specified pre-conditions are deemed necessary: (i) starting the proposed approach; (ii) analyzing the device operating status in the critical system; (iii) not blocking the proposed approach; (iv) preparing the proposed approach; (v) blocking the proposed approach; and (vi) verifying the impeding of the proposed approach.

At this point, we have an understanding of how analyzing the coded malleable model is indispensable, based on validation and checking phases reported in Section 3.1.2.

3.1.2. Performance Analysis

Validation and checking with HCPNs are crucial for ensuring the functional correctness, effectiveness, and reliability of critical systems. Validation is the essential procedure of confirming that a software system or component satisfies the specified criteria and operates effectively within its designated environment. The primary goal of this validation stage is to identify and correct any errors in the software to guarantee its compliance with the user requirements and its proper functioning. Checking refers to the procedure of verifying software artifacts against desired properties using formal checking techniques. The employment of strict methodologies, including formal methods, is underscored in the field of software engineering with the aim of preserving the initial engineered elements of a product and averting designs from straying away from their designated objectives, underscoring the significance of comprehensive verification processes in software development. CPNs offer a formal modeling approach that allows for the construction, validation, and checking of system behaviors. In turn, the hierarchical structure of CPNs enables a detailed representation of system components and interactions, facilitating thorough analysis and validation processes. This formal modeling approach not only aids in detecting errors and inconsistencies but also enhances the overall quality and reliability of systems, making it an essential tool for system designers and developers.

In critical systems, it is imperative that the system model be devoid of deadlocks; if they are not desired, there must exist a minimum of one state for every transition for every state that can be reached. The absence of deadlocks in critical systems is crucial for maintaining continuous operation, ensuring efficient resource utilization, upholding system predictability and reliability, facilitating timely diagnosis and resolution of issues, and meeting regulatory compliance. Deadlocks represent a fundamental risk to the operational integrity of critical systems, underscoring the necessity of robust design, testing, and mitigation strategies to prevent their occurrence. Consequently, when conducting behavioral checking of a CPN model, the following properties should be considered:

• Reachability→ This refers to the concept of a specific marking M being classified as reachable in a system, whereby there is a sequence of firing transitions that enables the system to move from the initial marking $M_0$ to the desired marking M. This concept can be formally expressed as M, belonging to the set of reachable markings R(N, $M_0$).
• Deadlocks→ They occur in a CPN model when a marking M is considered dead due to the absence of any enabled transition. A CPN model is deemed deadlock-free when every reachable marking within it enables at least one transition.
• Dead transitions→ A transition becomes categorized as inactive when it lacks a reachable marking where the transition can be executed.
• Liveness→ This property pertains to a transition t being classified as live when, given any marking M∈ R($M_0$), there is a series of transitions enabled from M including t, to be precise, for all M∈ R(N, $M_0$) where there exists M∈ R(N, M): $t^{\prime }$≤$M^{\prime }$. The concept of liveness serves to guarantee that the CPN model will never experience blocking.
• Boundedness→ A specific location P is deemed k-bounded for a given natural number k if, for every reachable marking, place P does not exceed k tokens at any point, formally expressed as ∀M∈ R(N, $M_0$): $M\left(P\right)$≤k. The concept of boundedness plays a crucial role in guaranteeing that the quantity of workpieces in progress remains within a certain limit, consequently contributing to the overall stability of the CPN model.
• Dead markings→ The information pertaining to dead markings provides insight into markings that lack enabled transitions.

In this work, the HCPN analysis is performed using CPNs Tools (more information about CPNs Tools can be obtained in https://cpntools.org/ (accessed on 14 August 2024)), which constitutes a suite of tools utilized for the purposes of modeling, editing, simulating, and analyzing state space. By employing the CPNs Tools suite, individuals are able to produce a state space corresponding to a specified PN model through the computation of reachable states (markings). This capability makes it possible to address a wide array of checking inquiries pertaining to the behavior of the system, such as deadlocks, liveness, and fairness. Moreover, the state space can be visually depicted by means of a directed graph known as a state space graph, in which states are denoted by nodes and events are represented by arcs. From the practice of state space analysis, it becomes feasible to check the coverage of all feasible executions.

In order to exemplify the implementation of a malleable model in the context of a real critical system, the proposed methodology is applied for a power system, as shown in Section 4.

4. Case Study

In power engineering, the development of methodological tools faces challenges in uncertain environments, focusing on new design options for electric power systems. Moreover, a supervisory system in the energy domain utilizes data acquisition for real-time decisions, highlighting the critical role of energy supervision in reliable operations.

In this sense, an HPP is considered as a case study in this work, emphasizing the importance of developing innovative modeling methods for integrated energy systems.

4.1. Eletrobras Chesf Hybrid Power Plant

One of the innovation projects being developed in the Brazilian Northeast region related to HPP is the insertion of a photovoltaic system (PV) and a battery energy storage system (BESS) for the hybridization of one wind farm (WF) at Casa Nova, Bahia, as part of the Research Project Program managed by Eletrobras San Francisco Hydroelectric Company (Eletrobras Chesf), a Brazilian hydroelectric company that generates and transmits electrical energy. This project (this work was ideated in the Research, Development and Innovation (R&D+I) Project with code number PD-00048-0217, being regulated by the National Electric Energy Agency (ANEEL)) is being coordinated by the Integrated Manufacturing and Technology Center (SENAI CIMATEC). The Eletrobras Chesf PV-WF-BESS HPP under construction, as shown in Figure 8, will contain three RESs: 1.5 MW from a wind turbine generator, 1 MW from photovoltaic strings, and 1 MWh from a BESS. They will supply loads connected to an AC busbar.

The proposed automation system for this HPP follows a hierarchical architecture, as presented in Figure 9. From the local controllers connected to each asset through electrical wires, the acquired data are transferred for the remote terminal unit (RTU) with a modbus protocol. As a consequence, these control devices communicate with the supervisory control and data acquisition (SCADA) system through the ISOTCP/IP protocol, which shares data with the plant information management system (PIMS) using the Open Platform Communications Unified Architecture (OPC UA) standard (OPC UA is a cross-platform, open source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation). Then, the PIMS shares data with intelligence software through the TCP/IP protocol.

Thus, five layers are established in this architecture for information exchange among their elements:

• Layer 1 (local controllers): HPP assets have local controllers that are responsible for managing the generator unit subsystems in which they are inserted as well as receiving set points from external systems to adjust power generation. This layer also includes the protection relays, which are responsible for ensuring some safety conditions during system operation, acting when short circuits occur.
• Layer 2 (RTU): Each of the local controllers communicates with the RTU, which is responsible for managing asset operation and controlling and supervising the HPP. The RTU is also responsible for receiving orders from Layer 3 and communicating with Layer 1.
• Layer 3 (SCADA system): This has an interface with HPP assets, displaying values of electrical measurements and their operating states. In this layer, acquired data from meteorological stations are available, manual commands are made by the operator, and information from Layer 4 reaches Layer 2 and vice versa.
• Layer 4 (PIMS): This is the system that acquires process data from several sources, stores them in a historical database, and makes them available by means of several representation forms.
• Layer 5 (intelligence software): This is an artificial intelligence (AI)-based algorithm that relies on weather forecasts received from Layer 3 and shared with other layers, as well as time-varying energy pricing (PLD—its acronym in Portuguese), which are used to contribute to decision making regarding energy dispatch. This dispatch is made through performed maneuvers on the plant, such as energy supply made available only by BESS discharge when there is low wind or sun incidence in the region.

The simultaneous operation of these RESs is very challenging and complex. In this context, it is essential to manage and control numerous components that interact with each other or with the environment, having properties that arise from these interactions such as non-linearity and spontaneous order, with no integration error. Because an HPP is a critical system that eventually has to face severe climate conditions and guarantee energy supply in order to avoid social and economic consequences, a supervision system considering these aspects is fundamental to integrate, without error, the HPP by means of structured, scalable, and graphical representations, making it possible to make decisions in a timely manner. Therefore, in Section 4.2, the malleable model development to support HPP supervision systems is addressed.

4.2. Malleable Model Development

In this section, the three steps shown in the proposed methodology in Section 3 are considered in order to build the malleable model of the Eletrobras Chesf PV-WF-BESS HPP supervision system. Because Eletrobras Chesf PV-WF-BESS HPP is a real critical system with automation layers like all kinds of real critical systems, which all have similar automation layers, it can be considered as a universal test case. In this work, the usage of the malleable model is in the electrical designing field.

According to the descriptions in Section 3.1.1, this malleable model is developed by initially considering an intelligent electronic device (IED) status evaluation of the PV plant into the Eletrobras Chesf PV-WF-BESS HPP. First, in Section 4.2.1, step 1 is introduced.

4.2.1. STEP 1 (INFORMAL): Obtaining Part of C4 Diagram

Initially, a set of functional requirements (FRs) referring to Layer 3 (SCADA system) is defined and connected to the HPP case study as follows:

• FR1 (operational vision structure): The SCADA system in its operational view must follow the pattern of three frames with defined dimensions, dividing the screen horizontally. These frames will be named “menu frame”, “main frame”, and “alarm frame”.
• FR2 (overview screen renewable generation system): The SCADA system must have a screen for monitoring the main electrical measurements of the IEDs for each HPP asset.
• FR3 (renewable generation system command screen): The SCADA system must have a screen that allows the operator to issue IED remote controls (for example, open/close, increase/decrease) initiated by operators.
• FR4 (renewable generation system monitoring screen): The system must have a screen for monitoring the main electrical quantities and states from IEDs.
• FR5 (alarm and event processing): The SCADA system must be provided with resources and logic functions to perform the classification, filtering, routing, annunciation, formatting, and archiving of alarm messages and events in general, which occur in the electrical system or in the control system itself.

In sequence, the C4 diagram of the supervision system is developed with relative details to the internal and external components of this system, as described in Section 2.1.1. In Level 1 of this supervision system, the SCADA system represents the software system for the context C4 diagram, as shown in Figure 10.

In this level, the Operator block refers to the user accessing the SCADA system by means of commands to the asset elements and/or by visualization of the state of these arranged elements in the supervisory system screens. Moreover, the operator can be classified into several types, such as Engineering, Foreman, or Maintenance. As observed in this diagram, the SCADA system is connected directly with three other external systems, as follows:

• Remote database: This contains the information history collected by the SCADA system to access the PIMS and smart dispatches. It also contains information about the WF, PV, BESS, weather forecast, proposed local control set point, and load dispatch schedule made by the Operator.
• Weather seasons: They are located in the HPP and connected to the SCADA system, sending information about weather conditions.
• Industrial switch: This refers to the system or equipment that acts as an interface for the communication network between the RTU and SCADA system, providing great capacity in data traffic and robustness to environments with extreme temperature variations. After capturing the information about the asset states, the switch sends it to the SCADA system, which processes data.

Regarding the C4 diagram, in Level 2, the SCADA system has four internal containers that communicate with three external systems, as illustrated in Figure 11.

These containers are structured as follows:

• Access control: This container is responsible for verifying the hierarchy level and allowing user access to the supervisory system. It consists of the login screen, which verifies the user’s hierarchy through an algorithm and allows the user to access operation and monitoring screens.
• History screens: This is the container of the set of screens and algorithms containing the screens of the system elements’ state history and the function for generating reports. This system has integration with the local SCADA system database, where such histories are stored.
• Local database: This is the database container, containing the history of the WF elements, PV, weather stations, BESS, and alarms. This information is collected from the operator’s actions on the SCADA system through queries to the remote database and RTU information.
• Supervision and control screens: This is the container of the set of screens, objects, and algorithms, which allows for the supervision and control of the elements contained in the SCADA system.

In Level 3, the container Supervision and control screens is composed of five internal components, Alarm manager, HPP asset elements, Substation elements, Weather data elements, and Communication driver, as illustrated in Figure 12.

In this context, after introducing step 1 of the methodology, an understanding of step 2 is needed and discussed in Section 4.2.2.

4.2.2. STEP 2 (FORMAL): Building HCPN Model

In order to formulate and solve the integration error problem in the supervision system, part of the code C4 diagram in the Alarm manager component in Level 4 is built in a formal way using HCPNs.

A general unifilar diagram of the Eletrobras Chesf PV-WF-BESS HPP is shown in Figure 13. At the output of each RES, there is a power transformer (630 V/34.5 kV), a power meter (PM), and a circuit breaker with protection relay (PR). Among the typical supervisions considered regarding PR, there is the breaker opening. In this work, in HCPNs, a representative supervision, i.e., a breaker opening, is transformed into subnets for didactic reasons and in order to exemplify the process. This supervision is considered in this work for modeling part of the code C4 diagram of the HPP PV section in HCPNs.

For this supervision, if breaker 2 in the HPP PV section is opened, the PR associated with breaker 2 identifies this status, and a mandatory alarm associated with the breaker 2 opening is generated.

Components and Causal Relationships

In this supervision, there are three basic elements, which were identified as necessary for the model, i.e., (1) Initiating, (2) Evaluating, and (3) Impeding. Causal relations between these elements of the breaker opening supervision are direct, and the presentation is structured in the following manner: Item 1 pertains to the modeling of Initiating; Item 2 pertains to the modeling of Evaluating; and Item 3 pertains to the modeling of Impeding.

In Figure 14, the connection among these elements is presented, with the arrows that state the relations between the parts of the model during execution. Each one of these elements represents a page of the modeled HCPNs.

Initially, measurements and alarms that generate information about the PV IED status were considered. Then, the required pre-conditions to identify PV IED status in operation were selected: ready, communication fail, and energized.

To illustrate the Boolean logical function, the pre-condition “Analysis” is taken as reference. The selection of this pre-condition as a reference point stems from its simplicity and representativeness. Furthermore, it is didactically compelling due to the presence of three events linked to this specific pre-condition. Consequently, it avoids being an insignificant illustration with just one event tied to the pre-condition. Thus, the pre-condition “Analysis” resulted in the following events:

• IED in operation: Event “PV PR in Ready”.
• IED communication fail: Event “PV PR Communication Fail”.
• IED energized: Event “PV PR Energized”.

The event “PV PR in Ready” is alarmed because it is on logical level 0; “PV PR Communication Fail” is alarmed because it is on logical level 0; and “PV PR Energized” is alarmed because it is on logical level 0. The pre-condition’s Boolean logical function “Analysis”, $y_2$, is given by Equation (3).

$$y_2=\overline{x_{21}}+\overline{x_{22}}+\overline{x_{23}}$$

(3)

where $x_{21}$ is the variable associated with the event “PV PR in Ready”; $x_{22}$ is the variable associated with the event “PV PR Communication Fail”; and $x_{23}$ is the variable associated with the event “PV PR Energized”.

If the events “PV PR in Ready”, “PV PR Communication Fail”, or “PV PR Energized” are alarmed, the Boolean logical function $y_2$ will be set to logical level 1, indicating the presence of a true token at the corresponding place in relation to this pre-condition, signifying the existence of a fault. In the absence of any alarms, the Boolean logical function $y_2$ will transition to logical level 0, denoting the presence of a false token at the associated place, suggesting the absence of a fault. A similar analysis can be conducted for the other pre-conditions to examine the behavior of the relevant Boolean logical functions linked to these pre-conditions.

Global Model

The global model of the breaker opening supervision for 1 (one) breaker is composed of three pages: Initiating, Evaluating, and Impeding. Firstly, PV plant IED status modeling is needed. To do so, a page—Initiating—is built using CPNs Tools, as shown in Figure 15. This page is associated with the PV IED status, which characterizes the PV IED as ready and energized, with no communication failure, in order to perform the breaker opening supervision.

Secondly, breaker opening supervision evaluation modeling is required. Then, a page—Evaluating—is made using CPNs Tools, as illustrated in Figure 16. Finally, breaker opening supervision impeding evaluation modeling is essential. Then, a page—Impeding—is created using CPNs Tools, as illustrated in Figure 17.

In Figure 15, Figure 16 and Figure 17, places are linked to the necessary prerequisites for initiating breaker opening supervision and the “status” of the model; transitions denote data acquisitions from HPP, determinations to set tokens, and alerts. The presence of a token in a place signifies the fulfillment of the corresponding condition. Furthermore, the values (val), colors (Colset), and variables (var) used to describe the required information in the places, transitions, and arcs are summarized in

Table 1. Value, color, and variable specifications in Figure 15, Figure 16 and Figure 17.

Declarations for 1 Breaker Opening Supervision
Name	Type	Definition	Meaning
iedboot	val	20	Estimated time in seconds to the IED boot
tmr	val	1	Timer value in seconds
n	val	2	Value used to define breaker 2
IB	Colset	int with 1..iedboot	Integer data from 1 to iedboot
A	Colset	with a	Logical data
BOOL	Colset	bool	Boolean data
BR	Colset	index br with 2..n	Data to define breakers
BRxBOOL	Colset	product BR*BOOL 1	Product data BRxBOOL
BRxBOOLxBOOL	Colset	product BR*BOOL*BOOL	Product data BRxBOOLxBOOL
INT	Colset	int	Integer data
TIMER	Colset	int with 1..tmr	Integer data from 1 to tmr
c, g, h	var	BOOL	Boolean variables
ib	var	IB	IB variable
t	var	TIMER	TIMER variable
b	var	BR	BR variable

¹ * is a special symbol used to produce product color set.

.

The meaning of the places and transitions in Figure 15, Figure 16, and Figure 17 are detailed in

Table 2. Meaning of places and transitions in Figure 15.

Page Initiating for 1 Breaker Opening Supervision
Element	Type	Meaning
Start	Place	A token a in this place indicates the 1 breaker opening supervision needs to be started.
Analysis	Place	According to the information that “authorizes” starting 1 breaker opening supervision, there is a token $\left(br\right(2),false)$ in this place if the supervision must be started or a token $\left(br\right(2),true)$ if the supervision must not be started.
NoBlock	Place	A token a in this place means there is no block pre-condition to the 1 breaker opening supervision.
Ready	Place	A token $\left(br\right(2),false)$ in this place means the 1 breaker opening supervision is ready to start.
Block	Place	A token a in this place means the 1 breaker opening supervision is blocked and supervision cannot be achieved due to reliability criteria of the proposed code approach.
Checking	Place	A token a in this place means some posterior checking needs to be conducted from this point.
Turn on	Transition	A token a in place Start enables this transition. When this transition fires, after a timer $ib$, if the 1 breaker opening supervision must be started, the value $\left(br\right(2),false)$ is returned from the HPP. Otherwise, information $\left(br\right(2),true)$ is returned from the HPP. The Boolean logical function associated with this transition, $z_2$, is described by $z_2=y_2$, where $y_2$ is the Boolean logical function associated with the pre-condition “Analysis” of the PV IED status.
Acquire	Transition	This transition evaluates the obtained information about the “authorization” to start the 1 breaker opening supervision. This information is needed to start the execution in a reliable way. The location Analysis enables this transition. If the supervision must be started, a token $\left(br\right(2),false)$ is in the location Analysis. In this condition, when this transition fires, a token $\left(br\right(2),false)$ is added to the location Ready. Moreover, a token a is added to the location NoBlock and a token a is added to the location Checking, indicating that there is no block pre-condition to the supervision and some posterior checking needs to be conducted from this point. On the other hand, if the supervision must not be started, a token $\left(br\right(2),true)$ is in the location Analysis. In this condition, when this transition fires, a token a is added to the location Block, indicating a block of the supervision, and supervision cannot be achieved due to the reliability criteria of the proposed code approach.

,

Table 3. Meaning of places and transitions in Figure 16.

Page Evaluating for 1 Breaker Opening Supervision
Element	Type	Meaning
Ready	Place	See Table 2.
Evaluation	Place	This transition evaluates 1 breaker status. When the transition Get fires, there is a token $\left(br\right(2),false,false)$ in this location if the breaker is opened or a token $\left(br\right(2),false,true)$ if the breaker is not opened.
NoBlock	Place	See Table 2.
Opened	Place	After transition InfOpen to fire, there is a token $\left(br\right(2),false,false)$ in this location if the breaker is opened.
Get	Transition	A token $\left(br\right(2),false)$ in the location Ready enables this transition, indicating the 1 breaker opening supervision is ready to start. When this transition fires, if the breaker is opened, the value $\left(br\right(2),false,false)$ is returned from the HPP. Otherwise, the value $\left(br\right(2),false,true)$ is returned from the HPP. The Boolean logical function associated with this transition, $z_3$, is described by $z_3=y_3$, where $y_3$ is the Boolean logical function associated with the pre-condition breaker status.
InfNOpen	Transition	A token $\left(br\right(2),false,true)$ in the location Evaluation enables this transition. When this transition fires, a token $\left(br\right(2),false,true)$ is removed from the location Evaluation, and a token $\left(br\right(2),false)$ is added to the location Ready.
InfOpen	Transition	A token $\left(br\right(2),false,false)$ in the location Evaluation enables this transition. When this transition fires, a token $\left(br\right(2),false,false)$ is removed from the location Evaluation, and a token $\left(br\right(2),false,false)$ is added to the location Opened.
Next	Transition	A token $\left(br\right(2),false,false)$ in the location Opened enables this transition. When this transition fires, a token $\left(br\right(2),false,false)$ is removed from the location Opened, a token $\left(br\right(2),false)$ is added to the location Ready, and a breaker opening supervision alarm is generated.

, and

Table 4. Meaning of places and transitions in Figure 17.

Page Impeding for 1 Breaker
Element	Type	Meaning
Checking	Place	See Table 2.
NoBlock	Place	See Table 2.
Block	Place	See Table 2.
ImpCheck	Transition	This transition evaluates whether there is a condition that impedes 1 breaker opening supervision. A token a in the location Checking and a token a in the location NoBlock enable this transition. When this transition fires, after a timer t, if there is a condition that impedes 1 breaker opening supervision, the value $true$ is returned from the HPP. Then, a token a is removed from place Checking, a token a is removed from NoBlock, and a token a is added to the place Block, indicating a block of the 1 breaker opening supervision. On the other hand, if there is no condition that impedes 1 breaker opening supervision, the value $false$ is returned from the HPP. Thus, a token a is removed from the location Checking, and a token a is added to the location Checking, enabling transition ImpCheck. The Boolean logical function associated with this transition, $z_4$, is described by $z_4=y_4$, where $y_4$ is the Boolean logical function associated with the pre-condition breaker impeding.

, respectively. Note that in their initial conditions, the places NoBlock and Block do not have any tokens, indicating that the 1 breaker opening supervision no block and block conditions are not defined initially to these places, respectively.

The names of the places and transitions are different, with the goal of achieving a proper and efficient analysis, as the suggested code diagram technique in HCPNs requires formal analysis, such as state-space analysis. With these pages, the 1 breaker opening supervision global model in HCPNs is formulated.

Generalization

The malleable model that has been constructed through a specific framework enables the achievement of structured and scalable generalization using this approach. To do so, only a few adjustments to the descriptions are necessary, and the global model can be used for breakers 1, 3, and 4 in addition to breaker 2.

In

Table 5. Value and color specification adjustments for 4 breakers.

Declarations for 4 Breakers Opening Supervisions
Name	Type	Definition	Meaning
n	val	4	Value used to define breakers 1, 2, 3, and 4
BR	Colset	index br with 1..n	Data to define breakers

, the value (val) and color (Colset) specification adjustments for 4 (four) breakers opening supervisions are presented in a summarized way. These specifications serve the purpose of delineating part of the necessary information in the places, transitions, and arcs in Figure 15, Figure 16 and Figure 17, with the aim of making these models work for four breakers, as shown in Figure 13.

4.2.3. STEP 3 (INFORMAL): Inserting the Global Model and Deploying the Proposed Code Diagrams as an Application Programming Interface

In order to verify the 1 breaker opening supervision of the PV plant into the Eletrobras Chesf PV-WF-BESS HPP, the proposed code diagram considering the alarm manager case for the specified supervision was developed and turned into an application programming interface (API), whose behavior is presented in Figure 18.

In this fluxogram, the three cases about the 1 breaker opening supervision are illustrated: (i) if Case 1 (OPENED) occurs, 1 is executed; (ii) if Case 2 (NOT OPENED) occurs, 2 is executed; and (iii) if Case 3 (FAULT) occurs, 3 is executed. These cases are described as follows:

• Case 1 (OPENED): There is no fault and Energized IED (“Data.IEDEnergized”) equals 1; IED Communication (“Data.IEDCommunication”) equals 1; Ready IED (“Data.IEDReady”) equals 1; and 1 breaker opening supervision (“Data.BR2.Status”) equals 0.
• Case 2 (NOT OPENED): There is no fault and Energized IED (“Data.IEDEnergized”) equals 1; IED Communication (“Data.IEDCommunication”) equals 1; Ready IED (“Data.IEDReady”) equals 1; and 1 breaker opening supervision (“Data.BR2.Status”) equals 1.
• Case 3 (FAULT): There is at least a fault; that is, the other possible conditions beyond these ones presented to Cases 1 (OPENED) and 2 (NOT OPENED), whose whole pre-conditions to accomplish 1 breaker opening supervision with functional correctness are not met.

In

Table 6. Pre-conditions, variables, and values of Case 1 (OPENED).

Conditions of Case 1 (OPENED)
Pre-Conditions	Variables	Values
Energized IED	Data.IEDEnergized	1
IED Communication	Data.IEDCommunication	1
Ready IED	Data.IEDReady	1
Breaker 2	Data.BR2.Status	0

,

Table 7. Pre-conditions, variables, and values of Case 2 (NOT OPENED).

Conditions of Case 2 (NOT OPENED)
Pre-Conditions	Variables	Values
Energized IED	Data.IEDEnergized	1
IED Communication	Data.IEDCommunication	1
Ready IED	Data.IEDReady	1
Breaker 2	Data.BR2.Status	1

and

Table 8. Pre-conditions, variables, and values of Case 3 (FAULT).

Conditions of Case 3 (FAULT)
Pre-Conditions	Variables	Values
Energized IED	Data.IEDEnergized	0	0	0	0	1	1	1
IED Communication	Data.IEDCommunication	0	0	1	1	0	0	1
Ready IED	Data.IEDReady	0	1	0	1	0	1	0
Breaker 2	Data.BR2.Status	X 1	X	X	X	X	X	X

¹ In Boolean logic, a “do not care" term (X) for a function is an input bit for which the function output does not matter.

, the conditions with pre-conditions, variables, and values of Cases 1 (OPENED), 2 (NOT OPENED), and 3 (FAULT) can be observed, where the case executions are distinct. Thus, these test cases contribute to the proof of the functional correctness and reliability of the proposed alarm manager approach.

After the malleable model development for the Eletrobras Chesf HPP, the validation and checking of this model are explained in Section 4.3, considering the whole modeling of the 1 breaker opening supervision related to reliability aspects.

4.3. Modeling Results

In Section 4.3.1, an example and a counterexample (a counterexample is an example that presents an argument in opposition or contradiction to a particular concept or hypothesis) related to reliability with respective reports and a message sequence chart (MSC) are shown in order to validate the alarm manager component in the malleable model. In Section 4.3.2, formal checking of this component is accomplished with full state-space analysis [20] and ASK-CTL temporal logic [21] for important and necessary behaviors related to reliability.

4.3.1. Validation

A way of validating the built malleable model is using simulations of test cases, as described in Section 3.1.2. An MSC associated with simulations can be prepared automatically. Consider an example scenario for evaluating 1 breaker opening supervision:

• PV IED state turned on;
• Need to perform 1 breaker opening supervision with functional correctness.

In this context, there is a need to accomplish the 1 breaker opening supervision reliably. To do so, the alarm manager is started according to some necessary ordered steps, as follows:

• Start 1 breaker opening supervision;
• Analyze PV IED state information;
• Execute 1 breaker opening supervision reliably.

The MSC connected with this simulation is displayed in Figure 19. In this MSC, nodes on the upper side with related descriptions identify places of Initiating, Evaluating, and Impeding pages; arrows accompanied by corresponding descriptions symbolize executed transitions within the model; and comprehension should adhere to a top-down and left-to-right approach due to the temporal indications presented in this manner. This MSC shows part of the proposed approach dynamics.

The complete report of this proposed approach simulation is presented as follows:

 

Report generated: Sat May 11 21:08:23 2024

 

1 0 Turn_on @ (1:Initiating)

 

- b = br(2)

 

- c = false

 

2 0 Acquire @ (1:Initiating)

 

- c = false

 

- b = br(2)

 

3 0 Get @ (1:Evaluating)

 

- c = false

 

- b = br(2)

 

- h = false

 

4 0 InfOpen @ (1:Evaluating)

 

- h = false

 

- c = false

 

- b = br(2)

 

5 0 Next @ (1:Evaluating)

 

- h = false

 

- c = false

 

- b = br(2)

Note that steps 1 (supervision must be started), 2 (there is no block pre-condition, posterior checking needs to be conducted from this point and supervision is ready to be started), 3 (breaker is opened), 4 (evaluation of breaker opening supervision information), and 5 (breaker opening supervision alarm and supervision is ready to be restarted) associated with this simulation were completed successfully, as explained in Section 4.2.2. Through this report, an assessment can be made on the dynamics inherent to the proposed approach in connection to the specific test case. As a result, the efficacy of the proposed alarm manager approach can be ascertained within the context of this particular test case.

Additionally, consider a counterexample scenario for evaluating 1 breaker opening supervision. It is similar to the one considered in the previous simulation. The MSC connected with this simulation is displayed in Figure 20. In this MSC, nodes and arrows have the same meanings as those seen in Figure 19; reading must be achieved the same way as described before. This MSC also shows part of the proposed approach dynamics.

The complete report of this proposed approach simulation is presented as follows:

 

Report generated: Sat May 11 21:09:57 2024

 

1 0 Turn_on @ (1:Initiating)

 

- b = br(2)

 

- c = false

 

2 0 Acquire @ (1:Initiating)

 

- c = false

 

- b = br(2)

 

3 0 Get @ (1:Evaluating)

 

- c = false

 

- b = br(2)

 

- h = true

 

4 0 InfNOpen @ (1:Evaluating)

 

- h = true

 

- c = false

 

- b = br(2)

Note that steps 1 (supervision must be started), 2 (there is no block pre-condition, posterior checking needs to be conducted from this point and supervision is ready to be started), 3 (breaker is opened), and 4 (evaluation of breaker opening supervision information) associated with this simulation were completed successfully, as explained in Section 4.2.2. As the breaker in this case is not opened (step 4 with Boolean variable h equals true), 1 breaker opening supervision goes to step 3. With this report, part of the dynamics of the proposed code diagram approach can be validated in relation to this test case. This test case demonstrates the correct behavior of the alarm manager’s proposed approach.

If the supervision associated with the 1 breaker opening did not follow these whole steps for the example and counterexample, functional correctness and reliability could be compromised. Thus, misunderstandings could occur and wrong decisions could be made, causing severe damage to the power system, society, and the company. Usually, these steps are not necessarily considered as associated with the pre-conditions of supervision, although they should be. In this way, it is clear that with these simulations, it is possible to detect problems in design procedures to manage alarms.

4.3.2. Checking

In order to facilitate model checking comprehension, a full state space for the alarm manager component is presented in Figure 21. The page names of the Initiating, Evaluating, and Impeding model are Initiating, Evaluating, and Impeding, respectively. Each node symbolizes an attainable marking, with each arc denoting the presence of a binding element that transfers the system’s marking from one node to another. Within each node, numerical values are displayed on the inner and upper sides, signifying the specific value linked to that particular marking. The initial marking is defined as 1. Additionally, within each node, a pair of numbers separated by a colon is present on the inner and lower side: the number on the left signifies the quantity of predecessor nodes, while the number on the right indicates the quantity of successor nodes.

In this full state space, marking 3 is reached from marking 1 when transition Turn on fires with binding elements b = br(2) and c = false, indicating that no fault occurred with the PV IED state associated with breaker 2 opening supervision. Then, marking 5 is reached from marking 3 when transition Acquire fires with binding elements b = br(2) and c = false, indicating that 1 breaker opening supervision must be started. Moreover, marking 8 is reached from marking 5 when transition Get fires with binding elements b = br(2), c = false and h = false, indicating that breaker 2 status is opened. Then, marking 11 is reached from marking 8 when transition Acquire fires with binding elements b = br(2), c = false, and h = false, indicating that a breaker 2 opening alarm needs to be generated.

In Appendix A, the full state space analysis report of the 1 breaker opening supervision model is presented. With this report, analyses of dynamic properties, already presented in Section 3.1.2, can be carried out, which are very efficient regarding the proposed model in this work.

In this report, note that some of the desirable characteristics to be modeled can be checked based on the analysis of dynamic properties of the proposed model. For example, two desirable characteristics to model are that there are no live and dead transitions, because these characteristics would indicate erroneous behaviors in the proposed model. Analysis of dynamic properties contributes to proving the functional correctness and the reliability of the proposed approach. Similar checks to the ones that were previously carried out for dead and live transitions can be carried out through the analysis of the dynamic properties of the proposed model.

To examine a particular behavior of the alarm manager’s proposed approach, the query codes in ASK-CTL are delineated along with their corresponding responses and brief elucidations pertaining to these codes, as outlined below.

 

Query 1:

 

Reachable (11,5)

 

Answer 1:

 

val it = true: bool

 

Query 1 and its corresponding response indicate marking 5 can be reached from marking 11.

Marking 5 is correctly reached from marking 11 when the transition Next fires with binding elements b = br(2), c = false, and h = false, indicating that a breaker 2 opening alarm generation is needed, according to the previous descriptions.

 

Query 2:

 

AllReachable ()

 

Answer 2:

 

val it = false: bool

 

Query 2 and its corresponding response indicate not all markings are reachable one from the other.

Answer 2 is correct because marking 2 cannot be reached from marking 3 according to the previous descriptions.

Queries within the CPNs’ ML functional programming language play a crucial role in substantiating the functional correctness and subsequent reliability of the proposed approach for the alarm manager. The utilization of CPNs’ ML language for similar analytics could also be extended to explore alternative behaviors within the proposed alarm manager approach, particularly in cases wherein a more comprehensive understanding of the dynamic modeling properties is deemed necessary.

After analyzing the results of this work, some discussion points are highlighted in Section 5.

5. Discussion

At present, conventional methods for reliability modeling in energy systems involve a subjective component due to them being predominantly executed manually by reliability engineers. The proficiency and expertise of these engineers significantly influence the system’s functional correctness. Additionally, the hardware topology impacts the system’s reliability rate and complicates its adaptability. With the increasing integration and complexity of contemporary energy systems, reliability engineers face growing difficulties in comprehending system behaviors, leading to a higher likelihood of errors in results acquisition and a consequent reduction in the accuracy of reliability assessments.

In this scenario, there is a clear gap in the literature between operators’ skills and hardware topology in terms of reliability, which demands an academic contribution. In this sense, the proposed malleable model design approach in this work provides a formulation and solution to the integration error problem in critical systems supervision with bidirectional connection between static and dynamic behaviors. This tendency to build flexible models for power system automation has been widely sought after in the last decade [22,23,24,25]. Despite the possibility of developing a quantitative approach to evaluate the malleable model, the focus of this work is on the qualitative approach, namely, designing a new critical system or reformulating an in-operation one.

Considering the Eletrobras Chesf PV-WF-BESS HPP as real-unit test case makes the proposed methodology achievable for practical applications. If appropriate adjustments (replacing the PV or WF or BESS by another critical system) are made, then the malleable model can be used, for instance, for other kinds of energy generation sources, such as energy generation from a hydroelectric power plant. Furthermore, as the developed malleable model was built according to a methodology, the structured and scalable generalization can be accomplished not only in other contexts in power systems beyond supervision but also in other contexts beyond power systems, such as aircraft systems and the aerospace sector.

Although PNs have still been used in the context of HPP automation system software architecture, modeling critical systems using PNs shows great potential due to the ability to capture the intricate behavior of such systems through formal methods [26]. Consequently, leveraging the algorithms and properties of this system enables a formal analysis. Developed mathematical representations are powerful checking and validation tools because they are strict. HCPNs guarantee functional correctness by their construction, and some required properties are reached from this formal approach. In this way, the malleable model design approach contributes to reliability in the supervision of critical systems and begins a current trend in the academy [27,28].

On the other hand, along with the numerous advantages, a significant drawback of CPN analysis can be identified, namely, the issue of state-space explosion [29,30], which leads to a notable increase in the computational complexity of the analysis. In order to mitigate this challenge, it is imperative to perform the following actions:

• Construct and examine occurrence graphs through the utilization of computational tools and also use techniques to reduce occurrence graphs while preserving a significant amount of information;
• Employ a hierarchical approach to enhance system management efficiency and avoid unnecessary states.

By using these techniques to reduce occurrence graphs, a reduced graph can be obtained that contains exactly the same information as the complete occurrence graph. These reduced graphs can be used to investigate all systemic properties that can be investigated through complete occurrence graphs. These reduced graph investigations are much more efficient. In this work, multi-set bounds are used to reduce the state space graph by bounding the number of tokens in certain places. By restricting the potential sizes of multi-sets in specific places, the combinatorial explosion of states can be reduced in the CPN model. This is especially beneficial in scenarios wherein there exist places with large or unbounded token populations that may result in a considerable state space. More information about these occurrence graph reduction methods can be obtained in [16,17].

Applying hierarchical modeling in CPNs may also contribute to the effective management of and reduction in the state space in a complex system through segmentation into smaller and more manageable submodels. The hierarchical organization plays a pivotal role in controlling state-space explosion, thereby facilitating the analysis and checking of the system.

6. Conclusions

The malleable model approach in this work provides an important contribution to the reliability of critical systems based on software architecture. The presented solution has the advantages of not depending on expert knowledge and hardware topology, with the possibility of easy adaptation due to it being structured and systematized in informal and formal approaches. In this way, the malleable model can facilitate the maintenance and/or analysis extension of critical systems, because the development of these systems’ supervision involves maintaining operation and fault tolerance.

The proposed framework to formulate and solve the integration error problem of the critical systems provides evidence that the method is applicable in power plant supervision. An HPP real-unit test case was considered with all of the automation layers in order to exemplify this framework. As the approach was developed in this work, particularly for an HPP, it can be utilized by electrical businesses. It can signify relevant operational and financial advantages in the long term due to the frequent occurrence of large-scale emergency situations and the high cost of errors in business plans.

For the informal approach, the C4 diagram was used to obtain the software documentation, while a logical modeling with HCPNs was used to describe the formal approach. HCPNs can be used to illustrate the dynamic behavior of an HPP supervision system in a succinct, thorough, systematic, and realistic manner. Analysis with validation—simulation and MSC—and checking—full state space and ASK-CTL temporal logic—in HCPNs was important because this proved the value of the functional correctness of the proposed framework in the energy domain. This study can also identify several issues in malleable modeling design.

As future work, the benefits of the generic methodology presented can be developed using other informal and formal approaches, as well as for systems other than HPP supervision. Furthermore, the development of the malleable model will also be carried out regarding the safety aspects of the critical system, providing robustness to the reliability analysis.