*3.3. Verification of Requirements Based on Petri Nets*

Verification is crucial to the proposed method for designing a power electronic mesh of sustainable resources integrated into a conventional electrical distribution system. The basic assumption is that requirement specifications must be formalized, analyzed, and verified before searching for an effective solution.

As with any automated system, integrated electronic power plants have to guarantee the proper convergence of objectives towards the satisfaction of user needs (as services) while also avoiding undesirable states and obstacles. This could be obtained from the modeling and verification of requirements, which would lead to the design of solutions that could also be verified using the same formalism, increasing traceability in the whole design process.

Verification could be done by generating the state space or by analyzing workflows (of control and items) using property analysis in Petri Nets, or both. Temporal and hierarchical extensions are also welcome.

#### **4. A New Requirement Cycle for Microgrid Systems Design**

We propose for a requirements cycle to be inserted in a design approach for microgrids that have the following characteristics:


In this work, we will focus on the early phase. MBSE will be the overall approach to propose a requirements cycle that can specifically sustain electrical systems based on the interaction of different subsystems, namely a systems of systems (SoS). Subsystems could also be microgrids, generators, or primary power sources. Requirements are adapted to fit user profiles and preferences, and to anticipate emerging requirements and new demands raised after implementation.

We start by representing the existing system (the System As-Is) and using it as a reference to define new goals, expecting to convert it into the System To-Be. Suppose there is no system-as-is (in which case the challenge is to make a design from scratch). In that case, a model is derived from the requirements elicitation, capturing the intentions of stakeholders and final users.

The distributed system arrangement is treated as a service. Using GORE techniques will help to overcome the so-called *functional dilemma*: the balance between functional and non-functional requirements. The goal approach potentializes design reuse, flexibility, and maintenance while anticipating formalization accuracy.

Figure 9 shows the process, which starts by collecting data from the domain where the system is supposed to be used (including user profiles). Once the system-to-be goals are derived and synthesized in a diagrammatic model, they should be formalized in LTL or Petri Nets.

**Figure 9.** The requirements life cycle (Reprinted with permission from Ref. [5]. Copyright 2021 IEEE).

Petri Nets structural and behavioral properties can analyze the dynamic process and workflow [37]. Verification should certify the work done and also provide directions for the new requirements cycling.

In the following, we will show the requirement cycle in a case study for a power supply system (a smart grid) installed in an isolated Amazon forest community.

#### **5. Case Study: Energy Supply in an Isolated Community**

The proposed method was applied in a case study based on the R&D Project "Minigrid with intermittent sources to serve isolated areas", which was a project conceived by a research group and implemented in an isolated community in 2012 [39]. The project's main goal was to develop and implement a solar–diesel battery microgrid, which we take as the system-as-is. The implementation domain was a small community in Laranjal do Jarí, located in Amapá province, covered by the Brazilian Amazon forest (Figure 10). In this region, many county communities are energetically isolated from the conventional hydroelectric provider.

The project was revisited to provide maintenance, that is, to attend to missed or emergent requirements and to improve automation. We detected some emerging requirements using the goal-oriented modeling built over the legacy system-as-is used to design the new system. Another goal of this maintenance process was to check and enhance sustainability and compatibility between the system and the local environment. Finally, the user coupling (originally only consumer) was also a goal, especially in terms of exploring this user's possibility to produce energy.

The microgrid mixed both AC and DC architecture, as shown in Figure 11. The legacy system (system-as-is) combined intermittent solar energy with battery sources and diesel generation units in a single automated generation system. The diesel generator was a backup unit to guarantee operation when the solar source was not producing the expected charge.

A data acquisition system (DAS) for control, monitoring, and storage was embedded in the network of inverters used to provide information about the system's behavior, such as the amount of energy generated and specific load consumption.

**Figure 10.** Location of the small villages where the project was implemented. Thet are close to a large hydroelectric facility but did not have energy.

**Figure 11.** Microgrid legacy system. There were two sources (PV): the microgrid provided an alternate current (CA) and the photovoltaic system provided power associated with a battery BT1, which provided a continuous current (CC). (Reprinted with permission from Ref. [25]. Copyright 2021 Sociedade Brasileira de Automática).

Energy meters monitor each customer's consumption and show when they overtake pre-established values. The monthly energy consumption of the units was not monitored by energy meters, as the purpose was not billing.

#### *5.1. Modeling the System-As-Is*

Following the requirement cycle of Figure 9, we started by organizing and classifying information, as shown in Table 1. This information was used to identify and justify objectives.



Some revisiting points emerged from the analysis. Most of them were derived from the emerging requirements or changes that appearred after implementation either in the environment or in the consumer's attitude. Such requirements would not be identified using a strictly functional approach, which justifies choosing a goal-oriented method.

The objective model for the legacy system's (system-as-is) objectives is shown in Figure 12. Basic information derived from the original project's documentation but additional expectations and constrains (and conflicts) emerged from the analysis of Table 2.

**Table 2.** Possible new goals to the project.


**Figure 12.** Objetives for System-As-Is (Adapted with permission from Ref. [25]. Copyright 2021 Brazilian Society of Automation).

The main goal for the system-as-is was to "Provide a low voltage microgrid" and it was refined in the sub-goals successively. For instance, "Meeting operational requirements" depends on the sub-objectives "Managing energy production", "Measuring consumption", and the expectation "Schedule maintenance". Requirement expectations are linked to the agents concerned with them: the Concessionaire, responsible for maintenance; the User; the Power Meter (a passive interface in the legacy system); the data acquisition system (DAS) Controller; or the financial provider (the Government). Notice that in the original project, the agent identified as "User" is responsible only for "Monitor Measurement", that is, this agent is not a consumer (recall that the system does not charge its consumers). Consequently, the project does not identify the system and its components as a service.
