assessment of information reliability using iec 61850 mms...

Assessment of informationreliability using IEC 61850 MMS

in control scenarios over imperfectcommunication networks

- IEC 61850 MMS as application layer protocol over TCP/UDPfor remote control of DERs in LV grid -

Project Report

Group 1024

Aalborg UniversityElectronics and IT

Copyright c© Aalborg University 2016

Electronics and ITAalborg University

http://www.aau.dk

Title:Assessment of information reliability usingIEC 61850 MMS in control scenarios overimperfect communication networks

Theme:IEC 61850 MMS

Project Period:Master of Science (M.Sc) ThesisSpring Semester 2016

Project Group:1024

Participant(s):Rafia Umair

Supervisor(s):Rasmus Løvenstein Olsen

Copies: 2

Page Numbers: 85

Date of Completion:June 2, 2016

Abstract:

The trend of producing energy from Re-newable Energy Sources (RES) is increas-ing greatly. Indeed RES has the capabilityto fulfil global need of power energy. Thisleads to the objective of building futurepower system entirely based on renewablesources. Since RES, such as wind powerexhibits non linearities and uncertaintiesin power production due to wind varia-tions and prediction errors. Therefore, acontroller system is required to effectivelygovern and communicate production andconsumption of the wind power supply.This research focuses on microgrid sce-nario of low voltage grid for remote con-trol of a wind turbine through IEC 61850MMS. In order to control wind power en-ergy production, MMS messages must bedelivered with reliable information to con-troller to achieve its optimum efficiency.This raises a challenge to assess informa-tion reliability and evaluate controller per-formance. The thesis models IEC 61850MMS protocol over both TCP & UDP andanalyze information reliability and con-troller performance over various imperfectcommunication networks.

The content of this report is freely available, but publication (with reference) may only be pursued due toagreement with the author.

http://www.aau.dk

Contents

List of Figures xi

List of Tables xv

Preface xvii

Glossary xix

1 Introduction 1

1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Organisation of Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Background 7

2.1 Smart Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Distributed Energy Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3 Microgrid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Microgrid Control System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 What is Substation Automation System? . . . . . . . . . . . . . . . . . . . . . . 10

2.6 Data Communication in Substation Automation . . . . . . . . . . . . . . . . . 12

v

vi Contents

2.7 Standards and Protocols for Substation Automation Communication . . . . . 13

2.8 What is IEC 61850 ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.8.1 IEC 61850 Standard and Overview . . . . . . . . . . . . . . . . . . . . . 14

2.8.2 Features of IEC 61850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.9 What is IEC 61850 MMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.9.1 Manufacturing Message Specification . . . . . . . . . . . . . . . . . . . 19

2.9.2 Client/Server Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Analysis 23

3.1 Analysis of Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1.2 Abstract Model of Wind Turbine Energy Production . . . . . . . . . . 25

3.1.3 Client Server Communication . . . . . . . . . . . . . . . . . . . . . . . 26

4 Requirement and Challenges 29

4.1 Functionality Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Performance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.1 Transfer Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2.2 Message Performance Requirements . . . . . . . . . . . . . . . . . . . . 30

4.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.2 Packet Losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.3 Network Failure Detection and Recovery time . . . . . . . . . . . . . . 32

4.3.4 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3.5 Controller Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Contents vii

5 Specification and Design 35

5.1 Technical Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1.1 Controller (MMS Client) . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.2 Wind Turbine (MMS Server) . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1.3 ISP Cloud Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2 Technical design of Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2.1 Modeling of IEC 61850 MMS Protocol through TCP and UDP . . . . . 37

5.2.2 Modeling of MMS Server . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2.3 Modeling of MMS Client . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6 Implementation using ns-3 Simulation Platform 43

6.1 IEC 61850 MMS Model over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1.1 MainwithUDP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.1.2 Request-response-server module . . . . . . . . . . . . . . . . . . . . . . 44

6.1.3 Request-response-client module . . . . . . . . . . . . . . . . . . . . . . 45

6.1.4 Request-response-helper module . . . . . . . . . . . . . . . . . . . . . . 46

6.2 IEC 61850 MMS Model over TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.2.1 MainwithTCP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.2 MMS-packet-sink module . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.3 TCP-request-response-client . . . . . . . . . . . . . . . . . . . . . . . . 47

6.2.4 MMS-packet-sink and TCP-request-response helper module . . . . . . 47

7 Experiments and Evaluation 49

7.1 Test Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii Contents

7.3 Values of Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.4 Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

7.5 Simulation Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.5.1 Test Case 1: Network delay . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.5.2 Test Case 2: Network unavailability . . . . . . . . . . . . . . . . . . . . 58

7.5.3 Test Case 3: Network link error . . . . . . . . . . . . . . . . . . . . . . . 63

8 Conclusion and Future Work 69

8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

8.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Bibliography 73

A Input Parameters of markov model for wind turbine 77

A.1 Initial Parameters of markov model . . . . . . . . . . . . . . . . . . . . . . . . 77

A.1.1 Generator matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.1.2 Mean holding time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.1.3 Transition matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.2 Parameters of markov model to drift up states in forward direction . . . . . . 78




A.3 Parameters of markov model to drift up states in backward direction . . . . . 79



Contents ix


B Matlab code to calculate mismatch probability 81

C Matlab code to calculate quality of controller performance 83

D IEC 61850 logical node for wind turbine smart metering 85

List of Figures

1.1 Microgrid control system, [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Overview of smart grid [35] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Substation automation system structure . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Data modeling approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 IEC 61850 communication stack . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 Concept of virtual manufacturing device . . . . . . . . . . . . . . . . . . . . . 21

3.1 Microgrid scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Client server communication in microgrid scenario . . . . . . . . . . . . . . . 25

3.3 Markov chain model of wind turbine energy production . . . . . . . . . . . . 26

3.4 Sequence diagram for client server communication in microgrid scenario . . 27

3.5 Communication network for RES . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1 Definition of transfer time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Definition of latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3 Definition of packet losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Definition of connection lost detection and recovery time . . . . . . . . . . . . 32

xi

xii List of Figures

4.5 Request Rk receiving a correct information of state, while Rk+1 a mismatchinformation [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1 Technical specification of scenario . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2 The protocol layers of MMS over TCP and UDP . . . . . . . . . . . . . . . . . 38

5.3 State transition diagram with transition rate λ and µ . . . . . . . . . . . . . . 40

5.4 Generator matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.5 State transition diagram with rate λ + 4 in forward direction . . . . . . . . . 41

5.6 State transition diagram with rate µ + 4 in backward direction . . . . . . . . 41

6.1 Implementation of IEC 61850 MMS model over UDP in ns-3 . . . . . . . . . . 44

6.2 MMS server implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.3 MMS client implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4 Implementation of IEC 61850 MMS model over TCP in ns-3 . . . . . . . . . . 47

7.1 State transition diagram with transition rate λ and µ (along their values) . . 51

7.2 State transition diagram with constant drift rate 4 in forward direction . . . 51

7.3 State transition diagram with constant drift rate 4 in backward direction . . 51

7.4 Network topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

7.5 Assess mmPr for different network delays . . . . . . . . . . . . . . . . . . . . 55

7.6 Quality of controller performance for different network delays . . . . . . . . 56

7.7 Confidence interval for mmPr vs Network delay . . . . . . . . . . . . . . . . . 57

7.8 Assess mmPr with network unavailability of 2 sec for 5 times . . . . . . . . . 59

7.9 Assess mmPr with network unavailability of 10 sec for 5 times . . . . . . . . 60

7.10 Quality of controller performance with 5 TCP connection losses for 2 sec . . 61

7.11 Quality of controller performance with 5 TCP connection losses for 10 sec . . 62

List of Figures xiii

7.12 Assess mmPr for different network link error . . . . . . . . . . . . . . . . . . . 64

7.13 Quality of controller performance for different link error . . . . . . . . . . . . 64

7.14 Confidence interval for mmPr vs Network link error . . . . . . . . . . . . . . 66

D.1 Logical node class MMTR (metering) . . . . . . . . . . . . . . . . . . . . . . . 85

List of Tables

2.1 The IEC 61850 standard - overview and scope [15] . . . . . . . . . . . . . . . . 15

2.2 List of logical node groups [32] . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 MMS objects and services mapping [1] . . . . . . . . . . . . . . . . . . . . . . 22

7.1 Test cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 List of parameter and their constant values . . . . . . . . . . . . . . . . . . . . 53

7.3 Latency measurement for different communication technologies . . . . . . . 55

7.4 Percentage of packet losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

xv

Preface

This report has been written by a student of Network and Distributed systems 10th semesterproject. This project was proposed by my supervisor Rasmus Løvenstein Olsen. The pur-pose of this project was to investigate the impact of different network performance pa-rameters while controlling wind turbine energy production remotely, in low voltage gridenvironment and evaluate the gain in form of mismatch probability (mmPr) and quality ofcontroller performance. This was done, by modeling of stochastic process of wind turbineenergy production and control operation of controller. Likewise, IEC 61850 MMS has alsobeen modelled over TCP and UDP to simulate the MMS communication between windturbine (MMS server) and controller (MMS client).

Material such as, the source code for the simulation, MATLAB code, and the report as allavailable on the project group website: http://kom.aau.dk/group/16gr1024

On a last note, First, I am grateful to my God, for His blessings and help. I would alsolike to thank my supervisor Rasmus Løvenstein Olsen for the time spend in guiding forthe project and thanks to Kamal Shahid (Ph.d student) for his all help and motivation. Inthe end, a big thank to my husband for being supportive and cooperative through out myeducation period. Without his understanding and loving nature it would be difficult forme to accomplish this project work.

Aalborg University, June 2, 2016

Rafia Umair<[email protected]>

xvii

http://kom.aau.dk/group/16gr1024

Glossary

ACSE Association Control Service Element. 38

ACSI Abstract Communication Service Interface. 18

ASN Abstract Syntax Notation. 38

BER Basic Encoding Rules. 38

CHP Combined Heat and Power. 9

CL Connection-Less. 38, 39

CLTP Connection Less Transport Protocol. 36

CO Connection-Oriented. 38

COTP Connection Oriented Transport Protocol. 36

CT/PT Current/Potential Transformers. 11

DER Distributed Energy Resources. 1, 2, 4, 5, 8, 9, 29, 35

DES Distributed Energy Storage. 1

DGS Distributed Generation System. 9

DNP Distributed Network Protocol. 13

EPRI Electric Power Research Institute. 13

GOOSE Generic Object Oriented Substation Events. 18

GPS Global Positioning System. 11

GSSE Generic Substation State Events. 18

HMI Human Machine Interface. 11, 20

IEC International Electrotechnical Commission. 2, 13

xix

xx Glossary

IED Intelligent Electronic Devices. 2, 3, 10, 13, 15, 17

ISP Internet Service Provider. 3

LN Logical Node. 36

LON Local Operating Network. 13

LV Low Voltage. 1, 4, 9, 24, 34, 35, 54

LVGC Low Voltage Grid Controller. 1, 8, 24, 26, 33, 50

MHT Mean Holding Time. 40, 50

mmPr Mismatch Probability. 33, 49

MMS Manufacturing Message Specification. 2, 4, 18–21

MV Medium Voltage. 1

MVGC Medium Voltage Grid Controller. 1

OPC-DA Open Platform Communications-Data Access. 13

OSI Open Systems Interconnection. 2

PV PhotoVoltaic. 3, 9

RER Renewable Energy Resources. 9

RES Renewable Energy Sources. 1, 10, 25, 34

RTU Remote Terminal Unit. 11

SA Substation Automation. 2

SAS Substation Automation System. 7, 10, 12, 13, 17, 18

SCADA Supervisory Control And Data Acquisition. 12, 20

SCL Substation Configuration Language. 17, 18

SCSM Specific Communication Service Mapping. 18

SV Sampled Values. 18

TC57 Technical Committee 57. 13

TCP/IP Transmission Control Protocol/ Internet Protocol. 2

VMD Virtual Manufacturing Device. 19

WT Wind Turbine. 3, 24–26

Chapter 1

Introduction

In past, power generation was mainly done by big centralized power station such as nu-clear power plant, fossil fuel, gas, coal fired and hydroelectric dams. But with advancementin technology and for environment protection, distributed and Renewable Energy Sources(RES) are implemented worldwide, especially in Europe, Canada, U.S and Japan [38]. Dan-ish Government and Parliament has also set goals for integration of RES. According to goalset by the Danish government, by 2050 danish power system will move to 100% renewableenergy and Danish parliament aiming 50% reduction of fossil fuels for electricity and heatfrom 2010 to 2020 [20].

Therefore, centralized power generation is evolving towards Distributed Energy Resources(DER). DER is different from centralised power generation that it is distributed, locatednear by end users and easy to install. Furthermore, DER produce electricity in environ-mentally friendly, secure, sustainable and reliable manner. However, the biggest challengeof DER network is to monitor and control its operations. Thus, for simplification of con-trol and management of DER, Microgrid concept is introduced. Microgrid is basicallysmall scale power system. It comprises of DER, Distributed Energy Storage (DES) andcontrollable loads. The purpose of microgrid is to self maintain DER in conjunction withtransmission, distribution and storage of electricity. It is also seamlessly synchronisedconnection to a utility power and can also operate as an independent power system [37].

In order to realise the objectives of microgrid, a microgrid control system is required to ac-tively balance between energy sources and energy consuming devices. The control systemhas hierarchical control structure, composed of Medium Voltage Grid Controller (MVGC)and Low Voltage Grid Controller (LVGC) [6]. MVGC is employed for controlling theMedium Voltage (MV) grid and likewise LVGC for Low Voltage (LV) grid [26], shown inFigure 1.1.

1

2 Chapter 1. Introduction

Control Center

WAN

WAN

Access Network

DER

Load Storage Meters

MVGC

LVGC

Figure 1.1: Microgrid control system, [6]

In pursuance of microgrid control system’s objectives, a bidirectional communication stan-dard is required between different components of microgrid. Since microgrid has multivendor DER and their Intelligent Electronic Devices (IED) so it is a fundamental require-ment to solve interoperability issue among DER. Although, International ElectrotechnicalCommission (IEC) introduced IEC 61850 standard to solve interoperability among IED inSubstation Automation (SA) but is also adapted for the integration of DER into commu-nication networks. Thus controller uses IEC 61850 services on Manufacturing MessageSpecification (MMS) to control DER, where MMS is an application layer protocol that canrun over Open Systems Interconnection (OSI) or Transmission Control Protocol/ Internet

1.1. Problem Statement 3

Protocol (TCP/IP).

1.1 Problem Statement

Major requirement of microgrid is, interconnection of its components to control centervia a communication infrastructure to support a variety of messages such as real timemonitoring, control, demand and response. Therefore, it is significant to assure that allcommunication messages’ latency time period must satisfy transfer time requirement. Fur-thermore, it is also necessary to check that all information received at controller matchesto correct true value at sender side and network parameters in not influenced on optimumperformance of controller. Therefore, analysing impact of network performance on MMScommunication is of critical importance in the DER network.

In current microgrid system, communication between DER and control center is carriedout through IEC 61850. A RES, like PhotoVoltaic (PV) and Wind Turbine (WT) that is to becontrolled and monitored by IEC 61850 client( i-e, controller), have IEC 61850 Server (alsoknown as IED). IED represents all parameters of RES that are readable and/or writeableby the client. To facilitate the communication between client and server IEC 61850 MMSstandard is followed. IEC 61850 supports flexibility of choosing different communicationnetwork for example 3G, 4G, LTE and WiMAX etc. But here, this research focuses onEthernet based Internet Service Provider (ISP) cloud as communication medium.

The scope of this MS thesis is in LV grid. Although microgrid control system has manyresponsibilities but regarding LVGC, Energy balancing is one of its objective. Energy bal-ancing makes sure that there is a balance between production and demand. Naturally, RESsuch as PV’s and WT’s power production is a random process because energy producedby PV and WT is influenced by uncertain weather conditions. For instances there are prob-abilities of sunny or windy day which effects the power production of DER. Therefore,controller implementing the energy balancing functionality collect information of powerproduction from each RES. The process of collecting information is periodic based, whichis also a stochastic process. Upon receiving real-time information of power productionfrom RES server, LVGC performs decision of possibly to increase or decrease productionor either shut down or turn on certain PV or WT. The performance of LVGC decisionis highly dependent upon communication messages, carrying information of power pro-duction, must be received on time. Therefore, a MMS message delivery must satisfy itstiming requirement. Although such IEC 61850 MMS based messages usually do not havethe highest performance requirements but immense number of PV and WT in a micro-grid system, effect the network performance due to load. Therefore, a controller collectinginformation from multiple RES servers, cause increment in network traffic resulting innetwork congestion and delay. Furthermore, process of collecting information is periodicprocess so must have rate to execute the process. So, usually rate factor also contribute inincreasing latency of communication messages, consequently effecting the performance ofLVGC. Moreover, a delayed message may lead carrying information obsolete which directs

4 Chapter 1. Introduction

controller for inappropriate decisions.

This research has mainly focused on assessing information reliability using IEC 61850MMS in control scenarios over imperfect networks because controller getting out of dateinformation potentially leads to reduction in control performance. Therefore informationreliability is interesting to study. Research has also targeted to measure quality of controllerperformance under different network conditions.

1.2 Research Question

The aim of project work is to analyze the impact of network performance parameters forremote controlling of DER in LV grid, while modeling IEC 61850 MMS over TCP and UDPboth.

Thus, main research question has been stated as below:

How can network performance be effected on remote control communication for DER, while mod-elling IEC 61850 MMS as an application layer protocol over TCP and UDP?

The main research question is further sub-divided into the following questions:

1. What are the main requirements and challenges of integrating IEC 61850 MMS to supportremote control communication for distributed energy sources ?

This question, the main requirements and challenges of remote control for dis-tributed energy resources, has been answered in chapter 4,

2. Compare performance analysis of IEC 61850 over TCP and UDP for different performanceparameters, such as packet delay, connection time out (lost) and packet losses.

To answer this question. First, MMS model has been designed, described in detailchapter 5 and chapter 6. Later chapter 7 has illustrated results about performancecomparison of designed model for TCP and UDP both.

3. How packet delay, transport layer connection and packet losses between LVGC and RES,influences the performance of the LVGC ?

Simulation based experiments on ns-3 has been conducted to analyze influence ofpacket loss and latency on quality of LVGC performance. It has been explained indetail in chapter 7.

1.3. Organisation of Report 5

4. Assess the reliability of received information about energy production from RES?

This question has been answered through the experiments and discussed in chap-ter 7

1.3 Organisation of Report

Rest of the report has been organised as follows:

chapter 2 presents some background information that is needed in order to understandand develop this project. It consists of study about smart grid, substation automation sys-tem, remote control communications in distributed grid and IEC 61850 MMS protocol.

chapter 3 presents scenario adopted in this project.

chapter 4 describes the requirements of IEC 61850 MMS and challenges of integrating it tosupport remote control communication for DER.

chapter 5 focuses technical specification of modeling IEC 61850 MMS over UDP and TCPfor remote control of DER in LV grid. It also covers the modeling and design of WindTurbine power production levels.

chapter 6 provides implementation of IEC 61850 MMS model along with MMS client andserver modeling in ns-3 simulation platform.

chapter 7 covers details of test execution and results.

Finally in chapter 8, conclusion and future work has been presented.

Chapter 2

Background

The chapter gives the background information about the smart grid and Substation Au-tomation System (SAS) and IEC 61850 protocol.

2.1 Smart Grid

Electricity is the most utilized form of energy with continuous increasing demand aroundthe globe. Today’s electrical production and utility has been transformed from central gen-eration and control to distributed scenario. The distributed and versatile power productionand consumption is built on advanced infrastructure to facilitate the sustainable and re-liable management of electricity. In this fashion, power grid are complex and distributedsystem. Thus, a Smart grid is an evolved power grid, with challenge of balancing energy.The problem with energy balance is that several parameters needs to be controlled andbalanced.

• Voltage

• Frequency

• Production and consumption

Keeping in mind distributed and complex nature of smart grid, interdisciplinary concepthas been introduced in Smart Grid, to address the challenge of energy equivalence. Hence,the purpose of inter-discipline is to control and balance electricity consumption and pro-duction in sustainable, reliable and economic manner.

7

8 Chapter 2. Background

Generation Transmission Distribution and Consumption

Power Plants

Commercial Area

Factory and Industrial Consumption

Residential Consumption

Residential Area

Distributed Generation

Substation Automation

System

Substation

Substation

Solar Plants

Wind Farms

PVs

WTs

LVGC

Microgrid Network

Note:

= Communication Network

Figure 2.1: Overview of smart grid [35]

The above diagram represents general overview of Smart grid that how different domainsof power grid like, generation, transmission, distribution, DER and consumption are con-trolled and manage via control center. The diagram further elaborate role of communica-tion technologies for bidirectional flow of the information among different domains. Theinformation carried through the communication technologies helps to govern power pro-duction and consumption in reliable and secure manner. The lower part of diagram alsorepresents the microgrid network which interconnects DER and is controlled and managedby LVGC.

2.2. Distributed Energy Resources 9

2.2 Distributed Energy Resources

DER is small scale electric power generator which generate power in kilowatts [30] such aswind power plants, hydro electric power plants, micro gas turbine, geothermal, CombinedHeat and Power (CHP) plants and PV systems. In contrast to traditional power generation,DER has less environmental impacts, easy to install, efficient and reliable [2]. Typically,DER are installed closer to end user thus provides advantages of reliable, uninterruptible,secure supply of power and also address shortcomings of long distance transmission [12].

But after extensive research on DER, it is soon realized that besides benefits, large scaleDER also has some lapses, such as high cost to access single generation and moreover theyare complicated to control. For Example. Distributed Generation System (DGS) must shut-down when it has produced enough power or when it has impact on the system voltageand frequency [12]. Therefore, DER requires a system for its control and management.Thus, Microgrid concept is introduced to provide environmental friendly and sustainableelectricity from Renewable Energy Resources (RER) in reliable and secure manner. In nut-shell, DER systems can be governed and integrated through microgrid, within a smartgrid.

2.3 Microgrid

Although, microgrid has no universal definition. Commonly, it is defined as a small powersystem which interconnects DER. It is self maintained low voltage distribution networktypically located near to end user. It has variety of components of distribution generators,transmission, sensors and management. It familiarises concept of prosumer, a blend ofenergy producer and consumer. Furthermore, microgrid may operate independently as anisland of smart grid system [33] [37]. In this project work, it is characterize as a smallerset of smart grid comprising of DER to connect, control and manage them remotely in LVenvironment.

A microgrid controller has many responsibilities such as:

• Isolation and interconnection of microgrid with main utility power

• Coordination between various DGs, DERs and loads

• Forecast of energy resources data, load and production

• Policy making and electricity market information

• Minimization of system losses and maximizes operational efficiency

• Voltage Control

• Management of DER


• Management of energy storage

2.4 Microgrid Control System

The modern concept of microgrid allows integrations of small scale RES into local powersystem. For optimal utilization of renewable energy, control system must be implementedin power system. Control system is mainly responsible to:

1. Voltage control

2. Energy balancing

3. Loss minimization

4. Maximize the profit subject to flexibility. Where flexibility is a concept which com-bines consumption, production and storage into one flexible entity

2.5 What is Substation Automation System?

Increasing complexity of smart grid has led automated operation of power transmission,distribution and management. Thus automation in the field of power electric system en-ables implementation of supervisory management and controlling power system.

"Power system automation means protection, control, measurement and monitoring through datacommunication".

The method of controlling, measurement and supervisory management of power systemis known as Substation Automation (SA). SA is composed of IED which are connectedthrough high speed communication medium, whereas IEDs are intelligent devices thatperforms significant role in act of automatically controlling the power system. It performsvarious operations related to control, protection, measurement and supervision of differ-ent components of power system. Thus, SA is controlling mechanism of power systemautomatically via IEDs using control commands from remote users. Finally, a SAS is acomputer system which allows e.g. administrator to communicate with the substationover a computer network such as the internet [10].

SubstationA substation is a subsidiary station of an electric power generation, transmission and dis-tribution system, where electrical lines and cables are connected from electric generatorsfor transmission and distributions of electric power [10] [11]. It performs the functionof transforming the voltage from high to low for distribution substation and vice versa.The function of voltage regulation is done by the transformer installed at substation. A

2.5. What is Substation Automation System? 11

Substation is also capable of performing various other functions as well, such as switch-ing, breaking, control and monitoring of the switch yard, recording, protection of thepower equipment, revenue metering and automation functions for energy managementand assert management [11]. Traditional substation is composed of conventional substa-tion with interlocking logic, Remote Terminal Unit (RTU), relays, conventional switchgearand Current/Potential Transformers (CT/PT). Each component is hardwired connectedwith parallel Cu wires [11].

Modern architecture of SAS is structured in three basic levels [11]:

• Station Level: Station level is located in the control room and it provides wholeoverview of substation. It includes Human Machine Interface (HMI), master stationcomputer, backup station computer and Global Positioning System (GPS) receiver,etc.

• Bay Level: Bay level is responsible for conducting maintenance work within onebay. It is close to the switchgear. It comprises of protection and control IED ofdifferent bays. The equipments at station and bay level are also known as secondaryequipments.

• Process Level: Process level covers the primary equipments such as switchyardequipment, CT/PT, remote I/O, actuators and merging unit , etc. All event mes-sages generated by the station level are captured in this level. Control commandsreceived from bay level are executed in the equipments at process level.

WLAN

Protection IED

HMI

Control IED

Process DeviceCircuit Breaker

Process DeviceSwitchgear

CT/PTs

Process DeviceMerging Unit

SCADA

Station Bus

Process Bus

STATION LEVEL

BAY LEVEL

PROCESS LEVEL

Figure 2.2: Substation automation system structure


Purpose and function of various component of SAS are defined below:

Supervisory Control And Data Acquisition

In Figure 2.2, Supervisory Control And Data Acquisition (SCADA) is a client which is ableto connect to a substation also referred as control center or SCADA system. The name ofthe components itself describing its function which is as follow [29]

• It contains data information received from IEDs and process and display it.

• It also keeps record of all received and retrieved information.

• Furthermore, display sequence-of-event reports and disturbance recordings whenneeded.

• It also performs function of activating alarms when necessary.

• It also transfer information over communication medium.

• SCADA also supervises and issues control commands for distributed componentsof power system.

Therefore SCADA system is also refer as master station based on hardware and softwareto provide operator interface for control, supervision and remote configuration of IEDs.

IEDIED is intelligent device embedded with microprocessor based relays. It is a versatiledevice that provides following functions to power automation system:

• electrical protection

• remote and local control Intelligence

• metering

• monitoring

• communication to SCADA system

2.6 Data Communication in Substation Automation

Data communication in substation plays a significant role for real time mission critical andnon critical operations of SAS. More often TCP/IP based LAN communication is providedin SCADA and SAS [11]. In modern SAS, all primary and secondary equipment are in-terlinked through communication buses. In conventional substation communication wasserial or propriety based. While in current substation, there are two types of communica-tion i.e. horizontal and vertical. Horizontal communication means communication within

2.7. Standards and Protocols for Substation Automation Communication 13

one level. Vertical communication refers to communication between station, bay and pro-cess level and facilitated by high speed ethernet station bus and process bus. Station busis used for communication between station level and bay level. Process bus provides com-munication services between bay and process level.

Station bus carries the time based data from multiple bays to analyze equipment at sta-tion level. The control commands for primary equipment (e.g circuit breaker) and datalike current, voltage and power factor are collected at station level. In bay level, controland protection IED collects data from bays and performs time critical action at primaryequipment through process bus. Thus process bus carries the time critical messages [11].

2.7 Standards and Protocols for Substation Automation Com-munication

SAS communication also require protocol and standards for communicate between IEDsand other devices. There are three standard categories of SAS communication [11].

• Vendor/Pro proprietary/vendor specification, e.g. UCA and DNP3, etc.

• National standard, e.g. IEEE 1613, etc.

• International standard, e.g. IEC 60870-5-101/104, IEC 60870-6-TASE.2, IEC 61850,etc.

In past, there were more than 50 protocols used for communication in legacy SASs. Forexample, Modbus TCP, ProfiNet, EthernetIP, Open Platform Communications-Data Access(OPC-DA), Local Operating Network (LON), Distributed Network Protocol (DNP) andIEC-870-5-101. These protocols have various limitations such as vendor specified, lowbandwidth, have serial interface, limited network devices and inflexible data, etc [11].Most commonly used protocols are DNP3 and IEC 60870-5-104. Both of them based onclient/server field bus communication but can only be implemented at station and baylevel. Furthermore, protocols operating in IEDs are able to communicate with the devicesof same manufacturer. The solution for interoperability can be achieved through protocolconverter or gateways but integration of multi vendor’s devices and interoperability amongthem created a demand of non proprietary protocol to facilitate substation communicationnetwork [21].

In 1997, IEC Technical Committee 57 (TC57) Working Groups 10, start working jointlywith Electric Power Research Institute (EPRI) to define a common international standardof substation communication and in 2003, introduce IEC 61850 communication standardfor electrical substation automation systems [23] [11].


2.8 What is IEC 61850 ?

IEC 61850 is communication standard for electrical substation automation systems. Itaddresses the major concern of interoperability issue of IEDs/devices at bay level. Bystandardising the language of communication within substation, it seamlessly integrateIEDs from different manufacturers. It is an object oriented protocol implemented over OSIor TCP/IP and Ethernet networks [22] [32] [7].

2.8.1 IEC 61850 Standard and Overview

IEC 61850 standard consists of following parts and have separate standard documents.Details of each part of IEC61850 is out of scope for research work. But list of features ofIEC 61850 parts is listed below.

2.8. What is IEC 61850 ? 15

IEC 61850-1 Introduction and overviewIEC 61850-2 GlossaryIEC 61850-3 General requirementsIEC 61850-4 System and project managementIEC 61850-5 Communication requirements for functions and device models

IEC 61850-6Configuration language for communication in electrical substa-tions related to IEDs

IEC 61850-7Basic communication structure for substation and feeder equip-ment

IEC 61850-7-1 Principles and modelsIEC 61850-7-2 Abstract Communication Service Interface (ACSI)IEC 61850-7-3 Common Data ClassesIEC 61850-7-4 Compatible logical node classes and data classes

IEC 61850-7-10Communication networks and systems in power utility automa-tion

IEC 61850-8 Specific Communication Service Mapping (SCSM)IEC 61850-8-1 Mappings to MMS (ISO/IEC9506-1 and ISO/IEC 9506-2)IEC 61850-9 Specific Communication Service Mapping (SCSM)

IEC 61850-9-1Sampled values over serial unidirectional multidrop point topoint link

IEC 61850-9-2 Sampled values over ISO/IEC 802-3

IEC 61850-9-3Precision time protocol profile for power utility automation(IEEE C37.238-2011)

IEC 61850-10 Conformance testing

Table 2.1: The IEC 61850 standard - overview and scope [15]

2.8.2 Features of IEC 61850

Main features of IEC 61850 are as follows:

Data Modeling Approach

IEC 61850 solves problem of interoperability between different IEDs from different vendor,through data modeling approach. In data modeling, IEC 61850 follows object orientedapproach. In substation, bay level device is the physical device. A physical device isa device that is connected to network and typically defined by its network address alsoknown as IED or server and it is possible that physical device may consist of one or more


servers. Furthermore, a physical device may contain one or more logical nodes. Logicalnode is the virtual component that perform particular function related to device [10]. IEC61850 has defined 91 different logical node classes and on basis of functionalities, aregrouped into 13 logical node groups, as follows.

Logical node group indicator Logical node group descriptionA Automatic ControlC Supervisor ControlG Generic Function ReferenceI Interfacing and ArchivingL System Logical NodesM Metering and MeasurementP Protection FunctionsR Protection Related FunctionsS Sensor, MonitoringT Instrument TransformerX SwitchgearY Power Transformer and Related FunctionsZ Further (Power System) Equipment

Table 2.2: List of logical node groups [32]

Thus each logical node is main building block of standard with certain services to powersystem. A logical node corresponds to data attribute and its value, as illustrated in figureFigure 2.3.

2.8. What is IEC 61850 ? 17

Physical Device

Logical Device

Logical Node Logical NodeXCBR1

LDx

IEDx

StVal q t Mag q t

MMXU1

Pos TotW

Data Object

Physical Device

Logical Device

Logical Node

Data Attribute

Figure 2.3: Data modeling approach

The hierarchy of the data model of IEC 61850 standard can be notated as

PhysicalDevice/LD/LN.Data.DataAttribute (2.1)

In short, IEC 61850 modularize the information into standard naming conventions andstructure through object oriented approach and helps to integrate different vendor’s IEDsinto power system.

Substation Configuration Language

The other feature of IEC 61850 is Substation Configuration Language (SCL), which is usedto configure SAS and IED. SCL makes easy to configure and modify SAS. It also allowsto alter structure of SAS by adding more IEDs. SCL are defined in XML format and havedifferent types of files with different purposes such as describing system and IED config-uration, capabilities, parameters, specification, communication, data flow and substationtopology [10] [14]. Furthermore, SCL also helps to exchange an IED’s communicationconfiguration information and software from different manufacturers [11].


Abstract Communication Service Interface

Abstract Communication Service Interface (ACSI) defines communication between clientand server. It describes all services available for a client. In other words, ACSI grant fullservice capabilities overview of server to the client. Furthermore, it provides interfaces forclient server communication while server could be remotely located. Additionally otherinterfaces for application to application communication devices. The type of communi-cation could be real time data access, device control, reporting and logging of events,publisher/subscriber and file transfer and many more [31] [10].

Specific Communication Service Mapping

After finalizing data model and services and configuring SAS and IEDs via SCL, all infor-mation is ready to traverse. IEC 61850 provides Specific Communication Service Mapping(SCSM) facility, where all services can be mapped to different application and data linklayer protocols. IEC 61850 maps services on already standardized protocols such as MMSand Ethernet. In this way, SCSM also leverage interoperability among IEDs.

The part IEC 61850-8-1 standard explains ACSI service mappings to MMS (ISO 9506) andmapping for Generic Object Oriented Substation Events (GOOSE) and Generic SubstationState Events (GSSE) to ethernet. The part IEC 61850-9-1 and 9-2 standard explain mappingof Sampled Values (SV) over serial unidirectional multidrop point to point link and overISO/IEC 802-3.

IEC 61850 Communication Stack

The communication service mapping of IEC 61850 has definite communication require-ments defined in IEC 61850-5. Different message types with different requirements perfor-mance class mapped to particular communication protocol as shown in Figure 2.4

2.9. What is IEC 61850 MMS 19

Data Model (Objects, Services)

Client ServerCommunication

Generic Object Oriented Substation

Event (GOOSE)

Sampled Values(SV)

Specific Communication Service Mapping (SCSM)

Ethernet Physical Layer

Ethernet Link Layer with Priority tagging

IP

TCP

MMS Real Time Communication

Abstract Communication Service Interface (ACSI)

Stack Interface

ISO/OSI Communication Stack

TCP/IPCommunication Stack

Figure 2.4: IEC 61850 communication stack

2.9 What is IEC 61850 MMS

This section demystify the mapping of different communication services and objects onMMS.

2.9.1 Manufacturing Message Specification

MMS is internationally accepted and widely adopted protocol by industrial and manufac-turing organizations. It is not concerned with how messages are traversed over network.It is basically an application layer protocol that defines rules, syntax, objects, structure ofmessages and services to control, monitor, supervise devices [25].

In smart grid, there is a huge problem of interoperability for manufacturing vendors thathow to integrate devices and how to define a common communication language standardso that devices can communicate and access services and message from each other. MMSdefines a local language translator, referred as Virtual Manufacturing Device (VMD). VMDplays role of language translator which ensure correct understanding and delivery of mes-sages among devices [25] [32].


In short, MMS is standard protocol that address interoperability issue of different vendordevices into smart grid. Thus providing benefits of flexibility of choosing different man-ufactured devices, reduced cost, product innovation, independency and interoperability[25] [7].

2.9.2 Client/Server Model

MMS architecture follows client server model. Industrial real devices such as IEDs act asa MMS server, allows MMS client to control, supervise and access the information fromthem. While here, MMS client could be application, HMI or SCADA machine at controlcenter.

VMDA VMD reside in MMS server and it is outermost object and contains other objects. Inshort, VMD provides a complete overview of server to the client through it model whichdefines following three things: [25] [32]

• Object: Object is the variable defined in server (IED). It provides the current statusof IED to client.

• Services: Service provides the mechanism to access those variables/objects. For ex-ample read,write, start stop and manipulate services to access parameters of control,operation and other defined in IED.

• Behaviour: Behaviour is the response of the server upon receipt of services fromclient.

2.9. What is IEC 61850 MMS 21

Object

Object

Object

IED

IED

IED

Services

LAN , WAN

PTP, LTE, WiMAX

VMD

MMS ServerMMS Services

MMS Client

Figure 2.5: Concept of virtual manufacturing device

Thus MMS is based on object oriented approach where object and services are used formessages formation. There are 15 MMS object classes and 80 services [25]. Following islist of major IEC 61850 objects and services mapped on MMS objects and services.


MMS Object IEC 61850 Object MMS Services

Application ProcessVMD

Server

InitiateConcludeAbortRejectCancelIdentify

Named Variable Objects Logical Nodes and Data

ReadWriteInformationReportGetVariableAccessAttributeGetNameList

Named Variable List Objects Data Sets

GetNamedVariableListAttributesGetNameListDefinedNamedVariableListDeleteNamedVariableListGetNameListReadWriteInformationReport

Journal Objects LogsReadJournalInitializeJournalGetNameList

Domain Objects Logical DevicesGetNameListGetDomainAttributesStoreDomainContents

Files Files

FileOpenFileReadObtainFileFileCloseFileDirectoryFileDelete

Table 2.3: MMS objects and services mapping [1]

Chapter 3

Analysis

The goal of this chapter is to analyze the use-case scenario adopted in this project. Thisshould provide the reader with an overview and basic understanding of LV microgrid andDERs communication scenario for energy balancing purpose.

3.1 Analysis of Scenario

To answer research questions of section 1.2, microgrid scenario has been defined. The Fig-ure 3.1 represents a microgrid comprises of local LV distribution systems with distributedenergy resources (DERs, e.g., PV on floor top and micro wind turbines) and loads. Thereis also a micro grid operation center, responsible for ensuring that all control objectiveswould meet. Figure 3.1 also represents that microgrid consists of large numbers of DERsdepending upon size of town. In proposed scenario, function of controller is to commu-nicate with each DER (e.g., PV and WT) and request for data, in order to accomplishmicrogrid control objectives.

23

24 Chapter 3. Analysis

Communication Network

PV

WT

PV

PV

LVController

Distribution Substation

Distribution Grid

Figure 3.1: Microgrid scenario

The evolving integration of RES will overall increase the percentage of electricity genera-tions. However, as shown in Figure 3.1, there are some RES whose energy production iscompletely dependent upon environmental external factor. For example PV energy gen-eration varies according to sunny or cloudy weather and similarly WT’s power profiledependent upon wind. So, RES are naturally intermittent [39]. Therefore, energy balanc-ing ensures balance between supply and demand in electrical system. Hence, an energypoint is provided by external system and LVGC make sure that reference point is followed.

3.1.1 Scenario

This project mainly focusing on energy balancing problem in LV Layer, where LVGC re-quests for energy production information from each RES and RES responds back to balancedemand and supply. The scope of project is to analyze communication between a singleWT and LVGC. Thus, LVGC implementing energy balancing, requires to get informationabout current energy production of WT so that it can direct it for possibly increase ordecrease production.

3.1. Analysis of Scenario 25

ISP CommunicationChannel

Wind Turbine

Server

LV Controller

Request

Response

Client

Figure 3.2: Client server communication in microgrid scenario

3.1.2 Abstract Model of Wind Turbine Energy Production

For client server communication, it is necessary to model required information of currentenergy production, generated by RES. As defined above in section 1.1, energy produced byWT is a stochastic process and can have multiple levels (outcomes) of production, as timeprogresses.

Markov Chain is one of the most commonly used tool for modeling stochastic processes.It is used to model WT energy production because given a state of WT energy production,the past and future states are independent of it which is the definition of Markov Property.

Suppose that process of producing power has finite number of states, i.e., S = {1,2,3,4,5,6}.If WT is in state 1, then it must jump to state 2 with transition rate of λ and from state 2to 1 with rate µ and similarly applies for all state as shown in figure, where, λ and µ areexponential distribution random variables.


1 2 3 4 5 6

Figure 3.3: Markov chain model of wind turbine energy production

3.1.3 Client Server Communication

Hence, as shown in Figure 3.4, LVGC requires to access data of current power productionfrom WT (server) periodically, known as request rate. For that purpose, controller sends arequest to server for current status of energy production. In response to the request fromclient, server sends the current state of energy level. Since, the objective of controller is tomeet energy balancing goals. Therefore, on basis of collected data, LVGC takes control de-cision of increasing and decreasing power production level by increasing the transition rateof state by value of 4, such that it can push WT in a desirable state of power production.

3.1. Analysis of Scenario 27

Client (LVGC)

Server (WT)

Request

Response

Request

Response

Action

Action

Upstream Delay

Downstream Delay

Request Rate

Figure 3.4: Sequence diagram for client server communication in microgrid scenario

In above described client server communication scenario, there are possibilities of delayand packet losses which may effect controller performance and information reliability.

chapter 4 illustrates performance requirements and challenges in more details.

IEC 61850 standard was originally developed for SA communication system. Now IEC61850 standard is also adapted for PV and WT and other DER communication network.IEC 61850 standard is adapted because it is necessary to maintain interoperability andcompatibility of communication among DGS manufactured by different vendors. So IEC61850-7-420 standard is used for communication networks and systems for power utilityautomation for DER [30] [9]. It defines basic communication structure and DER logicalnodes.


WAN

IED

Wind Turbines

IED IED

Wind Turbines

IED

PhotovoltaicPlants

PhotovoltaicPlants

IEC

61

85

0

MM

S

IEC

61

85

0

MM

S

IEC

618

50

MM

S

IEC

61

85

0

MM

S

IEC

618

50

MM

S

Low VoltageGrid Controller

Figure 3.5: Communication network for RES

Figure 3.5 represents, LVGC acting as a client machine which requires to control PVsand WTs. For integration of multi-vendor nature of DER, an IED of PV system and WTis required. Furthermore, DER’s IED builds a client server communication with LVGC,based on MMS. This project targets communication with single WT carried by Ethernetbased WAN carrier.

Chapter 4

Requirement and Challenges

This chapter describes functional and performance requirements of IEC 61850 for DERremotely controlled communication systems.

4.1 Functionality Requirements

The main objective of adopting IEC 61850 in DER is to facilitate interoperability among de-vices. Therefore, it is functional requirement that communication protocols have capabilityof supporting IEC 61850 abstract objects and service mapping [19].

As mentioned in chapter 2, IEC 61850 MMS can be mapped over TCP/IP or OSI com-munication stack. Therefore, it is necessary that communication network supports abovementioned communication profiles. Since MMS is an OSI application layer standard [25],so when it is mapped on TCP/IP stack, it is required to implement A-profile layers 1.Furthermore, as MMS is not a communication protocol, it only defines the messages tobe transported over network. For this reason, MMS needs Association Control ServiceElement (ACSE, ISO 8619/8650), Abstract Syntax Notation (ASN, ISO 8822/8823/9516),ISO 8326/8327/9548, and OSI transportation protocols to be implemented over TCP/UDPtransport layer [28] [16] [17]. The detailed information about MMS communication stackover TCP and UDP has been described in chapter 5.

1A-profile means OSI layers five to seven

29

30 Chapter 4. Requirement and Challenges

4.2 Performance Requirements

4.2.1 Transfer Time

According the IEC 61850-5 standard document, there are different performance require-ments for different types of messages. Where, performance requirements mentioned intransfer time. While IEC 61850-5 has defined transfer time as:

The time required for complete transmission of a message from sender to receiver. The time countsfrom the moment the sender puts the message on communication stack and receiver extracts datafrom its communication stack. [13]

Communication Processor

Data

Communication Processor

Data

Client Server

Transfer Time = t = ta + tb + tc

tbta tc

Figure 4.1: Definition of transfer time

In this research, the time ta and tc is not noticeable because this project is only modellingthe IEC 61850 MMS, so necessary communication processing, e.g. encoding and decodingis not required. Here Transfer time t is only dependent upon network delay tb.

4.2.2 Message Performance Requirements

IEC 61850 defines different messages types and each message has different transfer timerequirement [13]. The list and details of those message type are out of scope for thisresearch work. But this research focuses on the remote control communication in micro-grids, as described in subsection 3.1.1, for demand and response application. Thus, requestand response messages between LVGC and DER falls under type 2 and type 3 messages,describe as follows [13]:

4.3. Challenges 31

• Type 2 : These are medium speed messages. For these kinds of messages, mes-sage origination time is important but transmission time is less critical. The totaltransmission time for type 2 messages shall be less than 100 ms.

• Type 3 : These are low speed messages, used for slow speed auto control functions,transmission of event records, reading and changing set points values. The totaltransmission time for type 2 messages shall be less than 500 ms.

4.3 Challenges

There are number of challenges in controlling RER by remote controller(LVGC) such aslatency, quality of service, scalability, reliability and security [22][19]. But the researchfocuses on those network challenges which is mostly related to transportation of controlmessages over a communication network such as latency, reliability, packet losses, networkunavailability.

4.3.1 Latency

Latency plays an important role in communication system especially when it is required toaccess remote information timely. In this research, Latency is the amount of time requiredby a message to reach from source to destination and it is caused by ethernet WAN cloudnetwork delay, at layer 3.

Latency Network delayCaused by

Figure 4.2: Definition of latency

Since, this research focuses an ISP cloud network as a communication medium. There-fore, the amount of background traffic may impact latency of client server communication.Thus receiving a delayed message may affect reliability of information. If the informationreceived at requester side is obsolete according to the current true value at sender then italso lead inaccurate functioning of controller and effects efficiency of it. Therefore, one ofthe task of thesis is to analyse the impact of network delay on MMS model of TCP andUDP in terms of data reliability and controller performance.


4.3.2 Packet Losses

Packet losses occur when one or more data packets fail to reach their destination. Packetloss is typically caused by various factors such as link errors, traffic re-routing, networkcongestion etc. In this work, it is random network error that causes packet losses.

Packet losses Network link errorCaused by

Figure 4.3: Definition of packet losses

It is also important to analyse, how packet losses effects MMS model for both TCP andUDP. The nature of TCP and UDP has made this case interesting to analyse because, TCPis a complex protocol and works on mechanism of acknowledgement. If hypothesis ofpacket losses is made, then packet will have to be retransmitted with data value whichmay no longer is true. While in case of UDP, packet loss should have no huge impacton data reliability (mismatch probability) as compare to TCP, depending upon the requestrate of client. For example, if client requesting for data very frequently then packet lossshould have less impact on controller performance and mmPr.

4.3.3 Network Failure Detection and Recovery time

Connection failure detection is critical in the connection oriented protocol such as TCP. Thequicker the failure is detected the faster is the resumption of client-server communication.Furthermore MMS requires two handshakes. First for transport layer level and second forMMS association. On the other hand UDP traffic is connection-less which is a best efforttraffic and thus do not require reconnection. Due to the nature of TCP, it is critical todetect the loss connection as early as possible otherwise the controller could not be ableto command wind turbine promptly and there will be a loss of precious cycle and thusquality of controller can be degraded.

Transport layer connection lost

Network unavailability

Caused by

Figure 4.4: Definition of connection lost detection and recovery time

4.3. Challenges 33

Here, connection lost and recovery has been associated with network unavailability sce-nario. For example, there are certain extraordinary conditions: fibre link outage, networknode failure, security patch upgrade in router, planned and unplanned electricity out-age, hardware and software upgrade [27], which makes network unavailable. Hence, itis appealing to inspect MMS model behaviour for mmPr and controller performance inconnection lost and recovery scenario.

4.3.4 Reliability

Data reliability is measure of information correctness, means data has to be up-to-dateall time. This project uses concept of Mismatch Probability (mmPr) to validate the datareliability, where mmPr is define as the probability that any Nth information element ofserver, requested by client does not match with the current true value at server. This canhappen, if latency to reach the information from sever to client increases and mean whileserver information get change and which makes the received information at client obsolete,as described in Figure 4.5.

Si Si+1 Si+2

MMS Client

MMS Server

Rk Rk+1

Time

Time

Figure 4.5: Request Rk receiving a correct information of state, while Rk+1 a mismatch information[4]

The defined scenario, subsection 3.1.1, uses the on demand access of information, alsoknown as reactive approach. In this approach, whenever client needs an information, itsends request message to server, which responds by sending the message with informationvalue.

4.3.5 Controller Performance

The one of research question is to measure the quality of LVGC performance. The objectiveof LVGC is to control the power production of WT in desirable state and for this purpose,


it is highly dependent upon latency, packet losses and network availability. Because, lostand obsolete information may lead to poor quality of controller performance.

The objective of project is to analyse above defined challenges, while modeling IEC 61850MMS for remote control of RES in LV grid.

Chapter 5

Specification and Design

This chapter describes the technical specification of modeling IEC 61850 MMS over UDPand TCP, through ethernet based WAN carrier, for remote control of DER in LV grid. It alsocovers the modeling and design of wind turbine power production levels as continuousmarkov model.

5.1 Technical Specification

The overall architecture of controller and DER communication is shown in Figure 3.2. Inthis section based on the requirements of IEC 61850 MMS communication, the technicalspecification for LVGC (MMS client) and WT (MMS server) is discussed. The details abouttechnical specification has been presented according to MoSCoW model [36].

The model design principles are:

• Must have: requirements that system must have to function properly.

• Should have: requirements that should be done but not necessary for this researchwork.

• Could have: are nice to have requirements.

Figure 5.1, represents WT and LVGC with IEC 61850 and network communication module.

35

36 Chapter 5. Specification and Design

ISP Cloud Module

IEC 61850 LN for Smart Meter

Communication

Network Communication

Module

IEC 61850 Module for Smart Meter Communication

Network Communication

Module

IEC 61850 MMS Model over TCP and UDP

Client Server

Low Voltage Grid Controller

Wind Turbine

Figure 5.1: Technical specification of scenario

5.1.1 Controller (MMS Client)

The controller should have IEC 61850 MMS communication stack to communicate with thewind turbine, as MMS client. It should have IEC 61850 module for smart meter communi-cation.

• MMS client should send request message to establish Connection Oriented TransportProtocol (COTP) and Connection Less Transport Protocol (CLTP) connection with theMMS server.

• After COTP and CTLP connection establish, MMS client should send request mes-sage to establish MMS application association with the MMS Server.

• Controller must send request message over TCP/UDP, to pull information about theelectric energy produced by the Wind Turbine.

• Controller must send message to perform desired action on MMS server.

5.1.2 Wind Turbine (MMS Server)

The wind turbine should have IEC 61850 MMS communication stack to communicate withthe controller, as MMS server. It should also have IEC 61850 Logical Node (LN) for smartmeter communication.

• MMS server should send response message to establish COTP and CLTP connectionwith the client.

5.2. Technical design of Scenario 37

• After Client association request, MMS server should send response message to es-tablish MMS application association with the MMS client.

• In response to MMS client request, MMS server must send response message withthe energy state level over TCP/UDP.

• In response to MMS client action message, MMS server must follow instruction ofclient.

5.1.3 ISP Cloud Module

MMS Client and Server must communicate through ISP cloud module based on ethernet,which will route traffic between them.

5.2 Technical design of Scenario

5.2.1 Modeling of IEC 61850 MMS Protocol through TCP and UDP

IEC 61850 MMS was originally designed for OSI networking model but since TCP/IPwas never replaced by OSI [8]. So MMS is eventually mapped over the TCP/IP. For thatpurpose interconnecting layer is used between TCP/IP T-profile 1 and OSI A-profile 2

layers [8].

This research models the MMS over TCP/IP and following Figure 5.2 represents the pro-tocols layers of MMS over TCP and UDP.

1T-profile means TCP/IP layers one to four2A-profile means OSI layers five to seven


MMS

A-Unit DATA

CL Presentation / ISO 9576

CL Session / ISO 9548

OSI Transportation / RFC 1240

ACSE

CO Presentation / ISO 8823

CO Session / ISO 8327

OSI Transportation / RFC 1006

UDP TCP

IP

Ethernet Link Layer

Ethernet Physical Layer

Figure 5.2: The protocol layers of MMS over TCP and UDP

Although details about each protocol layer is out of scope but it has been described brieflybelow.

• OSI Application Layer: MMS services are part of application layer and MMS Clientuses those service for interaction with MMS server for specific functions such asreading and writing variables [22]. Association Control Service Element (ACSE) alsolies in application layer and it is used to establish and release Application Associ-ations (AA) between Application Entity (AE) [28]. It also supports two modes ofcommunication service: Connection-Oriented (CO) and Connection-Less (CL).

• OSI Presentation Layer ( ASN.1 and BER): This layers makes sure that presentationdata is preserved during transfer. It negotiate for transfer syntax and transform theapplication layer abstract syntax into transfer syntax. MMS uses Abstract SyntaxNotation (ASN).1 at presentation layer and Basic Encoding Rules (BER) is encodingrules specified by ASN.1 standard [28]. It supports both CO and CL presentationservices, specified by ISO 8823 and ISO 9576.

• OSI Session Layer: Session layers provides the mechanism of opening, establish-ing, managing and termination of connection between two end user applicationprocesses. CO session protocol is specified by ISO 8327 while CL session protocolspecified by ISO 9548.

• OSI Transportation Layer: This layer helps to mapped the OSI layer over TCP/IPand it is a protocol extension for TCP and UDP protocol. RFC 1006 describes ISOtransport services on top of TCP and RFC 1240 is used on top of UDP.

Before sending MMS request by client, It should establish an MMS association with MMS


server. Foremost, It should establish connection on the transport layer. In case of CLmode, it does not require handshake at transport layer and should make connectionlessMMS association that simultaneously establishes and releases an association. Since themain focus of this research work is to analyse the impact of network delay and packetlosses on quality of LVGC performance and reliability of MMS server information. Thus,it has been assumed that both OSI and MMS layers handshakes is already established. Thearea of study only focuses on main MMS request and response operation between MMSserver and client.

MMS protocol data unit for request, response and action over TCP and UDP can be calcu-lated according following formulae: [8] [16] [17]

MMS Request/Response PDU size over TCP= RFC 1006 and ISO 8073 + ISO 8327 Session + ISO 8823 Presentation + MMS UserInforma-tionPDU= 7 + 4 + 9 + User Information field

MMS Request/Response PDU size over UDP= RFC 1240 and ISO 8602 + ISO 9548 Session + ISO 9576 Presentation + MMS UserInforma-tionPDU= 7 + 1+16 +16+ User Information field

Thus each time, a MMS request response message is sent with overhead of 20 bytes (ap-prox) for TCP and 40 bytes (approx) for UDP on top of user information field, as calculatedabove. Here, User information field is the data that need to be send and receive betweenclient and server.

5.2.2 Modeling of MMS Server

As explained in subsection 3.1.2, amount of power generated by WT has been model byContinuous markov chain. For simplicity, a countable state space S ⊂ { 1,2,3,4,5,6 } hasbeen assumed which represents the amount of power generated, as follows

State Space1: 0-1 KW2: 1-2 KW3: 2-3 KW4: 3-4 KW5: 4-5 KW6: 5-6 KW


Following Figure 5.3 represent state transition rate diagram, where λ and µ is exponentialrandom variable with mean value 1. Where each transition rate is different exponentialrandom variable.

1 2 3 4 5 6

Figure 5.3: State transition diagram with transition rate λ and µ

The Markov chain is mathematically described by the generator matrix, seen in

Figure 5.4: Generator matrix

Furthermore, assuming that the system is at state i. Transition probability that the nextstate transition will be to state j, can be calculated as follows

Pi j = λi j/(λi j + µi i−1) (5.1)

It is also assumed that system remain in each state until its Mean Holding Time (MHT)expires, where MHT is defined as time spend by system in a state, calculated as follows:

MHT = 1/(λ + µ) (5.2)

In start, at time t = 0, initial probability is Po = [1,0,0,0,0,0]. It is the probability that systemis in state S = 1 at time 0 and remain is state "1" until its MHT expires. After that serverjumps to state "2" and remain till MHT expiration. Further on, Server moves to next state,back or forth decided by a random number generator. If random number is greater thanthe probability of moving forward then system jumps forward else jumps to previous state.


A same seed number is selected in order to generate similar set of random values so thatTCP and UDP can be compared on same baseline.

5.2.3 Modeling of MMS Client

LVGC act as a MMS Client and its responsibility is to control the power production of WT.Here, it has been assumed that current demand of power is to keep WT in state 3 or state4.

The controller has been designed such that it can speed up or down the process of powergeneration. For example, if WT is in state below 3 then it can increase the transition ratewith value of 4. As result, state transition rate will look like as follows in Figure 5.5

1 2 3 4 5 6

Figure 5.5: State transition diagram with rate λ + 4 in forward direction

Similarly, if WT is in state above 4 then it increase the transition rate in backward directionwith same value of 4, shown in Figure 5.6

1 2 3 4 5 6

Figure 5.6: State transition diagram with rate µ + 4 in backward direction

Measurement of Quality of Controller Performance

One of the objective of research work is to evaluate the quality of controller performancefor different network conditions. Since the function of controller is to keep wind turbinein desirable state. Thus the quality of controller performance is measured using followingformula.


QoC =πi

Ttotal(5.3)

where,QoC = Quality of Controller Performanceπi = Steady state probability of being in State ’i’Ttotal = Total time used observing the system

As, here it has been assume that desirable states of server are 3 and 4. Thus, QoC formulabecomes

QoC =π3

Ttotal+

π4

Ttotal(5.4)

where:π3 = Steady state probability of being in State ’3’π4 = Steady state probability of being in State ’4’

Chapter 6

Implementation using ns-3 Simula-tion Platform

This chapter explains over all implementation of IEC 61850 MMS model over TCP andUDP, designed to analyse the impact of network performance for remote access to dynam-ically changing information elements of MMS server. It also discuss the implementation ofMMS Client and MMS server in NS3 simulation platform.

6.1 IEC 61850 MMS Model over UDP

The MMS model designed for MMS client server communication are based on the technicalspecification and design that have been described in chapter 5. The overall details of MMScommunication stack for UDP and TCP is already shown in Figure 5.2. The model hasbeen designed in such a manner that it focuses on MMS request and response implemen-tation, assuming that MMS association for connection-oriented services has already beenestablished. To achieve, the goal of implementation, the size of MMS PDU for request andresponse has been calculated through literature study, illustrated in subsection 5.2.1. MMSPDU of 40 bytes with 12 bytes of user information field is mapped over TCP/IP stack forMMS communication, by developing following modules.

43

44 Chapter 6. Implementation using ns-3 Simulation Platform

MainwithUDP.cc request-response-helper.h

request-response-server.cc[HandleRead()]

[SetState()]

request-response-client.cc[SetFill()]

[HandleRead()]

create obj.client

and server

create obj.server

create obj.client

ISP cloud

udp-echo-helper.h

Derived from

Figure 6.1: Implementation of IEC 61850 MMS model over UDP in ns-3

6.1.1 MainwithUDP module

MainwithUDP is the main module responsible to construct the network topology alongwith major objective to create and run UDP request response service for MMS communica-tion. It also governs duration of simulation. This module also defines the other importantsimulation parameter such as, network delay, request rate and ISP cloud bandwidth.

6.1.2 Request-response-server module

This is the module where MMS server model implementation is carried out. It is composedof two major functions.

• HandleRead(): As by its name, this function is responsible to read the request andaction message received from MMS client and parse it for response and action pur-poses.

• SetState(): This function contains the brain functionality of MMS server, shown inFigure 6.2.

MMS Server implementation

From sequence and flow chat Figure 6.2 MMS server implementation can be easily under-stand. After receiving request message from client, server response back with its currentstate. As a result, server performs the action, generated by the client. There are three pos-

6.1. IEC 61850 MMS Model over UDP 45

sible action that could be performed either ramp up states in forward/backward directionor follow existing pattern of transition.

Receieve MMS Request

Send MMS Response

MMS Client (Controller)

ISP CloudMMS Server

(Wind Turbine)

MMS Request

MMS Response

MMS Action

Current State

Perform MMS Action

If Action

Continue using current

Generator Matrix

Use Qdown Generator Matrix

Use Qup Generator Matrix

OK

Increase: λ = λ + Increase: μ = μ +

Figure 6.2: MMS server implementation

6.1.3 Request-response-client module

This is MMS client module composed of two major functions.

• SetFill(): This function create response and action message. It coded the brain func-tionality of MMS client, shown in diagram Figure 6.3

• HandleRead(): As by its name, this function is responsible to read the responsemessage received from MMS server and parse it to create action plan.

MMS Client implementation

The job of the client as a controller to keep server in desirable state and for that purpose itsignals the server for drift up in required direction, explained through Figure 6.3.

46 Chapter 6. Implementation using ns-3 Simulation Platform

Send MMS Request

Read MMS Response

If State

OK Increase: μ = μ + Increase: λ = λ +

Send above respective MMS Action

MMS Client (Controller)

ISP CloudMMS Server

(Wind Turbine)

MMS Request

= 3 or 4

<3 >4

MMS Response

MMS Action

Figure 6.3: MMS client implementation

6.1.4 Request-response-helper module

This module is used to initialize all variables and methods.

6.2 IEC 61850 MMS Model over TCP

MMS model has been designed in same manner except that MMS PDU of 20 bytes with 12bytes of user information field is mapped over TCP.

6.2. IEC 61850 MMS Model over TCP 47

MainwithTCP.cc

MMS-packet-sink.cc[HandleRead()]

[SetState()]

TCP-request-response-client.cc[SetFill()]

[SetState()]

create obj.client

ISP cloud

MMS-packet-sink-helper.cc

TCP-request-response.cc

Packet-sink-helper.cc

derived from

create obj.server

Figure 6.4: Implementation of IEC 61850 MMS model over TCP in ns-3

6.2.1 MainwithTCP module

It has same functionalities as subsection 6.1.1, but it create TCP request and responseservices for MMS communication.

6.2.2 MMS-packet-sink module

MMS server model for TCP has been designed in this module. It also has the same majorfunctions described in subsection 6.1.2.

6.2.3 TCP-request-response-client

This module coded for MMS client model for TCP. Again, it provides the same servicementioned in subsection 6.1.2.

6.2.4 MMS-packet-sink and TCP-request-response helper module

This module is used to initialize all variables and methods, used in MMS model of TCP.

Chapter 7

Experiments and Evaluation

This critical chapter will analyze the results found during the execution of testing.

7.1 Test Strategy

In order to answer research questions define in section 1.2, test cases are classified intothree main groups. Test groups are based on network performance parameters of packetdelay, transport layer connection lost and packet losses Table 7.1.

Test case no. Description of test case

Test 1: Network delayAssess mmPr & controller performance ofMMS model over TCP and UDP for differentpacket delay

Test 2: Network unavailabilityAssess mmPr & controller performance ofMMS model over TCP and UDP in case of net-work unavailability

Test 3: Network link errorAssess mmPr and controller performance ofMMS model over TCP and UDP for packetlosses

Table 7.1: Test cases

The test were performed by generating 10,000 MMS requests both for TCP and UDP, witha request rate of 1 packet per second (10000 requests). The reason of selecting such a high

49

50 Chapter 7. Experiments and Evaluation

number of requests is two fold. First it is to minimize the likelihood of biased results dueto the random number generator, see subsection 5.2.2. Secondly the value is selected tounderstand the behaviour of wind turbine over a longer period of time (over 2.5 hours).During this extensive testing, there are about 60 pairs of csv files collected for both TCPand UDP. These csv files are then analyzed with the help of tool developed in Matlab(see, Appendix B), in order to understand the impact of network performance parameters(discussed in section 4.3) on:

• Data reliability (mmPr)

• Quality of controller performance

• Performance of MMS communication over TCP and UDP

Through NS3 simulation, defined in chapter 6, MMS traffic were generated over TCP andUDP as an underlying protocol. The traffic is sent between controller and wind turbineand all test cases are executed for different network conditions.

7.2 Assumptions

Before going into details of test description and results, it is necessary to understand theassumptions, made in this project.

• It has been assumed that controller can not interrupt a state of server, until MHT ofthat state get expired. In other words, if server has already committed for a statethen server will remain in that state till its MHT and afterwords follows the actionof controller.

• It has been assumed that both OSI and MMS layers handshakes are already estab-lished. The area of study only focuses on main MMS request and response operationbetween MMS server and client. Because main focus of this research work is to anal-yse the impact of network delay and packet losses on quality of LVGC performanceand reliability of MMS server information.

7.3 Values of Simulation Parameters

The scenario and MMS client and server model considered for this project has many pa-rameters. Different values of those parameters can lead to multiple test cases and diversityin research work. But due to time constraint, values of different parameter are assumed tobe constant.

7.3. Values of Simulation Parameters 51

State transition rate:State transition rate in forward direction is represented by λ while µ represents transitionrate in backward direction. It is calculated as a exponential random variable with meanvalue of 1. The mean value of exponential random represents server mean waiting time toenter into an other state. It has been chosen so that state of wind turbine can be analyzedevery second.Additionally, for purpose of wind turbine energy production modeling as a continuousmarkov random process, all values of λ and µ are kept different, shown in Figure 7.1. It ispossible to keep all values of λ same and all values of µ. But to model the wind fluctuationand variation, they are kept different.

1 2 3 4 5 6

= 0.63 = 0.30 = 0.02 = 0.01 = 0.91

= 0.43 = 0.97 = 0.11 = 0.36 = 0.21

Figure 7.1: State transition diagram with transition rate λ and µ (along their values)

Upon intervention of controller, state transition rate will drift up with constant rate ofvalue 4 = 0.5, expressed through Figure 7.2 and Figure 7.3.

1 2 3 4 5 6

Where = 0.5

Figure 7.2: State transition diagram with constant drift rate 4 in forward direction

1 2 3 4 5 6

Where = 0.5

Figure 7.3: State transition diagram with constant drift rate 4 in backward direction


Here, 4 is used to increase the transition rate so that server can reach to desirable statequickly. It is still a research question that what should be optimum value of 4 (see sec-tion 8.2). It could be kept different from 0 to 1, in order to identify its optimal value. Butdue to time bondage, simulations are run for a constant drift value and a mid point valueof 0.5 has been selected.

Request rate:Rate of sending MMS request is set to be 1 request per second. Here, it is also possible torun simulation under different request rate value, to investigate the impact of request rateon mmPr and controller efficiency but simulation has been run with a constant value, toaccomplish the project work on time. The reason of selecting 1 request per sec is that themean holding time of state is selected in seconds (subsection A.3.2 and subsection A.2.2)where the minimum duration for wind turbine to reach from state 1 to state 6 is 9 sec. Andminimum stay time on single state is 0.56 sec which means with the lower value of requestrate, the controller would possibly missed the turbine on one of the state. Therefore alower value could affect controller function. Second reason of choosing request rate equalsto 1 is that since transition rate considered in this project work is an exponential randomvariable with mean value of 1 which means server takes mean value of 1 sec to switch fromone state to another.

Desirable state of server:From controller perspective, desirable state of server is always 3 and 4. Again, it has beenassumed that current demand of energy production requires wind turbine to be remain instate 3 and 4 production level at most of time. Although, it is possible that desirable statechanges according to reference point of energy requirement and practiced by the controller(see section 8.3). But since the focus of the project is to analyse network performanceparameter on MMS IEC 61850 model running on TCP and UDP, thus desirable state hasbeen restricted to 3 and 4.

The list of parameters and their values are also shown in Table 7.2

7.4. Network Topology 53

Notation of Parameter Description Valueλ State transition rate in

forward directionλ12=0.63, λ23=0.30,λ34=0.02, λ45=0.01,λ56=0.91

µ State transition rate inbackward direction

µ65=0.21, µ54=0.36,µ43=0.11, µ32=0.97,µ21=0.43

Request rate MMS client request rateto query about serverstate

1

4 Drift rate to increasestate transition rate inforward and backwarddirection

0.5

S Number of states 6Desirable state Desirable state from con-

troller perspective3 and 4

Table 7.2: List of parameter and their constant values

7.4 Network Topology

To carry out the test execution a network topology is required. In this experiment, the goalis to investigate the network evaluation performance for MMS IEC 61850 remote controlcommunication. In order to achieve this goal, an ethernet cloud (WAN) is considered.Here an explanation of physical topology design and simulation is described. To simulatescenario, channel bandwidth is configured to 10Mbps for MMS communication betweencontroller and wind turbine. For now, it has been assumed it is a non shared medium.


MMS ServerMMS Client

IEC 61850 MMS communication over TCP and UDP

Low Voltage Grid Controller

Wind TurbineISP Cloud of 10Mbps

10.1.1.0 10.1.3.0.1.1

.2 .2

Default link Default link

Figure 7.4: Network topology

7.5 Simulation Experiments

The experiments are conducted in ns-3 simulation environment with the modules designedand implemented as shown in subsubsection 6.1.3 and subsubsection 6.1.2. The samemarkov chain model of MMS server has been used for all test cases.The main objective of the experiments is to verify the performance of the IEC 61850 MMSmodel over TCP and UDP under different network conditions (such as network delay, errorand unavailability) and assess information reliability and performance of LV controller, tosupport remote control communication in distributed microgrid. To achieve the goal ofproject work, MMS traffic is passed through simulated ISP cloud network with a fixed rateof 1sec and following test cases has been executed separately.

7.5.1 Test Case 1: Network delay

Description

First case scenario is executed under packet delay conditions, means that different networkdelays are introduced on ISP cloud. Each time with different delay values, 10,000 MMSrequests packets are sent from MMS client to MMS server through non share communica-tion medium with 0% packet losses for a period of 10,000 seconds. Means, at every second,a MMS request is send from client to server to perform control action based on receivedinformation.

Packet delay as defined in subsection 4.3.1 and subsection 4.2.1. For the purpose of testing,packet delay of different values has been selected so that it can be mapped on networkdelay (latency) of different communication technologies, as listed in Table 7.3.

7.5. Simulation Experiments 55

Communication Technologies Latency (msec)DSL or cable Internet connections 25-100 approx[18]Satellite internet connection >= 500 approx[18]LTE 75-250 approx[3]WiMAX 6.15 approx[34]

Table 7.3: Latency measurement for different communication technologies

After test execution, following results are obtained.

Results

Figure 7.5, shows the assessment of mmPr for MMS model over TCP and UDP based onnetwork delays.

0 50 100 150 200 250 300 350 400 450 500Network delay in msec

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

Mis

mat

ch P

roba

bilit

y

mmPr vs Network delay

mmPr for MMS model over TCPmmPr for MMS model over UDP

Figure 7.5: Assess mmPr for different network delays

Figure 7.6, shows the quality of controller performance for same model.


0 50 100 150 200 250 300 350 400 450 500Nework delay in msec

0.44

0.45

0.46

0.47

0.48

0.49

0.5

0.51

0.52

0.53

0.54

Qua

lity

of c

ontr

olle

r pe

rfor

man

ce

Quality of controller performance vs Network delay

Quality of controller performance for MMS model over TCPQuality of controller performance for MMS model over UDP

Figure 7.6: Quality of controller performance for different network delays

Confidence Interval

In this experiment, 95% of confidence interval is used, calculated through Adjusted Waldtechnique [24]. It helps to provide faith on simulation readings. Figure 7.7 provides themost likely range of values if simulations is run for more longer period of time.


Figure 7.7: Confidence interval for mmPr vs Network delay

Rationale

It has been observed from Figure 7.5, the mmPr increases when the latency increases, forTCP and UDP communication. The reason for this is that response message arrives withhigher delay then there are high chances that current state of server may have alreadymove to next state and while the message about server state become obsolete which causesa miss information.

On the other hand, it has been analysed that the impact of latency found to be samefor MMS over TCP and UDP data reliability. It is quite expected result because undernormal conditions of network, TCP and UDP performance are same. TCP only differ thatit requires two handshakes one on the transport layer and one for the MMS applicationlayer, before starting MMS data exchange [19].

Before discussing the results of Figure 7.6, it is necessary to mention that quality of con-troller performance has been calculated using formula defined in subsubsection 5.2.3. Butquality of controller could not be analysed independently. Because it is highly dependentupon amount of time server spends in desirable state naturally. In easy words, due tonature of MMS server continuous markov chain model, even in the absence of controller,server still spend some amount of time in state 3 or 4. Thus first it is necessary to calculatethe percentage of time, server stays in state 3 and 4 when there is no control from MMSclient (controller). It has been recorded 30% to 40% of time server remains in desirable


state 3 and 4, normally.

Based on above defined baseline of controller performance, it has been observed that con-troller performance is increased from [30%-40%] to 53% in start. Response packet delaymay lead to mismatch information to controller which causes to proceed a wrong deci-sion. Thus quality degraded to 45% approximately. Furthermore, test results shows thatbehaviour of controller performance remain same for TCP and UDP because of their samebehaviour.

7.5.2 Test Case 2: Network unavailability

Description

This test case has been carried out to inspect the impact of network unavailability whichcauses transport layer connection lost. Test has been run for two different connection losttime duration. First one for 2 sec time duration and second for 10sec, while connectionis lost after every 2000sec. Thus, number of connection lost is count to be 5. Along this,test is also performed for 10,000 seconds with different latency as done for subsection 7.5.1with 0% packet losses , such that test results can be compared with the results of previoussubsection 7.5.1.

This test case has been designed to evaluate the impact of network loss on communicationof MMS model over TCP and UDP.

Results

Results for mmPr as shown below.


10 20 30 40 50 60 70 80 90 100Network delay in msec

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1M

ism

atch

pro

babi

lity

mmPr for network unavailability of 2sec


Figure 7.8: Assess mmPr with network unavailability of 2 sec for 5 times


10 20 30 40 50 60 70 80 90 100Network delay in msec

0.01

0.02

0.03

0.04

0.05

0.06

0.07

0.08

0.09

0.1

Mis

mat

ch p

roba

bilit

y

mmPr for network unavailability of 10sec


Figure 7.9: Assess mmPr with network unavailability of 10 sec for 5 times

Results for controller performance are placed below.



0.44

0.45

0.46

0.47

0.48

0.49

0.5

0.51

0.52

0.53

0.54Q

ualit

y of

con

trol

ler

perf

orm

ance

Quality of controller performance for network unavailability of 2sec


Figure 7.10: Quality of controller performance with 5 TCP connection losses for 2 sec



0.45

0.46

0.47

0.48

0.49

0.5

0.51

0.52

0.53

0.54

Qua

lity

of c

ontr

olle

r pe

rfor

man

ce

Quality of controller performance for network unavailability of 10sec


Figure 7.11: Quality of controller performance with 5 TCP connection losses for 10 sec

Confidence Interval

In this experiment, 95% confidence interval is used. It has almost same range of values asFigure 7.7.

Rationale

The results Figure 7.8 shows that there is no such impact of connection lost for 2sec dura-tion on mmPr even for TCP because 2 sec of connection lost is considered as controller isabsent for 2 sec. If there is no controller means there is no request from controller so nochance of mismatch information. Similarly, the same result are obtained for 10sec duration,Figure 7.9.

It can be observe from graph Figure 7.10, controller is not effected by such short durationof absence for 2*5= 10sec from 10,000 sec duration which is very less amount in compareto 10,000. Thus, soon network becomes available, controller is able to perform normally.

Furthermore, delimitation of controller operation assumed in section 7.2 that controller can


not interrupt the server if server has already committed for a state which also has a majorimpact on controller performance.

But as connection lost time increases to 10sec, controller performance start degrading grad-ually, in comparison to Figure 7.10, shown in Figure 7.11.

Although the controller performance for TCP and UDP are same because both behaveexactly same for different network delays and 0 packet losses, discussed in subsubsec-tion 7.5.1

7.5.3 Test Case 3: Network link error

Description

In order to evaluate the impact of packet loss on MMS model, a range of network error hasbeen introduce in the ISP cloud (ranges from 0.001 to 0.05). The more the error the more thepacket losses and hence effect the mismatch probability and the controller performance.The idea is to understand the behaviour of MMS model running on UDP and TCP. Lost ofpacket in UDP traffic would cause a loss of client request or loss of Server response. Onthe other hand TCP traffic is connection-oriented where lost packet is retransmitted.

Results

Below are the results obtained for test case 3.


0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Percentage of network link error rate

0.005

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

0.055

Mis

mat

ch p

roba

bilit

y

mmPr vs Network link error

mmPr for MMS Model over TCPmmPr for MMS Model over UDP

Figure 7.12: Assess mmPr for different network link error

0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5Percentage of network link error rate

0.49

0.495

0.5

0.505

0.51

0.515

0.52

0.525

0.53

0.535

Qua

lity

of c

ontr

olle

r pe

rfor

man

ce

Quality of controller performance vs Network link error rate


Figure 7.13: Quality of controller performance for different link error

Below Table 7.4 also represents the percentage of packet losses verses link error rate.


Link error rate % of TCP packet losses % of UDP packet losses0.001 0.71 0.190.002 1.66 0.350.003 2.57 0.640.004 3.3 0.80.005 3.74 1.050.006 4.22 1.230.007 5.15 1.390.008 5.87 1.570.009 6.46 1.650.01 7.07 1.870.02 13.5 3.790.03 20.2 5.980.04 26.74 7.760.05 31.9 9.92

Table 7.4: Percentage of packet losses

Confidence Interval

In this experiment, 95% of confidence interval is used, calculated through Adjusted Waldtechnique [24].


Figure 7.14: Confidence interval for mmPr vs Network link error

Rationale

The Figure 7.12, shows that increment in packet losses causes increment in mmPr bothfor UDP and TCP. In case of TCP, each time a packet is lost, retransmission is taken placewhich causes delay in response packet. Thus retransmitted response packet carrying theinformation may become out-of-date, causing mismatch of server state information.

While in case of UDP, packet losses has no significant impact on mmPr by virtue of UDPwhich does not support guaranteed delivery. If any request or respond packet is lostduring transmission, the next request message can recompense the job of getting latestinformation, as observed in Figure 7.12.

It is also important to note that percentage of packet losses is higher for TCP than UDPsimply because, TCP have more number of packets for request responses due to acknowl-edgement mechanism.

Now analyzing the quality of controller performance. In case of TCP, it has been observedthat there is a trade-off between packet losses and performance of controller. As packet isget lost, controller is not able to make action and furthermore in case of retransmission ofresponse packet with mismatch information may lead to wrong decision, exploit controllerquality which can be seen through Figure 7.13.


In this experiment of UDP, effect of packet losses on controller performance is differentfrom TCP. The reason of almost constant performance is highly dependent upon MMSclient request rate. As request rate is set to value of 1 request per second thus it is obviousthat performance does not suffer poorly.

Chapter 8

Conclusion and Future Work

The project work has been conducted by combination of literature and simulation basedresearch to answer the main research question:

How can network performance be effected on remote control communication to Distributed EnergySources (DER), while modelling IEC 61850 MMS as an application layer protocol.

During thesis work, many tasks are performed to analyse the impact of network delay,unavailability and packet losses on designed IEC 61850 MMS model over TCP and UDP.Important observations are discovered during the course of thesis which are listed in sec-tion 8.1. Last section put some light on the future work.

8.1 Conclusion

Following conclusion are made on basis of designed IEC 61850 MMS model illustrated inchapter 5 for TCP and UDP.

• In this thesis work, a simulation based model for IEC 61850 MMS has been estab-lished, in order to provide an experimental study for assessing reliable balancingpower in the low voltage microgrid over different communication technologies, tocompensate imbalance of consumption and generation.

• This research work introduces a way to measure quality of controller performancein the interest of balancing energy generation and consumption.

• One of the focal point in this thesis is to understand the behaviour of mmPr withthe injection of MMS traffic over TCP and UDP across simulated ISP cloud network.

69

70 Chapter 8. Conclusion and Future Work

ISP cloud provided with different network delay, has significant impact on mmPr,which enables to conclude that increment in network delay increases the mmPr.

• Experimental results also revealed that under normal conditions of 0% packet lossesand network unavailability conditions, mmPr for MMS model over TCP and UDPgives more or less same results with slight differences. The slight difference is no-ticed because TCP requires additional steps of transport layer and MMS associationhandshakes in comparison to UDP.

• Theoretically, quality of controller performance has a trade off with mmPr, networkdelay and unavailability. It has been proven to be correct. But quality controller isalso dependent upon its design. Here, there is a limitation in controller functional-ity that it can not interrupt the server for a already committed job which also hassignificant impact on achieved results.

• It was also observed that packet loss has heavy impact on MMS model for TCP ascompare to UDP. mmPr for TCP is higher than UDP mmPr. On the other hand,retransmission of lost packets in TCP brings no good for controller performance.While in UDP packet loss has not effected the controller performance which is alsodue to appointed request rate of 1 sec. If rate of sending request is reduced, con-troller performance may also effected in case of UDP too.

• For designed IEC 61850 MMS model, TCP and UDP has no dominance on eachother under different network delays. While in case of network unavailability, eachtime network is restored, TCP requires extra steps for handshaking in comparisonto UDP. But in case of packet loss scenario, UDP is the best choice over TCP.

8.2 Recommendations

This section highlights the recommendations.

• It is recommended that controller should have the ability to interrupt already com-mitted task of server (wind turbine) so that server can follow controller instructionimmediately.

• In order to achieve the best controller performance, It is also recommended to findthe optimal drift rate of transiting state from one state to another. For that purpose,number of test cases can be run with different values of 4 to find the relationship ofboth entities.

8.3 Future Work

This section provides directions for future potential work.

8.3. Future Work 71

• This thesis has many simulation parameters mentioned in section 7.3 which can bechanged or kept as a variable value to make the system more near to real worldscenario.

• Wind turbine energy production can be model in different way. For example, in-corporate the on and off state of wind turbine along with finite or infinite states ofenergy production level.

• Functioning of LVGC can be made more interactive by taking the input from relevantstakeholder who takes care of energy supply and demand.

• In future, more test cases can be executed to analyse the TCP and UDP based mmPrand controller quality as a function of varying request rate, and also as function ofvarying cross traffic.

• Similarly, TCP and UDP based mmPr and controller quality can be analysed on aspecific communication technology e.g.,WiMax, LTE and Wifi wireless technologies.

Bibliography

[1] Drew Baigent et al. “IEC 61850 communication networks and systems insubstations: an overview for users”. In: SISCO Systems (2004).

[2] Prasenjit Basak et al. “A literature review on integration of distributed energyresources in the perspective of control, protection and stability of microgrid”.In: Renewable and Sustainable Energy Reviews 16.8 (2012), pp. 5545–5556.

[3] T Blajic, D Nogulic, and M Družijanic. “Latency improvements in 3G longterm evolution”. In: Proceedings of the International Convention on Informationand Communication Technology, Electronics and Microelectronics. 2006.

[4] Martin Bøgsted, Rasmus L Olsen, and Hans-Peter Schwefel. “Probabilisticmodels for access strategies to dynamic information elements”. In: Perfor-mance Evaluation 67.1 (2010), pp. 43–60.

[5] “Communication networks and systems in substations – Part 7-4: Basic com-munication structure for substation and feeder equipment – Compatible log-ical node classes and data classes”. In: (2003-05).

[6] G Dondossola and R Terruggia. “SmartC2Net use cases, preliminary archi-tecture and business drivers”. In: FTW, AAU, TUDO, RT, RSE, VO, EFACEC,SmartC2Net WP1 Deliverable: Use Cases and Architecture D 1 (2013).

[7] Ahmed Elgargouri. “Implementation oF IEC 61850 in Solar Applications”.thesis. University of VAASA Faculty of Technology Telecommunication En-gineering, 2012.

[8] Stefan Feuerhahn, Robert Kohrs, and Christof Wittwer. “Remote Control ofDistributed Energy Resources using IEC 61850 as Application-Layer ProtocolStandard”. In: Energy Technology 2.1 (2014), pp. 77–82.

[9] Heinz Frank, Sidonia Mesentean, and Friederich Kupzog. “Simplified appli-cation of the IEC 61850 for distributed energy resources”. In: Computational

73

74 Bibliography

Intelligence, Communication Systems and Networks, 2009. CICSYN’09. First In-ternational Conference on. IEEE. 2009, pp. 172–177.

[10] Eirik Hammer and Eilev Sivertsen. “Analysis and implementation of the IEC61850 standard”. PhD thesis. Technical University of Denmark (DTU) Den-mark, 2008.

[11] Hirschmann. White Paper – Data Communication in Substation Automation Sys-tem (SAS). Tech. rep. Hirschmann, 2012.

[12] Wei Huang, Miao Lu, and Li Zhang. “Survey on microgrid control strate-gies”. In: Energy Procedia 12 (2011), pp. 206–212.

[13] “IEC 61850-5, Communication networks and systems for power utility au-tomation – Part 5: Communication requirements for functions and devicemodels”. In: (2012).

[14] “IEC 61850-6: Substation automation system configuration description lan-guage”. In: (2009).

[15] IEC61850. 2016. url: https://en.wikipedia.org/wiki/IEC_61850.

[16] Information Technology - Open Systems Interconnection - Connectionless Presenta-tion Protocol : Protocol Specification, ITU-T Recommendation X.236.

[17] Information Technology - Open Systems Interconnection - Connectionless SessionProtocol : Protocol Specification, ITU-T Recommendation X.235.

[18] Bradley Mitchell. Introduction to Latency on Computer Networks. 2016. url:http://compnetworking.about.com/od/speedtests/a/network_latency.htm.

[19] AD Nguyen. “Integration of IEC 61850 MMS and LTE to support remotecontrol communications in electricity distribution grid”. In: (2013).

[20] T. Weiss P. Sorknæs H. Mæng and A.N. Andersen. Overview of the DanishPower system and RES integration. July, 2013.

[21] Palak Parikh. “Investigation of Wireless LAN for IEC 61850 based SmartDistribution Substations”. PhD thesis. The University of Western Ontario,2012.

[22] Giang T Pham. “Integration of IEC 61850 MMS and LTE to support smartmetering communications”. In: (2013).

[23] Douglas Proudfoot. “UCA and 61850 for Dummies”. In: Siemens Power Trans-mission and Distribution (2002), pp. 21–03.

[24] Jeff Sauro. How To Compute A Confidence Interval In 5 Easy Steps, Discrete Binaryexample. 2014. url: http://www.measuringu.com/blog/ci-five-steps.php.

https://en.wikipedia.org/wiki/IEC_61850

http://compnetworking.about.com/od/speedtests/a/network_latency.htm

http://compnetworking.about.com/od/speedtests/a/network_latency.htm

http://www.measuringu.com/blog/ci-five-steps.php

Bibliography 75

[25] Karlheinz Schwarz. Introduction to the Manufacturing Message Specification(MMS,ISO/IEC 9506). 2000. url: http://www.nettedautomation.com/standardization/ISO/TC184/SC5/WG2/mms_intro/.

[26] SmartC2Net Consortium, Deliverable D4.2; Supply/Demand Control Algorithms- final report; Online Available. March, 2015. url: http://smartc2net.eu/public-deliverables.

[27] Karl Solie and Leah Lynch. “CCIE Practical Studies”. In: Energy Technology1st edition, II (2012).

[28] Jan Tore Sorensen and Martin Gilje Jaatun. A description of the ManufacturingMessage Specification (MMS). 2007.

[29] Cobus Strauss. Practical electrical network automation and communication sys-tems. Newnes, 2003.

[30] Wencong Su and Jianhui Wang. “Energy management systems in microgridoperations”. In: The Electricity Journal 25.8 (2012), pp. 45–60.

[31] Jian-Cheng JC Tan, Vince Green, and John Ciufo. “Testing IEC 61850 basedmulti-vendor substation automation systems for interoperability”. In: PowerSystems Conference and Exposition, 2009. PSCE’09. IEEE/PES. IEEE. 2009, pp. 1–5.

[32] Mini S Thomas, Ikbal Ali, and Nitin Gupta. “Interoperable Framework forIEC61850 Compliant IEDs and Noncompliant Energy Meters with SCADA”.In: Energy Technology & Policy 2.1 (2015), pp. 73–81.

[33] Taha Selim Ustun, Cagil Ozansoy, and Aladin Zayegh. “Distributed EnergyResources (DER) object modeling with IEC 61850–7–420”. In: UniversitiesPower Engineering Conference (AUPEC), 2011 21st Australasian. IEEE. 2011,pp. 1–6.

[34] M Vikram and N Gupta. “Performance Analysis of QoS Parameters for WimaxNetworks”. In: International Journal of Engineering and Innovative Technology 1.5(2012).

[35] Why We Need a Smart Grid. url: http://trilliantinc.com/smart-grid.

[36] Wikipedia. MoSCoW method. 2015. url: https://en.wikipedia.org/wiki/MoSCoW_method.

[37] Byong-Kwan Yoo et al. “Communication architecture of the IEC 61850-basedmicro grid system”. In: Journal of Electrical Engineering and Technology 6.5(2011), pp. 605–612.

http://www.nettedautomation.com/standardization/ISO/TC184/SC5/WG2/mms_intro/

http://www.nettedautomation.com/standardization/ISO/TC184/SC5/WG2/mms_intro/

http://smartc2net.eu/public-deliverables

http://smartc2net.eu/public-deliverables

http://trilliantinc.com/smart-grid

https://en.wikipedia.org/wiki/ MoSCoW_method

https://en.wikipedia.org/wiki/ MoSCoW_method

76 Bibliography

[38] Ramon Zamora and Anurag K Srivastava. “Controls for microgrids with stor-age: Review, challenges, and research needs”. In: Renewable and SustainableEnergy Reviews 14.7 (2010), pp. 2009–2018.

[39] Ramon Zamora and Anurag K Srivastava. “Controls for microgrids with stor-age: Review, challenges, and research needs”. In: Renewable and SustainableEnergy Reviews 14.7 (2010), pp. 2009–2018.

Appendix A

Input Parameters of markov modelfor wind turbine

This appendix represents all parameters of continuous markov chain used to model windturbine.

A.1 Initial Parameters of markov model

Initial parameters are used when system starts at t=0, when there is no action from thecontroller is observed.

A.1.1 Generator matrix

Generator matrix represents the rate of moving from one state to another.

GNeutral =

−0.63 0.63 0 0 0 00.43 −0.73 0.3 0 0 0

0 0.97 −0.99 0.02 0 00 0 0.11 −0.12 0.01 00 0 0 0.36 −1.27 0.910 0 0 0 0.21 −0.21

77

78 Appendix A. Input Parameters of markov model for wind turbine

A.1.2 Mean holding time

Mean hold time means amount of time (in sec) spend by server in a state. Matrix valuesrepresents the mean holding sequentially for state 1,2,3 and so on.

MHTNeutral =(1.587 1.37 1.010 8.3 0.79 4.76

)

A.1.3 Transition matrix

Transition matrix tells the probability of jumping from state to another state.

PNeutral =

0 1 0 0 0 00.589 0 0.4109 0 0 0

0 0.978 0 0.0202 0 00 0 0.916 0 0.083 00 0 0 0.283 0 0.7160 0 0 0 1 0

A.2 Parameters of markov model to drift up states in for-ward direction

Below parameters are used when controller wants to drift up state to reach the desirablestate of 3 and 4


Values of generator matrix change as follow when drift rate of 0.5 is applied in forwarddirection.

GUp =

−1.13 1.13 0 0 0 00.43 −1.23 0.8 0 0 0

0 0.97 −1.49 0.52 0 00 0 0.11 −0.62 0.51 00 0 0 0.36 −1.77 1.410 0 0 0 0.21 −0.21

A.3. Parameters of markov model to drift up states in backward direction 79


Mean holding time of state after applying drift rate

MHTUp =(0.8849 0.813 0.671 1.612 0.5649 4.76

)


Drift rate brings following changes in transition matrix too

PUp =

0 1 0 0 0 00.349 0 0.650 0 0 0

0 0.651 0 0.348 0 00 0 0.1774 0 0.8225 00 0 0 0.2033 0 0.79660 0 0 0 1 0

A.3 Parameters of markov model to drift up states in back-ward direction

Below parameters are used when controller wants to drift up from state 5 or 6 to state 3 or4


Values of generator matrix change as follow when drift rate of 0.5 is applied in backwarddirection.

GDown =

−0.63 0.63 0 0 0 00.93 −1.23 0.3 0 0 0

0 1.47 −1.49 0.02 0 00 0 0.61 −0.62 0.01 00 0 0 0.86 −1.77 0.910 0 0 0 0.71 −0.71


Mean holding time of state after applying drift rate

MHTDown =(1.587 0.813 0.671 1.612 0.5649 4.76

)

80 Appendix A. Input Parameters of markov model for wind turbine


Drift rate in backward direction also brings following changes in transition matrix too

PDown =

0 1 0 0 0 00.756 0 0.2439 0 0 0

0 0.9865 0 0.0134 0 00 0 0.9838 0 0.0161 00 0 0 0.4858 0 0.51410 0 0 0 1 0

Appendix B

Matlab code to calculate mismatchprobability

In this appendix, matlab code to calculate mismatch probability has been explained.First, MMS client and server csv files generated in ns-3 simulation has been saved into .matfiles. These files contains the information about state of server at client and server side.Such as, file Server _state.csv contains the information that server spends in each state. Thisfile helps to know the state of server at any point of time. Similarly, file Client_state.csvcontains the information about server state when the response packet is received.

1 %Load the S e r v e r s t a t e f i l e .2 S=c s v r e a d ( ’ S e r v e r_s t a t e . c s v ’ ) ;3 s a ve ( ’ S e r v e r_s t a t e ’ , ’ S ’ ) ;45 C=c s v r e a d ( ’ C l i en t_state_500 . c sv ’ ) ;6 s a ve ( ’ C l i en t_state_500 ’ , ’C ’ ) ;

Listing B.1: Import data into matlab

This matlab code is used to initialize a variable to count number of miss information.

1 % I n i t i a l i z e a v a r i a b l e to count number o f mi s s i n f o rma t i o n2 HitCount = z e r o s ( l e n g t h (C) ,1 ) ;

Listing B.2: Initialize a variable to count miss information

Here, each received state of server at client side is matched with the state of server on thatspecific point of time. If state differ from each other, HitCount variable is incremented by1. Finally, mean of HitCount gives the value of mmPr.

1 % Ca l c u l a t i n g the mis s i n f o rma t i o n2 f o r i =1: l e n g t h (C)3 f o r j =1: l e n g t h (S)4 i f (C( i , 2 ) >= S( j , 2 ) && C( i , 2 ) <= S( j , 3 ) )5 match = 1

81

82 Appendix B. Matlab code to calculate mismatch probability

6 i f (C( i , 3 )~= S( j , 4 ) )7 HitCount ( i , 1 ) =1;8 e l s e9 HitCount ( i , 1 ) =0;

10 end11 end12 end13 end14 %Ca l c u l a t i n g mmPr15 mmPr = mean ( HitCount ) ;

Listing B.3: Calculating mismatch probability

Appendix C

Matlab code to calculate quality ofcontroller performance

In this appendix, matlab code to calculate quality of controller performance has been ex-plained.First we, initialize an array for number of states.

1 % Def i n e number o f s t a t e i n an a r r a y2 s t a t e = [ 1 , 2 , 3 , 4 , 5 , 6 ] ;

Listing C.1: Array of states

It is also required to initialize separate variables to calculate total amount of time spend ineach state

1 % I n i t i a l i z e t ime v a r i a b l e s to c a l c u l a t e the t o t a l amount o f t ime i n each2 % s t a t e3 t s 1 =0;4 t s 2 =0;5 t s 3 =0;6 t s 4 =0;7 t s 5 =0;8 t s 6 =0;

Listing C.2: Initialization of variables

Now, load Server file containing information about server state with duration of timespend in a state in whole span of simulation.

1 %Load the S e r v e r s t a t e f i l e .2 l o a d ( ’ S e r v e r_s t a t e . mat ’ ) ;

Listing C.3: Import data into matlab

Following lines of codes Listing C.4, helps to sum up the time when server stays in a state

83

84 Appendix C. Matlab code to calculate quality of controller performance

1 f o r j =1: l e n g t h (S)2 i f S( j , 3 )==13 t s 1 = t s1 + S( j , 2 )−S( j , 1 ) ;45 e l s e i f S( j , 3 )==26 t s 2 = t s2 + S( j , 2 )−S( j , 1 ) ;78 e l s e i f S( j , 3 )==39 t s 3 = t s3 + S( j , 2 )−S( j , 1 ) ;

1011 e l s e i f S( j , 3 )==412 t s 4 = t s4 + S( j , 2 )−S( j , 1 ) ;1314 e l s e i f S( j , 3 )==515 t s 5 = t s5 + S( j , 2 )−S( j , 1 ) ;1617 e l s e i f S( j , 3 )==618 t s 6 = t s6 + S( j , 2 )−S( j , 1 ) ;19 end20 end

Listing C.4: Calculating amount of time server spend in each state

Following formula is used to measure the controller performance and as coded in List-ing C.5

QoC =π3

Ttotal+

π4

Ttotal(C.1)

where:QoC = Quality of Controller Performanceπ3 = Steady state probability of being in State ’3’π4 = Steady state probability of being in State ’4’Ttotal = Total time used observing the system

1 % Formula to c a l c u l a t e the c o n t r o l l e r pe r fo rmance2 QC = ( t s 3+t s4 ) /( t s 1+t s2+t s3+t s4+t s5+t s6 )

Listing C.5: Calculating amount of time server spend in each state

Appendix D

IEC 61850 logical node for wind tur-bine smart metering

In IEC 61850-7-4 the logical node class MMTR (metering) is defined [5]. This logical nodeprovides the list of data classes that can be used to retrieve the information about energyproduction produced by the wind turbine system.

Figure D.1: Logical node class MMTR (metering)

85

assessment of information reliability using iec 61850 mms...

Documents