Journal of Engineering Technologyselab.hongik.ac.kr/down/journal/20180731487-502.pdf · 2019-03-05 · Journal of Engineering Technology Volume 6, Issue 2, July. 2018, PP. 487-502

Journal of Engineering Technology Volume 6, Issue 2, July. 2018, PP. 487-502

487

Estimation on prioritization of failure rates based on operational profile

mechanism for a solar energy monitoring system

Woo Sung Jang, Byungkook Jeon*, and R. Young Chul Kim

SE Lab., Dept. of Software and Comm. Engineering, Hongik University, Sejong, 30016, Korea

*Dept. of Software, Gangneung-Wonju National University, Wonju City, 26403, Korea

Abstract: Our photovoltaic (PV) monitoring system consists of heterogeneous subsystems which

include a web monitoring server, a data collection server, a number of data collection clients, and

inverters. When receiving data from heterogeneous inverters with different data protocols, a main

monitoring server is difficult to monitor and manage each different data received between a main

server and other subsystems. To easily control this system, we did transform a uniform data with

metamodeling technique. Most important thing is that our system may be continuously working well

on solar energy generation. To reliably achieve the system, we propose to estimate failure rates of

operational profiles on the solar energy monitoring system based on Musa’s mechanism [5]. This

method can estimate failure rates, and prioritizes the occurrence probability of normal and abnormal

operations. We also generate test cases based on abnormal operation profiles with higher failure rates.

With these test cases, we can preferentially execute testing on the system. On system maintenance, we

can guarantee the software reliability through executing reliable test cases based on abnormal

operations.

Keywords: Operational Profile, Solar Energy Monitoring, System Failure Prioritization,

System Test Prioritization

1 Introduction

Many countries around the world are going on the significant advances in the research,

development, and dissemination or policies of renewable energies. Solar energy is one field of

renewable energy involving many technology-intensive mechanisms. Various studies have been

conducted on solar energy on power generation prediction, real time monitoring, and environmental

prediction [1, 2].

Recently, there are an increasing number of studies on fault detection and diagnosis of

photovoltaic (PV) power generation systems [3, 4]. However, few studies have been conducted on the

analysis of monitoring system failures. The previous general monitoring systems with heterogeneous

inverters did manage one by one per different protocols. Furthermore, the interactions between

diverse equipment are vulnerable to numerous errors which lead to incorrect measurements or

predictions of solar power generation. For this reason, we need to fix these errors. However, in reality,

we don’t have enough time to test the system due to limited resources.

Therefore, we identify the normal and abnormal functions of a PV monitoring system, which sub-

classify functions into “success operational cases” and “failure operational cases” based on an

operational profile mechanism. The success cases are a set of normal operations. The failure cases are


488

erroneous operations. All functional operations can be prioritized. First of all, we perform to test

success cases. Subsequently, failure cases can be performed consecutively in order of high priority of

occurrence probability. That is, we may guarantee the reliability of this system through testing failure

operational cases with high priority.

This paper is organized as follows. Section 2 describes Musa’s operational profile mechanism and

our metamodel based photovoltaic monitoring system (M-PVMS). Section 3 describes the procedure

for estimation on prioritization of M-PVMS functional failure rates. Section 4 shows success and

failure cases in the M-PVMS. Section 5 mentions conclusion.

2 Related works

2.1 Operational Profile [5]

An operational profile describes how users operate a system. Quantitative measurements are

performed to determine how the system will be utilized (which is essential for software reliability

engineering). A profile provides methods to enhance productivity, stability, and development speed.

When an operational profile is utilized to perform a test, a test with inherent limitations can be

performed successfully despite its constraints.

Development of an operational profile is a five-step process as follows: (1) find the customer

profile, (2) set the user profile, (3) define the system-mode profile, (4) determine the functional

profile, and (5) determine the operational profile. The order of these steps is illustrated in Figure 1.

Table 1 describes a list of each profile.

Table 1. Operational Profile Descriptions [5]

Name Description

Customer Profile Person, group, or institution that is acquiring the system. The complete set of

customer groups and their associated occurrence probabilities.

User Profile Person, group, or institution that utilizes the system. Set of user groups and

their occurrence probabilities.

System-mode Profile Set of functions or operations grouped for convenience for analyzing execution

behavior. Set of system modes and their associated occurrence probabilities.

Functional Profile Break each system mode down based on the functions it requires (creating a

function list) and determine each function's occurrence probability. Provides a

quantitative descriptions of the relative uses of different functions.

Operational Profile The manner in which the user will employ operations to accomplish functions.

An operation represents a task being accomplished by the system, sometimes

in a particular environment, as viewed by the people who will run the system.

Test Selection Execute a test utilizing the operational profile.


489

Figure. 1. Operational profile development process

2.2 Metamodel based Photovoltaic Monitoring System [6, 7]

In this study, an operational profile for a PV monitoring system is created. An M-PVMS is a PV

monitoring system that supports easy communication between various types of equipment. It also

supports automatic conversion between protocol models by applying the Object Management Group’s

model-driven architecture. When new equipment is added, system maintenance is possible with

minimal cost [8]. We also conducted study on the automatic test case generation with Sequence

Diagram of M-PVMS [9].

The overall structure of the system is illustrated in Figure 2. The DC electricity generated by the

PV cell is converted into AC electricity by the inverter. The inverter then measures the generated

electricity and delivers it to the M-PVMS client. Inverters manufactured by different companies

utilize various types of protocols. The M-PVMS client converts the data transmitted via various

protocols into integrated XML data with the metamodel based transformation method. The

transformed data are then transmitted to the M-PVMS server, which stores the received data in a

database (DB). The M-PVMS monitor reads the data stored in the DB, and displays the data in a web

browser.

Figure. 2. M-PVMS architecture


490

The elements in the M-PVMS are described below. We create operational profiles for the three

elements of the M-PVMS.

2.2.1 M-PVMS Server

The M-PVMS server manages the data from all power plants. The M-PVMS server transforms the

data transmitted by the M-PVMS client with metamodel transformation, stores the transformed data,

and updates the most recently generated data upon request from the M-PVMS monitor. Additionally,

the M-PVMS server sends periodic data updating requests to the M-PVMS client.

2.2.2 M-PVMS Client

The M-PVMS client manages the data from a single plant. The M-PVMS client receives update

requests (for power generation data) from the M-PVMS server, converts the power generation and

sensor data into metamodel data, and then transmits the converted metamodel data to the M-PVMS

server.

2.2.3 M-PVMS Monitor

The M-PVMS monitor displays the amount of power generation in a web browser, presents power

generation reports to the client, and requests data of the latest power generation from the M-PVMS

server upon request from the client.

3 Estimation on Prioritization of M-PVMS Failure Rates based on Operational Profile

Mechanism

We mention a prioritization method for functional failures in a solar energy monitoring system.

For prediction of failure, first, we describe how to identify the components of a solar energy

monitoring system for the creation of an operational profile. If a subsystem in a PV system fails, the

failures of associated subsystems may be predicted. Functions with a high occurrence probability of

failure can be intensively tested during system maintenance. Second, we also describe a flow for

prioritizing the test cases of normal functions and abnormal functions on an M-PVMS. The functions

of the M-PVMS are analyzed to create a customer profile, user profile, system-mode profile,

functional profile, and operational profile. The generated operational profile has then analyzed to

determine whether it is correct or incorrect on any necessary changes. Next, we create test cases based

on the final operational profile with its own occurrence probability. In figure 3, we show test case

generation and prioritization process of failure functional operations based on the Operational Profile

for M-PVMS.


491

3.1 Data Collection for the M-PVMS

The components of an M-PVMS include an M-PVMS monitor, M-PVMS server, M-PVMS

clients, inverters, junction boxes, and solar cells. Each component communicates on utilizing

heterogeneous and homogeneous protocols in our system. System components are analyzed for

application in the operational profile of our M-PVMS. The elements are analyzed as follows:

System components

Relationships between system components

Number of data requests and responses between system components

Data types in the system

Communication types in the system

Error log data

Communication logs in the system

3.2 Classification of Data Groups and Definition of Occurrence Probabilities

Our HS solar energy company (http://www.hsse.co.kr), they build 113 power plants around

Sejong city, Korea. We have applied on the integrated monitoring system of their power plans.

The collected data are grouped, and the occurrence probability of each group are defined. For

example, two types of power station’s communication protocols are Wi-Fi and LoRa. Among the total

113 power plants, 28 power plants utilize Wi-Fi communication, and 81 power plants utilize LoRa

communication. Therefore, the percentage of utilizing Wi-Fi communication among all plants is 23%

and the percentage of utilizing LoRa communication is 77%.

3.3 Generation of the Operational Profile

The data that are grouped and analyzed in Section 3.2 are applied in our operational profile. In

accordance with this procedure, the customer profile, user profile, system-mode profile, functional

profile, and operational profile are created. Each profile identifies different elements of the system, as

shown in Table 2. The detailed profile generation process is described in Section 4.

Table 2. System elements associated with each profile

Profile Elements

User Profile System monitor, Server manager, Client manager,

Inverter manager

System-mode Profile System monitor mode, Server manage mode, Client

manage mode, Inverter manage mode

Functional Profile All communication paths of inverter, client, and server

Operational Profile All system operation paths based on functional profile


492

3.4 Identification of Success and Failure Operational Profiles

Stakeholders analyze all operational profiles, and classify them as success and failure operational

profiles. Successful operational profiles indicate normal system operation. For example, a successful

profile might indicate that inverter power data has been successfully saved in the database. Failure

operational profiles indicate abnormal system operation. For example, inverter power data cannot be

saved in the database. Various issues may be happened such as lack of disk capacity or invalid access

authority. Failure operational profiles can be broken down into various operations for a single fault.

3.5 Test Case Generation and Prioritization

We generate test cases for both successful operational profiles and failure operational profiles.

The utilization of an operational profile requires a combination of successive functions. Successive

functions rely on the results of previous functions as the inputs to subsequent functions. Therefore, a

test case of an operational profile is a set of successive functions. With test cases based on operational

profiles, we can prioritize testing based on the occurrence probabilities of functions.

Figure 3 shows the failure test case generation and prioritization process based on the Operational

Profile for M-PVMS.

Figure. 3. The test case generation and prioritization process based on the Operational Profile for M-PVMS

4 Case Study

We utilize the collected M-PVMS data to create success and failure test cases. The data collection

process is not described here.

4.1 Customer Profile

The customer profile contains a single element, and the probability of occurring on an element is

100%.


493

Table 3. Customer profile for M-PVMS

Name Probability

Solar energy power plant 1.0

4.2 User Profile

The user profile includes a monitor, server, client, and inverter. The monitor refers to an M-

PVMS monitor, server refers to an M-PVMS server, client refers to an M-PVMS client, and inverter

refers to the inverter of a power plant. The probability of the occurrence of each element is

proportional to the number of pieces of equipment. The probabilities are listed in Table 4.

Table 4. User profile for M-PVMS

Name Probability

Monitor 0.01

Server 0.01

Client 0.43

Inverter 0.55

4.3 System-mode Profile

The system-mode profile includes server use, client use, inverter use, and monitor use. The

probability for the occurrence of each element is proportional to the number of data requests or data

responses. The probabilities of occurrence are listed in Table 5.

Table 5. System-mode profile for M-PVMS

Name Probability

Server use 0.01

Client use 0.04

Inverter use 0.93

Monitor use 0.02

4.4 Functional Profile

All functions of the M-PVMS are identified to create a functional profile. The types of functions

correspond to the functions of the M-PVMS server, M-PVMS client, and M-PVMS monitor. Both

success and failure cases of all functions are included. The associations of all functions are depicted.

4.4.1 Call Tree of Functional Profile

We generate a call tree for the functional profile. The call tree represents the probabilities of

occurrence of its associated functions. Each function has a probability of occurrence with any linked

functions. The probability of occurrence is calculated based on the number of database inquiries,


494

number of occurrences of function failures, and communication type of the power plant. For example,

the “packet data save failure (server)” on the gray color in Figure 7 is associated with insufficient disk

space, no DB, No table, and DB server access failed. These functions are all related to data storage.

The probability of occurrence is calculated from the data inquiry error log. The probabilities of

occurrence for all functions of inverter use in system-mode are presented in Figure 4.

Figure. 4. Call tree of inverter use

The probabilities of occurrence for all functions of server use in system-mode are presented in

Figure 5.

Figure. 5. Call tree of server use


495

The probabilities of occurrence for all functions of monitor use in system-mode are presented in

Figure 6.

Figure. 6. Call tree of monitor use

The probabilities of occurrence for all functions of client use in system-mode are presented in

Figure 7.


496

Figure. 7. Call tree of client use

4.4.2 Functional Profiles on Call Trees

A portion of the functional profile for client use is presented in Table 6. Other system-modes are

omitted because of their similar structures. We define all paths in the call tree for client use as “input

states.” We can calculate the probability of occurrence for each input state by multiplying the


497

probabilities in the call tree for client use. The resulting values are the probabilities of occurrence

during client use. The overall probability is the probability of occurrence in all system-modes, which

is calculated by multiplying the probability of occurrence of the input state and probability of

occurrence of the system-mode.

Table 6. Portion of functional profile for client use

Path Input State occurrence

probability overall probability

First

path

①

integrated request packet split encoding, failed to send split packet,

integrated packet decoding success, inverter error request, error data

response success, packet data save success (Client), create integrated

packet, packet transmission success, packet data save success (Server)

0.10030044024 0.0040120176096

Second

path

②




packet, packet transmission success, packet data save failure (Server),

insufficient disk space

0.0061460695296 0.000245842781184

Third

path

③





no DB

0.0001280431152 0.000005121724608

Fourth

path

④





no table

0.0000640215576 0.000002560862304

The first input state of Table 6 in client use call tree is illustrated in Figure 8.

Figure. 8. First path (success path) of Table 6 in client on call tree

The second, third, and fourth input state of Table 6 in client use call tree are illustrated in Figure

9.


498

Figure. 9. Second path, third path, and fourth path (failure paths) of Table 6 in client on call tree

4.4.3 Environmental Variables

External elements that affect the probability of functional profiles are identified. A functional

profile has a different probability based on its communication method. Therefore, communication

method is defined as an environmental variable. The probability of occurrence of this environmental

variable can calculated based on the number of communication methods in a power plant. The target

power plants utilize Wi-Fi and LoRa communication, and the probabilities of each variable are listed

in Table 7.

Table 7. Environmental variables of server use for M-PVMS

Type Name Probability

Wi-Fi W 0.23

LoRa L 0.77

4.4.4 Operational Profile

We generate an operational profile based on the functional profile. The input states from the

functional profile become operations. Likewise, the occurrence probabilities from the functional

profile become the occurrence probabilities of operations. For operations utilizing an environment

variable, we multiply the occurrence probability of the operation with the occurrence probability of

the environment variable. A portion of results is listed in Table 8.

Table 8. Portion of generated operational profile

Operation Environment overall


499

Variable probability

integrated request packet split encoding, failed to send split packet, integrated packet

decoding success, inverter error request, error data response success, packet data save

success (Client), create integrated packet, packet transmission success, packet data save

success (Server)

W 0.000922764

050208

L 0.003089253

559392




failure (Server), insufficient disk space

W 0.000056543

8396714

L 0.000189298

9415086




failure (Server), no DB

W 0.000001177

996658

L 0.000003943

727942




failure (Server), no table

W 0.000000588

998329

L 0.000001971

863971

4.5 Identification of Success/Failure Operational Profile

We identified the types of operation through stakeholder meetings. The identified types are

success and failure. Success indicates normal system function. Failure indicates a function with a

potential risk or an abnormal function. Such issues can result from low disk capacity, database errors,

etc. A portion of the results are listed in Table 9.

Table 9. Portion of identified operation profile

Type Operation Environment

Variable

overall

probability

Success

integrated request packet split encoding, failed to send split packet, integrated

packet decoding success, inverter error request, error data response success,

packet data save success (Client), create integrated packet, packet transmission

success, packet data save success (Server)

W 0.000922764

050208

L 0.003089253

559392

Failure




success, packet data save failure (Server), insufficient disk space

W 0.000056543

8396714

L 0.000189298

9415086

Failure




success, packet data save failure (Server), no DB

W 0.000001177

996658

L 0.000003943

727942

Failure




success, packet data save failure (Server), no table

W 0.000000588

998329

L 0.000001971

863971


500

4.6 Test Cases for Operational Profile and Prioritization on Occurrence Probability

Next, we add inputs, conditions, and expected results to the operational profile. Inputs are the

input actions or values for the test. Conditions are system conditions related to the inputs. Expected

results are the expected results for given input values. Table 10 is portion of test cases based on operation

profile.

Table 10. Portion of test cases based on operation profile

Type Operation Env.

Var.

Overall

Probability Input Condition Expected Result

Success

integrated request packet split

encoding, failed to send split

packet, integrated packet decoding

success, inverter error request,

error data response success, packet

data save success (Client), create

integrated packet, packet

transmission success, packet data

save success (Server)

W 0.0009227

64050208

Input power data

packet from inverter

into M-PVMS Client

None System

inaccessible

L 0.0030892

53559392

Input power data


into M-PVMS Client

None

No output

message. View

the latest

generation data

from the

database. New

data should be

retrieved within

1 minute

Failure









save failure (Server), insufficient

disk space

W 0.0000565

438396714

Input power data


into M-PVMS Client

M-PVMS

Server does

not have

hard disk

capacity

System

inaccessible

L 0.0001892

989415086

Input power data


into M-PVMS Client

M-PVMS

Server does

not have

hard disk

capacity

M-PVMS Server

outputs

"Insufficient disk

space" message

Failure









save failure (Server), no DB

W 0.0000011

77996658

Input power data


into M-PVMS Client

No MySQL

DB on M-

PVMS

Server

System

inaccessible

L 0.0000039

43727942

Input power data


into M-PVMS Client

No MySQL

DB on M-

PVMS

Server

M-PVMS Server

outputs "No DB"

message

Failure









save failure (Server), no table

W 0.0000005

88998329

Input power data


into M-PVMS Client

No Table of

MySQL DB

on M-

PVMS

Server

System

inaccessible

L 0.0000019

71863971

Input power data


into M-PVMS Client

No Table of

MySQL DB

on M-

PVMS

M-PVMS Server

outputs "Did not

find DB Table"

message


501

Server

All test cases have a certain probability of occurrence. The test cases with a high probability of

occurrence must be checked first within the system. These test cases are classified as successful or

failure cases. Successful test cases must be passed. Failure test cases are tests of errors with potential

risks. The optimal way should involve running all failure test cases. In some cases, if not testing

enough test time, we should perform testing in the order of priority based on the occurrence

probabilities of failure rates.

5 Conclusions

Our integrated monitoring system is comprised of various subsystems, which can manage the

communication between heterogeneous inverters, and are vulnerable to various types of errors.

Generally, if not enough testing time, it is difficult to guarantee reliability of the system. Furthermore,

for system maintenance, numerous tests should be repeated.

We propose to estimate failure rates of operational profiles on the solar energy monitoring system

based on Musa’s mechanism [5]. This method can estimate failure rates, and prioritizes the

occurrence probability of normal and abnormal operations. We also generate test cases based on

abnormal operation profiles with higher failure rates. With these test cases, we can preferentially

execute testing on the system. On system maintenance, we can guarantee the software reliability

through executing reliable test cases based on abnormal operations

Acknowledgments

This research was supported by Basic Science Research Program through the National Research

Foundation of Korea(NRF) funded by the Ministry of Education(NRF-2017R1D1A3B03035421), and

supported by Development of Information Communication and Broadcast R&D(2018 Open OS

Environment Development and Diffusion) through NIPA(National IT Industry Promotion

Agency)(S1113-18-1001), and supported by a grant(18CTAP-C133299-02) from Technology

Advancement Research Program funded by Ministry of Land, Infrastructure and Transport of Korean

government. . Also, this work was supported by the Human Resource Training Program for Regional

Innovation and Creativity through the Ministry of Education and National Research Foundation of

Korea (NRF-2015H1C1A1035548).

References

[1] Korea Energy Agency New and Renewable Energy Center, "2016 Understanding of New and Renewable

Energy", 2016.


502

[2] R. Leyva, C. Alonso, I. Queinnec, A. Cid-Pastor, D. Lagrange, L. Martinez-Salamero, "MPPT of

photovoltaic systems using extremum-seeking control", IEEE Transactions on Aerospace and Electronic

Systems 2006; 42:249-258.

[3] D. Sera, R. Teodorescu, "Photovoltaic module diagnostics by series resistance monitoring and temperature

and rated power estimation," Annual Conference of IEEE, pp.2195-2199, 2008.

[4] K.H. Chao, S.H. Ho, M.H. Wang, "Modeling and fault diagnosis of a photovoltaic system," Electric Power

Systems Research 2008; 78:97-105.

[5] John D. Musa, "Operational Profiles in Software-Reliability Engineering", Journal IEEE Software 1993;

10:14-32.

[6] Woo Sung Jang, Hyun Seung Son, Bo Kyung Park, Byung Kook Jeon, R. Young Chul Kim,

"Implementation of Effective Web Integrated Monitoring System for Small Renewable Energy business

Industries", Korean Institute of Smart Media 2016; 5(1):303-305.

[7] Woo Sung JANG, Hyun Seung SON, Chae Yun SEO, R. Young Chul KIM, "Meta-model based

Photovoltaic Monitoring System for Heterogeneous Renewable Energies", Asia Pacific Society for

Computing and Information Technology 2017, 44-47.

[8] Son, H.S., Kim, W.Y., Kim, R. Y. C., "A Study on Modeling Tool for Convergence of Smart Appliances",

The Journal of IIBC (The Journal of The Institute of Internet, Broadcasting and Communication) 2008;

8(4):119-125.

[9] Woo Sung Jang, Byung Kook Jeon, Hyun Seung Son, R. Young Chul Kim, " Automatic Test Case

Generation for Validating the Dynamic Behaviors of the Complete Solar Power Monitoring System",

Multimedia Tools and Applications(Springer) 2018.

Corresponding Author : Byungkook Jeon, R. Young Chul Kim

Documents

Journal of Engineering Technologyselab.hongik.ac.kr/down/journal/20180731487-502.pdf · 2019-03-05 · Journal of Engineering Technology Volume 6, Issue 2, July. 2018, PP. 487-502