Automatic control of renewable energy sources at varying load

(1)

UPTEC E 20014

Examensarbete 30 hp

Juni 2020

Automatic control of renewable

energy sources at varying load

Patrik Zenkert

Douglas Lowén

(2)

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Automatic control of renewable energy sources at

varying load

Patrik Zenkert, Douglas Lowén

With the current climate crisis with the global temperature increasing due to fossil fuelsbeing used there are big investments in green energy. Wind power is a good alternative tofossil fueled power and already has a widespread use. One of the problems with wind poweris control and keeping the grid frequency stable during peaks and lows of power generation.In this master thesis there is a goal to implement a system which can regulate wind millswhile always trying to use as much wind power as possible.A model was built in Matlab to represent the final product which was translated into aSCADA system. A fully integrated

communication from SCADA computer to PLC to IEDto wind mill and back was built.The simulation in the SCADA system gave satisfactory result where the wind power wasutilized to the maximum, and other conditions met. The laboratory experiment with anArduino represented as the wind mill lacked in communication and the model did not achieveperfect results in every case. There is future work to be done, improved communication,additional or alternative automatic control and creating a bigger system with

several powerproducers integrated.

Ämnesgranskare: Mikael Sternad Handledare: Johan Wistedt

(3)

Populärvetenskaplig sammanfattning

Detta examensarbete har arbetat med att utveckla en lösning som reglerar vindkraft sam-tidigt som man ska utnyttja så maximal effekt som möjligt från vindkraften. Man reglerar Vindkraftselproduktion till elnätet när det produceras mer elkraft än det konsumeras. Detta sker under tider när det blåser mycket och är varmt. Vid sådan tillfällen kan man behöva reglera ner på vindkraftsproduktionen eftersom ett överskott skulle leda till att frekvensen på elnätet kan börja stiga, ökar den för mycket kan andra känsliga elektriska maskiner sön-der.

Detta projekt startades med att man skapade en modell i Matlab som tog information från ett exempel som skulle kunna ske på Gotland. I detta exempel skulle man inte producera mer effekt än vad lasten behövde, det skulle också vara en andel av lasten som ska vara annat kraftslag än vindkraft då detta är essentiellt för att hålla frekvensen stabil.

Med dessa kravställningar lyckades en modell i SIMULINK skapas som senare översattes till ett nytt system som ska representera en mer verklig situation. I det nya systemet som byg-gdes fanns det en representation av ett vindkraft i form av en Arduino, en Phoenix contact enhet som mäter last samt läser av vad som sker med vindkraften, en programmerbar enhet från Brodersen som beräknar hur regleringen ska ske samt skickar vidare informationen till en dator som representerar all data på ett övervakande system som är lättläsligt.

Först skapades ett system där vindkraftverket simulerades så man använder sig endast av datorn samt den programmerbara Brodersen enheten, resultaten från den simulationen var bra. Vid nästa test när Arduinon kopplades in blev det problem antagligen i kommunika-tionen mellan Arduinon och Phoenix mätenheten då upplösningen var för låg. Detta ledde

(4)

till att regleringen aldrig stannade och började skjuta iväg med antingen för mycket eller för lite vindkraft. Detta kan förbättras i framtida arbete.

Det finns mer att göra med detta system. Som grund är det en bra utgångspunkt från var man ska gå vidare för att vidareutveckla ett helt integrerat system som utnyttjar förnybar energi maximalt. Detta kan bli kombinerat med andra sätt att styra hur mycket kraft som produceras men också hur mycket som skulle konsumeras i extrema fall som kan vara en lösning om det kommer en framtida effektproduktionsunderskott.

(5)

Acknowledgements

We would like to start by thanking everybody at Techinova, especially our supervisor Johan Wistedt. He has taught us every new system used in this project and this thesis would not have been possible without him and his help. Furthermore our subject reviewer Mikael Sternad has also helped us by asking us relevant questions pointing us in the right direction, lastly we would like to thank our families, friends and the nice people at Copa Data Sweden that let us use their office before everybody was forced to stay at home.

(6)

List of Acronyms

CEL Chronological Event List

GOOSE Generic Object-Oriented Substation Event HMI Human Machine Interface

HVDC High Voltage Direct Current IDE Integrated Development Environment IEC International Electrotechnical Commission IED Intelligent Electronic device

IEEE Institute of Electrical and Electronics Engineers I/O Input/Output

TCP/IP Transmission Control Protocol/Internet Protocol MMS Manufacturing Message Specification

PID Proportional-Integral-Derivative PWM Pulse width modulation PLC Programmable Logic Controller RTU Remote Terminal Unit

SAS Substation Automation System

(7)

1. Introduction

1.1 Description and background

Climate change is a global and humanitarian threat. This threat is already affecting the world with a global increase of temperature around 1◦C [1]. With the current rate of change most predictions says that the temperature will rise even more. With the signing of the Paris agreement Sweden and almost every other country in the world has vowed not to increase the temperature more than 2◦C [2]. This combined with the Kyoto protocol has led to Sweden making a major efforts in reducing its carbon footprint, resulting in investment in renewable energy, this shift on funds were agreed upon by a majority of the parties in Sweden in the deal "Energiöverrenskommelen". This agreement has guidelines for the fu-ture energy production for Sweden. One of the most noticeable change in this agreement affecting us today is the goal to have 100 % renewable energy production by 2040. This has huge implication since the nuclear power production in Sweden today is around 40%, which is fossil free during operation however not renewable. This has led to major investments in renewable energy, foremost wind power.

Wind power is a cheap source of energy under certain conditions, there must be an in-frastructure supporting the power being generated, there must be windy and preferable a steady stream of winds. These conditions exist often offshore or near shore. Gotland is a natural place in Sweden which fulfills all these criteria and is in need of power due to being an island.

(11)

never commercially successful and therefore not expanded. The interest in wind power started increasing again at the start of the 90’s with Vattenfall building wind power stations in Gotland and other coastal provinces in Sweden. [3]. The wind power today has been expanded to a degree where it produces around 45% of the consumption on the islands [4]. The usage of power electronics in wind power makes it harder to keep the grid frequency as stable as when using a rotating machine as in hydro or nuclear power plants. This has led to a stop in wind power expansion on Gotland. These problems can be fixed with a better connection to the grid of the mainland. Plans for an expansion suggested in 2009 were lately scrapped. Currently there are 2 high voltage direct current(HVDC) cables Gotland 2 and 3 connected to the island supplying the demand during downswings of wind power production and keeping the grid stable.

Techinova AB is working within the energy sector in Sweden and are developing and selling products tailored for electrical distributors in need for a smart grid where a combination of renewable and traditional power sources needs communication. To solve these challenges Techinova uses its own self developed communication and automation-system called TechiN-ode. This combined with auto reclosers makes a self-healing distribution-grid possible. The usage of this system when searching for faults and automatic sectioning of the power sys-tem has made it possible for Techinova to solve the problems with power shortages and automation of renewable power sources.

1.2 Purpose

The purpose of this project is to create a general solution for automatic control of re-newable energy sources at varying load and build a full model with Intelligent electronic devices(IEDs) that communicates and can implement the solution.

The solution shall include:

• A Remote Terminal Unit(RTU) with a soft Programmable Logic Controller(PLC), in a substation controlling a renewable energy source.

(12)

• Additional RTUs shall measure the power of the load and production in the elec-tric power system and communicate via 61850 Manufacturing Message Specifica-tion(MMS)/Generic Object-Oriented Substation Event(GOOSE).

• The sub-station RTU shall communicate with a local SCADA system via IEC 60870-5-101/104 where the power curves, local and external production shall be shown and stored.

(13)

2. Theory

2.1 IED

Intelligent Electronic Devices(IED) are devices containing one or multiple processors which have the capability to receive or send data from and to an external source. An IED with its microprocessor and communications technology, the unit provides self and external circuit monitoring, real-time synchronisation for event reporting. An IED therefore increases the possibilities for remote, local control and data information such as current and voltage phasors. One could say that IEDs are the eyes and ears of any remote power management system[5]. Any device using the standard IEC protocol, the name IED is used for any controller that can process and communicate data according to the communication standard. In this project, the IEDs will consist of a Remote Terminal Unit(RTU), a bus coupler as well as a redundant system consisting of two Techinova RTUs part of the TechiNode system.

2.1.1 Brodersen RTU32M

For the data processing system, a Brodersen RTU32M will be used as the main commu-nicator between the bus coupler and the SCADA system. The Brodersen RTU32M works similar to a PLC as it is a microprocessor that can transmit measurements and calculated data through communication standard to a master system, which in this project will be the SCADA system. The SCADA system will also be able to send commands down to the RTU where control functions will act on the measurement system to control power flow.

(14)

The Brodersen RTU32M will be programmed with all the automatic control functions and measurement variables making it a central part of the project. The RTU32M will be placed in a substation or node where the finalized project system would be deployed and from its position work as a data processor and transmitter to report information to and from the master computer with the SCADA system. So the Brodersen RTU32M works as a PLC ex-cept the remoteness of the RTU is the main difference from other PLCs. PLC devices often need to be close to the SCADA with wired communication channels, RTU can use wireless communication standards when receiving and transmitting data. The Brodersen RTU is programmable via regular PLC programming making it easy to configure for a specific sys-tem and for this project. The reason behind choosing a Brodersen RTU32M for the specific project is also its ability to use redundant network protocols. As the RTU will communi-cate with the Phoenix Contact Substation Automation System(SAS) -BK using IEC 61850 protocol, it can use a redundant system using IEC 60870-5-101/105 for communication with SCADA as well as the TechiNode system.

Figure 2.1: Brodersen RTU32M

2.1.2 Phoenix Contact SAS

Another hardware component used for this project is the Phoenix Contact SAS bus coupler that uses IEC 61850 communication. A bus coupler is a component which can couple multiple buses together without creating disturbances in power supply and creates a safe

(15)

environment without arcs. Through this device, the measurement values of the wind power plant production, load and external DC power are fed through the device and are calculated to values in Watt. The communication from the device further down the system is made through IEC 61850 either GOOSE or MMS. [6]

2.2 Arduino

Arduino is an open source hardware and software company. Arduino is manufacturing several micro controllers, with one of the most common and used product, the Arduino UNO. Developed for easy to use with electronics and to be implemented with code with other electrical components [7].

Arduino UNO uses the ATmega328P microchip with 14 digital I/O pins, 6 analog inputs, a USB connection, a power jack and a 16 MHz ceramic resonator. The UNO can be used with the Arduino Software integrated development environment(IDE).

(16)

Figure 2.2: Schematic of an Arduino UNO [8]

2.3 SCADA and HMI

For processing all signals and data from the IED in the configured system, a Human Machine Interface(HMI) and a Supervisory Control and Data Acquisition(SCADA) system is needed. As substation and grid networks are often monitored and operated through some command central, a SCADA system with multiple HMIs is the highest hierarchical command central. All of the important information and commands are operated through the SCADA system throughout the network.

(17)

2.3.1 SCADA

SCADA is a system containing software and/or hardware to allow supervision and operation of industrial organization[9]. SCADA systems allow for:

• Control industrial processes locally or at remote locations • Monitor, gather, and process real-time data

• Directly interact with devices such as sensors, valves, pumps, motors, and more through HMI software

• Record events into a log file

The four items above are important for industrial organization as they improve control of an overview of the whole system. The monitoring and controlling of different SCADA systems is based on five different levels or hierarchies. Depending on what systems is being monitored or controlled, the amount of levels present may differ from system to system.[10] These levels are:

0. Field level instrumentation and control devices 1. Marshalling terminals and RTUs

2. Communications system 3. The master station(s)

4. The commercial data processing department computer system

Level 0 comprises of sensors and other measuring instruments. On level 1 the RTUs pro-vides an interface to the analog and digital signals. Level 2 is the communication systems between the master station and the remote sites. This communication can for instance be radio, TCP/IP, telephone, microwave or any other form of communication. The master sta-tion, at level 3, gather all data from the RTUs and generally provide an operator interface for control and information on the remote sites. Different interfaces on higher level for data

(18)

processing on a commercial level is the last hierarchical level.

Modern SCADA systems nowadays allow real-time data from the instruments to the op-erator to be accessed anywhere in the world. With increasing digitization and modern communications systems, most SCADA systems are now computers with a SCADA soft-ware.

Figure 2.3: the SCADA-hierarchy

2.3.2 Zenon Energy

In this project the Zenon Energy Edition 8.00 was used as SCADA software. Zenon Energy Edition is a software platform developed for the automation and control of power generation, transmission and distribution. The controlling and automation of substations, distribution management, energy storage, renewable energy management and public transport are not limited by the applications provided by the software. One advantage with Zenon Energy is that it supports all major industry standard protocols such as IEC 61850 and IEC 61870-5-101/104 which are used in this thesis project. [11]

(19)

The Zenon Energy Edition is built up of two main software programs, the Zenon Editor and the Zenon Runtime. The Zenon Editor is the workspace software where the HMI is built and configured. In this workspace all internal and external variables and functions are configured to build the HMI. The designing of the HMI is also made in the Zenon Editor where one can design screens, buttons, dashboards and more that facilitates a user friendly HMI. The functions and variables are linked to the buttons and dashboards to either read or write values. As an example, the IEC 60870-5-104 signals will be variables when imported to the workspace of the Zenon Editor where they can be configured and used in the preferred way. When a HMI has been made in the Zenon editor, it is possible to run the HMI real time with the Zenon Runtime. In the Runtime, the operator can control and monitor the system through the HMI. As described, Zenon Runtime displays the final product designed in the Zenon Editor.

2.4 TechiNode

The company Techinova has developed its own system solution for the distribution grid market called TechiNode. The TechiNode system can be described as a radio network that runs parallel to the ordinary grid. The purpose of the system is to enable control and supervision of the grid, error detection, measurement, automation of active equipment such as breakers and reclosers.

The core of the TechiNode system is the Radio RTU. The RTU is very efficient considering overall function, memory space, and its energy consumption through integrated functions for radio, communication, automation and I/O.

For this project, two parts of the TechiNode system have the possibility to be implemented which are the RS-15 communication RTU as well as the BRS-71 substation RTU. As the project in itself will be using the previous described Pheonix contact SAS and the Brodersen RTU32M as the main and only components to handle signal processing and communications between nodes, the TechiNode system is able to run as a parallel redundant communication system to back up the main communications system in this project. The BRS-71 for protocol

(20)

IEC 60870-5-101 has the built-in ability for wireless communication with underlying units. The RS-15 has therefore a similar task as the Brodersen RTU but communicates with the base station RTU BRS-71 instead. Hence data can be transferred in a redundant way to the SCADA system using the TechiNode system.

Figure 2.4: System overview of hardware and communication

2.5 Protocol

Protocol is a set of standards and definitions that electronic devices uses to more easily communicate. There are several different protocols being used today when communicating between IEDs. The protocols used for communicating in this project have been chosen partly to be able to create a secure communication between the sender and receiver, partly to be able to have a redundant communication via TCP/IP and radio communication.

2.6 IEC 61850

Substation automation and communication has grown bigger and more relevant in recent years. With the need for international standards, the International Electronics Commission (IEC) has developed a global standard for substation automation with the information model IEC 61850 [12]. This was produced due to several different manufacturers and users wanted a standard for the IEDs to achieve an easier communication and collaboration between

(21)

different manufacturers products [13]. Having this standard, a more structured approach could be used when designing substation automation systems, the standard had its main development and publishing between 2002 to 2005 of version 1. Version 2 was launched around 2007 with various updates of the standards, it has had an continuous development by IEC technical committee 57 ever since[14].

One of the main purposes of IEC 61850 is interoperability between IEDs from different providers, this can be achieved by the standardization of IEC 61850 [15]

Figure 2.5: Vertical and horizontal communication illustrated [16]

There are a number of data models defined in IEC 61850. Mappings for communication are Sampled Measured Values, MMS and GOOSE. These are used over TCP/IP networks and LANs(Local Area Networks). The use of MMS is a vertical communication from bay to supervisory level, IEDs to SCADA. Sampled values internal on bay level from IED to IED

(22)

and lastly GOOSE, horizontally IED to IED between different bays as seen in figure 2.5. The connection between two IEDs can be used for a function to be be performed on one IED and reside on another, this standard demands free allocation of different standards and a need for interoperability. This can be used for both a centralized and decentralized approach.

2.6.1 Logical node

Figure 2.6: IEC 61850 Visual representation of data modelling

The data modelling breakdown starts from a physical device down to a logical device. A logical device represents a group of logical nodes and is the communication access point. The logical node is the lowest level of a virtualized function of physical equipment. A logical node is built up with individual Data Objects which has the Data Attribute in them, seen in Figure 2.6 [17]. This separation can be used due to having one measurement in an IED but wanting to use them in different functions and thereby get different values which creates the need for these data separations. Common Data Attributes are value, time, and quality.

(23)

Figure 2.7: Example: position of a circuit breaker using IEC 61850

To get specific values, for example a breaker, the addressing can be written as in Figure 2.7. All these devices, nodes, constraints, objects and attributes can be changed to get other values from different IEDs.

Table 2.1: Table of LN groups Group indicator Logical node groups

AXXX Automatic control

CXXX Supervisory control

DXXX Distributed Energy Resources (DER) FXXX Functional blocks

GXXX Generic function references

HXXX Hydro power

IXXX Interfacing and archiving

KXXX Mechanical and non-electrical primary equipment LXXX System logical nodes

MXXX Metering and measurement PXXX Protection functions

QXXX Power quality events detection related RXXX Protection related functions

SXXX Supervision and monitoring

TXXX Instrument transformer and sensors

WXXX Wind power

XXXX Switchgear

YXXX Power transformer and related functions ZXXX Further (power system) equipment

(24)

2.6.2 IEC 60870-5

IEC 60870-5 first sub-part published in 1990 is a reference to a bundle of standards that gives detailed functional description for systems controlling SCADA [15]. It is the most used standard in the electrical industry but has other applications as well. It has six core standards and four companion standards. The standard is applied when sending data from a substation to a master and sending data back.

IEC 60870-5-101

IEC 60870-5-101 is one of the companion standards which operates over low bandwidth. Used in the energy sector it is based on the Enhanced Performance Architecture using a serial based communication[15].

Vendors are ensured interoperability by the interoperability list defined by the standard. Defined in the list is the function range for each device by marking the applicable functions. Due to different implementations on a vast amount of devices it was not until Bayernwerke (E.ON), developed independent IEC 60870-5-101 based standards which has become the most common standard in the Scandinavian countries. The advantage of this protocol is the resilience of its link layer and for its simplicity in structured application layer. With a focus on performance has led to information needed for data decoding is not transmitted. To decode correctly one must know information object length, the Application-layer Service Data Unit(ASDU) address length etc. which can be found in the interoperability list[18].

IEC 60870-5-104

IEC 60870-5-104 is a transport function for 60870-5-101 provided by TCP/IP. Adding a network layer to the EPA model[19] meaning it enables a communication via standard network and coexisting data transfer between several devices and services. The protocol has smaller information types and configuration parameters as in 60870-5-101 leading to 60870-5-104 missing some functions like short time stamps. In 60870-5-104 widely uses an interoperability list as 60870-5-101 [20].

(25)

2.7 Automatic Control

Automatic control is the application of control theory for regulation of dynamical systems. In closed loop systems a negative feedback is used to improve the desired output from the system and reach the set point.

2.7.1 PID

A proportional-integral and derivative(PID)-controller have been around since the 18th cen-tury and is commonly used within mechanics and electronics [21]. The ability of the PID is to utilize the 3 interacting factors proportional, integral and derivative. the P, I and D is parallel coupled as seen in 2.8.

Figure 2.8: Visual representation of a PID controller with a controlled system

The PID-system starts with a desired set point value(r(t)), r(t) is subtracted by the out-put(y(t)) of the system giving the error value r(t)-y(t), (e(t)). The error value is sent to the three parallel processes of P, I and D. The gains Kp, KI and KD are weighted depending on

(26)

how the optimal system operates. The combined signal after the P, I and D block becomes the overall control function(u(t)) which is the signal sent to the state-space representation of controlled system that represents the dynamic system being controlled, out from the state-space block is the final output, the position or value of the system, is sent back again to be subtracted with the set point value generating a feedback loop, thus creating a new error value and restarting the process.

Proportional

The proportional part of the PID is calculated by taking the difference from the set point value and the feedback output value, e(t), multiplied by a factor of KP. As seen,

Pout= Kpe(t). (2.1)

Automatic control with only a proportional block is simple and is common to start with because of the simplicity, a high KP increases the instability of the system since a small

change or error may cause the system to overreact[21].

Integral

The integral term in a PID controller is the sum of all the previous and current errors multiplied by KI as seen,

Iout= KI

Z t

0

e(τ )dτ, (2.2)

this makes the Integral term of the PID dependent on the duration of and and the magnitude of the error over time. The integral term moves the actual value towards the set point value faster and decreases residual steady state error that may occur with a pure proportional controller. Due to integral part accumulates error over time there is a risk of overshoot if the magnitude of KI is too large[21].

(27)

Derivative

The derivative of e(t) calculates the slope of the error over time and multiplies it by KD as

seen,

Dout= KD

de(t)

dt . (2.3)

The characteristics of the derivative term in a PID is to improve settling time and stabil-ity[21]. However a derivative term is not commonly used in PIDs and can create a more unstable system easily with a high KD.

2.7.2 State-space representation of a controlled system

A state space representation used in control theory is a mathematical model of a physical system. This is created because you cannot predict the consequences of the output signal due to the input signal. The state-space representation of controlled system created depends of the input, output and the current state of the system and can be described by linear differential equations [22]. A linear continuous time invariant system with p inputs and q outputs and n state variables can be written in the following form:

˙

x(t) = Ax(t) + Bu(t) y(t) = Cx(t) + Du(t)

(2.4)

x is the state vector, y is the output vector, u is the input or control vector. A, B, C and D are the state, input, output and feed forward matrices.

2.7.3 Tuning

Tuning a PID-controller is paramount for a successful automatic control, weighting the 3 parts of the PID between each other can be done intuitively, this may give good results but may be hard to replicate and can cause unforeseen errors. A manual tuning approach in form of Ziegler-Nichols method, is commonly used. Where one starts with KI and KD set

(28)

for further tuning is half of KP O,

KP T =

KP O

2 . (2.5)

The tuning is continued by increasing KI until the steady state error is eliminated and then

(29)

3. Implementation

3.1 Model

The model built in this project was made with the technology invented by Techinova in mind. The signals, i.e. load, wind power or supply is being simulated on an Arduino UNO device, receiving information via a binary code and relaying information via a PWM signal from 0 to 5V to the RTU. The resulting signals are measured by the Phoenix contact SAS device, these signals results in voltage, current, grid etc. The values being transferred over to the Brodersen soft PLC. The soft PLC makes the automatic control by itself sending back information to the Phoenix contacts device. From the Brodersen module additional signals transferred to the main computer where the SCADA system operates while displaying the data given.

One signal is sent via IEC 60870-104 directly to the main computer. The redundant signals, activated when the IEC 60870-104 communication is down, is sent via IEC 60870-101 first to the RS-15 unit. The RS15 unit is relaying the information via radio communication to the BRS-71 unit which is receiving the radio communication to finally send it to the main computer to be presented in the SCADA system as seen in 2.4.

To reach the final results with a satisfactory product there had to be several iterations of the model starting by finding a real-life example where a model is described, continuing with a theoretical model where the problem is formulated, set up and solved. Lastly a lab model was created where the solution could be implemented on a rudimentary level with physical devices.

(30)

3.1.1 Original

The description of the environment where the model is to be used is based on an the actual conditions from the Gotland island. Information taken from a former master thesis about wind power curtailment with the title Automated Curtailment of Wind Turbines during Critical Transmission Periods [23]. It can be found that the minimum power transfer from the mainland is 20 MW and that the power flow average from the mainland is 40 MW. The model expanded from this information have set three conditions in the model used in this project. These conditions were derived as a consequence of the wind power curtailment master thesis.

• PHV DC = PLOAD − PP RODU CED

• Minimum 30 % power delivered from HVDC • Minimum 30 KW power delivered from HVDC

The conditions have been created to be placeholders, the conditions are changeable to facil-itate changes if the conditions of the environment would change.

3.1.2 SIMULINK model

For this project to be fully understood and completed a model was created for broader understanding. Therefore, a theoretical model of the automatic control was firstly created in Simulink. The Simulink model included input parameters of the DC-supply, Wind power and load in. In the first models of the project the signals were static and the Simulink program was created to behave in a way which represented the physical model.

(31)

Figure 3.1: Simulink model representing the physical model and the complete system

Figure 3.1 represents the complete physical model created in Simulink as derived from the original model. There are a few main blocks in the system which have different purposes. In figure 3.1 the green and blue blocks represents wind power production(PW indpower) input

in kilowatts and the load(PLoad) in kilowatts. The red block represents the set point value

calculation through conditions. The yellow block is the control block containing the PID-controller as well as the state space of a wind power plant. These blocks are seen in detail below in figure 3.2 and 3.3. First, the main input variables representing the load as well as the wind power produced are represented as signal blocks to show a varying load and production. As the system is closed off, the third input variable, Grid power, is the difference between load and wind power produced. The Grid Power is determined as stated in equation 3.1 as PGrid.

PGrid= PLoad− PW indpower (3.1)

The reasoning behind this equation is that the grid would supply all remaining power missing to compensate for the load. This is made under the assumption the grid could provide the remaining power. Just like a power output in the wall at home. These variables are represented by colours, the green for wind power produced and blue for load in figure 3.1. For all calculation, all values were stated in kilowatts(kW).

(32)

With the three input variables determined, the first order was to include the conditions for the set point value into the model. In figure 3.1 these calculations are made inside the red block. The reason behind having this block was to have the correct set point value reach the PID-controller block which takes the conditions into consideration.

Figure 3.2: Calculating the Set-point value according to known case limits

Figure 3.2 represents the set point calculation block with the conditions of the thesis taken into consideration. There are really two main calculations being made inside this block. The green block seen in figure 3.2 is only to determine whether conditions are met and how the signal is to pass through the subsystem block. The green block therefore collects the two input signals of DC power and load and compares them to the conditions. The green block is a simple if statement taking the input values in to account. The inputs to the if statement were PGrid, 30% of PLoadaccording to the condition and PW indpower.

(33)

Algorithm 1: Set point calculation through conditions Input: PGrid, PLoad, PW indpower

Output: PSetpoint

1 if PGrid< 30kW then

2 PSetpoint = PW indpower− (30kW − PGrid)

3 else if P_Grid< (0.3 · P_Load) then

4 P_Setpoint = P_{W indpower}− (P_Load· 0.3 − P_Grid)

5 else

6 PSetpoint = PW indpower

As there are two main conditions, seen in section 3.1.1, there are two orange blocks a new set point according to the condition. If conditions are not fulfilled, the wind power produced signal will pass through as the set point. If the conditions are exceeded, Algorithm 1 will calculate a new set point value. The conditions are as stated in 3.1.1 and the orange blocks will prevent the set point to excess these conditions and will act as the new set point. The algorithm in the condition blocks are shown above in Algorithm 1.

By setting up the condition block this way, the set point will always be the amount of wind power produced momentarily while no conditions are met. At a point when a condition is violated, the algorithm will change the set point to a value which will not violate any condition. This way the controller will recieve an error between the set point and the actual production and start eliminating the error. By configuring the set point, PSetpoint, after the

power conditions this way, the maximum wind power production set point can be assured at all times.

(34)

Figure 3.3: Simulink model of the PID-controller and the usage of state-space representation of a controlled system. The model is found within the Yellow block in figure 3.1

When a set point had been calculated in the red block seen in figure 3.1, the set point value is sent to the control block. Inside the control block, the point is to have a PID-controller eliminate the error between the calculated set point and the actual momentary wind power production. The output of the control block is the actual wind power produc-tion reacting to curtailment or enhancement. This block is most complex and has had the most work put in.

At first, there was a need for a state space representation of a wind power plant. In this project a resulting wind power state space, from a recent master thesis on wind curtail-ment[23], and placed inside a state space block in SIMULINK. The wind power plant rep-resented in the state space is a power plant from a wind farm at Gotland in Sweden. The input u(k) is a value in kilowatts. The power plant can be controlled by sending a percentage value of maximum rated power in kilowatts. The output from the state space, y(k), gives a representation on how the wind power plant is reacting to changing power production. The following state space parameters

x(k + 1) =    1.689 −0.7077 1 0   x(k) +    0.125 0   u(k) (3.2)

(35)

y(k) =

0.1483 0

x(k) (3.3)

were used in the yellow block seen in figure 3.3. The orange block in the same figure repre-sents the PID-controller of the system. The main task for the PID-controller is to eliminate the error between produced wind power and the calculated set point value. Therefore, a feedback loop calculating the difference between the two parameters is found within the block. The controller itself is a premade PID-controller block found in Simulink in which the PID-parameters are inserted. The sample time was set to one second as the wind power system is a relatively slow system.

The last piece of the theoretical model in Simulink was simply a scope to find and analyse how the model was working and how good it was. The inputs to the scope were load, wind power production, maximum wind power production and set point value.

3.1.3 Wind power calculations

The varying wind power production is a signal block in Simulink simulations but in reality and for the PLC code configuration, real wind power calculation formulas were needed. Calculating the maximum power in a wind power plant, the following equations were used

Pgen= Pwind· Cp (3.4)

Pwind= 0.5 · ρAV3Cp (3.5)

where Pgen replaced the signal block from Simulink. The equations (3.4) and (3.5) include

generated power (Pgen), wind speed (V), rotor swept area (A), air density (ρ) and a

max-imum power coefficient (Cp). In this project a Vestas V90 - 2MW wind turbine[24] was

simulated as the varying power production in the system. The maximum power output at 2MW and the rotor swept area was taken from the data sheet and used in the power equations. The maximum power coefficient (Cp) vary at different wind speed but could

(36)

11-12m/s wind speed. For simplicity, Cp= 0.452 was chosen as constant at all times during

the project. The air density was set to 1.23kg/m3and the rotor swept area, as seen in the data sheet of the Vestas V90, to 6362m2_.

The new varying wind power replaced the signal block in Simulink as now varying wind power was a function of wind speed. A knob replacing the signal block made it possible to vary wind speed and see how the system reacts in real time using

Pgen= 0.5 · 1.23kg/m3· 6362m2· V3· 0.452 (3.6)

where wind speed (V) is adjustable.

This kind of wind power calculation was implemented in to the Brodersen RTU when implementing the model in to the real system. When the model was translated to the Brodersen RTU, the idea was to no longer use pre built signals but instead have the controller work in real time when changing wind speed and load.

3.1.4 Brodersen RTU configuration

One of the most important pieces of hardware in this project is the Brodersen RTU. The reason behind this is that the Brodersen RTU is the IED in which the PID-controller is coded and it is also the connection point for all communication in the system as seen in figure 2.4. The main objective for the RTU is to be configured and coded so that it resembles and contains all vital parts of the Simulink model. Using the PLC-programming tool Zenon Logic, the Simulink model could be translated into PLC code for configuring the Brodersen RTU in Zenon Logic. In Simulink there is a wizard program for translating subsystems into PLC-code. Hence PLC-code was generated from Simulink and placed in Zenon Logic. This was made for translating the PID-controller as well as the State space of the windmill. The rest of the PLC-code was written around these two components as represented in the theoretical model in Simulink.

In Zenon Logic the most comfortable way to handle the subsystem blocks from Simulink is to create functions. After translating the subsystem blocks into PLC code, two main

(37)

functions were created which were the PID-controller function and the State space function. By creating functions with certain inputs and outputs, using these functions and deciding the inputs and outputs from the HMI through variables became quite simple.

3.1.5 HMI implementation

As part of the entire project an automated HMI had to be implemented to act as the control station. The idea to create a well looking and easily accessible HMI would create opportunities to standardise a product to use in real-life in multiple substations. The HMI was created in Zenon Energy edition 8.00 and the creation was set up in multiple stages. The first was to create a main frame or page where the whole system was displayed so anyone could see all components part of the system in sort of a single line diagram. Then a control frame and display of important data was created for managing the system. The entire screen displaying data contains output variables of the Brodersen RTU linked with different symbols or numeric displays. As the Brodersen RTU is the main provider of data to the Scada HMI the communication through the IEC 61850-104 it is critical for the HMI to provide the correct information.

Zenon energy provides many different communication protocols and drivers are built-in to support standardized communication such as the IEC 61850-101/104. This means as the Brodersen RTU and the created HMI used IEC 61850-104 communication, a simple driver could be created in Zenon Energy for translating all variables. The only condition also needed was to set up the correct IP address of the Brodersen RTU to the computer containing the HMI.

The SAS bus coupler was set up using a SCD configuration file and a web HMI. The SCD file was created in an IED configuration software called "PCWORX IED CONFIGURATOR 1.0". In the Brodersen RTU an ethernet port was configured to the right IP-address via a web HMI to connect to the SAS bus coupler. A built in driver for IEC 61850-104 was set up in the RTU32M PLC which then was configured with the SCD file and IP-address of the SAS bus coupler. The communication between the SAS bus coupler and Brodersen

(38)

RTU32M was successful. To make it even more easy, while developing the HMI, a simple ethernet cable was used to establish communication between the Brodersen RTU and the SAS bus coupler.

As the project never reached real-life testing, due to time issues, different knobs on the SAS bus coupler and artificial knobs in the HMI were implemented instead. The knobs in the HMI would act as input data to the system such as load changes and wind speed changes. A SCD file was created to use the real input sockets to the bus coupler and then translated through the Brodersen RTU all the way up to the HMI. The reason behind this is to create a "plug-and-play" product so that when finished, the IEDs and HMI could work if implemented in a real system. Therefore the SCD file for configuring the I/Os of the SAS bus coupler were implemented as if real with logical nodes measuring magnitudes. These were then sent up the system through communication but simulated in the HMI through knobs.

Other work on the HMI was done to make it easy to read and operate. A Techinova demo template was supported by the company to have the same framework as the company has in other products. Using the Techinova template, a design which fit the project was constructed. The lay-out was made so every part of the screen has a symbol with a text explaining what data to expect from the section. A menu was implemented with the option to change screens and navigate around the HMI. A login option was also implemented where if logged in, one would have more access to run simulations and make changes. The actions a logged in member can perform depends on the user and can be altered by an admin with ease. Some other minor implementations are Day/Night mode which changes to background and text colour as well as project information and updates.

(39)

Figure 3.4: The SCADA HMI operational frame

As seen in Figure 3.4 there are multiple parameters, graphs and knobs representing dif-ferent areas of the system. One of the main indicators of the system is a green/red indicator showing whether the communication in IEC 61850-101/104 is online or not. Before the green lighting is shown, communication is offline and the system will not work as intended.

(40)

Figure 3.5: The Scada HMI Block diagram with the option to change PID/State space parameters

The idea of having a Block diagram screen was mostly to show the operator how the controller and system is configured. Besides that, variables connected from the HMI down to the Brodersen RTU makes it possible to change the state space and PID-controller pa-rameters. The main idea behind this was to also make the Scada HMI a plug and play product for many different locations and systems.

Two more functions implemented in the Scada HMI is the Chronological Event List(CEL) and the Alarm Message List(AML). The implementation of these two lists are to always keep track of changes and events made in the system. In Zenon energy edition, it is easy to implement such lists as they are pre-made templates that can be inserted into the HMI. The CEL shows commands made by an operator but what information being presented in the list can be altered in the settings. By keeping track of all commands made and even which operator who did them, a new operator can easily follow what has been done in the system. In this project, the CEL was mostly used to find out which operator that logged in,

(41)

restarted the operation, if simulations have been made in "Simulation mode" and changed PID/State space-parameter values. The CEL log changes can be seen in figure 3.6.

The AML has the purpose of displaying alarms set by the constructor and warns whether alarms have been reached. The idea of having this AML is to be able to troubleshoot easier as the alarms are saved and displayed in the AML. For this project, whenever the PID-controller is needed to balance the system an alarm is set and listed in the AML. This way an operator can always see at what time and in which way the wind power production was curtailed by the system.

Figure 3.6: CEL in the HMI

3.1.6 Lab environment

The lab environment created connected all the previous mentioned hardware together us-ing the designed communication for each part as in 2.4. Added in this lab environment simulation was the windmill which were simulated in an Arduino that interacted with the automation signals returning the value from described in the state-space representation of controlled system used during theoretical model testing.

(42)

Figure 3.7: System overview with connected Arduino Uno

To be able to simulate and continue developing the PID-controller for the system, the arduino was coded to act as the wind mill described by the state space model of equations (3.2) and (3.3). The Arduino could then be connected to the Phoenix Contact as a real wind power farm or plant would be in real-life. The arduino was placed in the system overview as seen in the above Figure 3.7. The reason behind configuring an Arduino to act as a windmill was to see if the rest of the system communication and the PID-controller worked as intended. Therefore, data was sent from the Arduino containing a simulated power production, wind speed and load. The control signal will run through the Brodersen RTU containing the PID-controller and then sent back and the Arduino will react as a wind power plant. This way the controller can be optimized after analysing the results.

3.1.7 Arduino UNO set up and communication

The Arduino UNO was added to the project to have the state space added into the project externally as a physical device. The communication from Brodersen were not able to send an analog signal to represent the output value from the simulated windmill directly, there was need for a solution of sending digital signals over to the Arduino and it reading the values from the Brodersen 8 digital I/O. The Brodersen Digital I/Os were sending a 24 V

(43)

signal, the limit voltage for an Arduino UNO is around 5V which lead to the use of voltage divider system with the use of resistors. Added to the system was the load and wind speed controlled via knobs from an external system seen in 3.8.

Figure 3.8: The arduino set up

The communication needed to be transferred via digital signals from the Phoenix contact IED to the Arduino UNO. The output value from the PID, u(t), were recalculated into 8 bit digital output by an algorithm created in the structured text code A.7. The value was between 0 and 255 using a decimal to binary algorithm seen in appendix A.1. Likewise the signals read by the Arduino, a combination of analog and digital read functions, reversed the digital signals and remade it to decimal again seen in the Arduino code. The Arduino received the power out signal and sent it through the state space. The state space out signal, y(t), was again sent back to the phoenix contact which read the Pulse width modu-lation(PWM) output signal from the arduino later to be converted to the correct numeric value in the PLC code as seen in 3.9.

(44)

Figure 3.9: Full schematic of wind power communication and functions

(45)

4. Results and Discussion

The results are taken from tests made on the theoretical model developed in Simulink and then later the lab environment model set up as seen in 3.7. From the lab environment there is the simulation and real mode.

4.1 Simulink model

To test the model built during the project there was standard tests developed which would check all the extreme cases. This is to assess if the logic of the Simulink model is correct. The model was set to discrete time steps with an interval of 1 second as the system was determined to not need a faster interval.

4.1.1 PID tuning

Following instructions used in Tuning, 2.7.3, the Kp, KI and KDparameters were obtained,

further tested and tweaked to obtain better results with a standard step response of the wind power going from 0 to 100 kW.

(46)

Figure 4.1: Step response

The case has used the previous defined limitations of a minimum 30 % and 30kW power coming from the grid with the same state space. The step response case is where wind power goes from 0 to 100 kW with a load of 100kW forcing the PID to regulate down. The parameters used for the Simulink model were:

• KP = 5

• KI = 0.31

• KD= 10

4.1.2 Increase of wind, constant load

When the wind power production is large enough to exceed the ratio of variable power and grid power, the PID-controller is regulating the wind power production towards the set value. The set value is calculated to be within the ratio of variable wind power production and grid power.

(47)

Figure 4.2: Overproduction of wind large load

When the wind power is not producing enough to reach critical levels the DC-system is providing the rest of the power as seen in Figure 4.2 in the first 100 sec of the simulation. Extreme cases that may occur is when the load is small. One of the conditions is that a minimum of 30 kW from the grid is to be transferred to keep the frequency stable.

(48)

Figure 4.3: Overproduction of wind with small load

As can be seen in 4.3 the wind power is constantly trying to regulate down to reach the level of power needed to be provided from the DC-link.

Seen at around 80s and 120s in Figure 4.3 the curves look identical and it is the same amount of increase in wind power meaning that the PID works the same at different wind power and times, which is a goal as well as the PID resets and can react to new cases without oscillation.

4.1.3 Variable load

The system is designed for the difference between the load and wind power to constantly regulate itself to the correct position with as much utilization of wind power as possible. this shall happen with a variable load as well.

(49)

Figure 4.4: Overproduction wind with a variable load

This is seen as possible in the created system and successfully achieved seen in Figure 4.4.

4.1.4 Variable Load variable wind

(50)

Figure 4.5: Variable wind and variable load

As one of the most important aspects of the PID is not to run away and start oscillating. this does not happen in the variable wind and variable load case.

4.2 Lab simulation

With the simulation mode activated, results were noted down on how communication, PID-controller and the general system was working. During simulation mode, only communi-cation between SCADA and the Brodersen RTU was connected. Seen in figure 4.6 the simulation mode of the product is initiated and the system starts to simulate values where the knobs declare variables instead of analog inputs. A data set of real analog inputs could be implemented but was never chosen due to time issues. At the red line, the simulation mode is initiated and the on and off button is within the red square in the figure.

(51)

Figure 4.6: Simulation during normal operation with increasing wind at steady load

4.2.1 Increasing wind speed, constant load

In figure 4.7 was the first test to note that the system was responding as expected. The communication was responding in real time and parameter changes during simulation mode worked as expected.

(52)

4.2.2 Fast increase of wind speed

In figure 4.8 a normal operation state was simulated. A few changes in wind speed during steady load was simulated and the system was responding as expected. The controller limited the output of the wind power plant in a satisfying way when variable power ratio to grid power was exceeded. As seen in the Figure, at a few increases in wind speed the controller may have been a bit to fast leading to overshoot in the system.

Figure 4.8: Simulation during fast increase of wind speed at steady load

4.2.3 High wind speed, increasing load

In figure 4.9 a normal operation was simulated once more. Steady wind speed with an increasing load, the PID-controller responded as expected. As the load increased and the variable power to grid power became greater, the controller was pushing the wind power to produce more as no violations were exceeded.

(53)

4.2.4 High wind speed, decreasing load

Figure 4.10 in contrast to the previous increase of load, here the load was decreased to trigger violations in variable power to grid power ratio. In this case, the controller was pushing the wind power production down as load decreased and triggered violations. This was expected from the system and the results were pleasing.

Figure 4.10: Simulation during high wind speed with decreasing load

Overall, the simulation mode worked as intended and the PID-controller was fast enough to react to load and wind speed variations. The plug-and-play idea of the simulation mode made it simple to change the parameters of the PID-controller to perform further testing and improvements on the controller. The communication between the HMI and Brodersen RTU was working as intended and never lost contact.

4.3 Lab environment

The lab environment measurements were taken from the SCADA system with every value taken and calculated from external sources in the Brodersen PLC. This result can be saved and stored externally if needed but since the focus is a general approach where specific values is not important, a screen shot from the SCADA program was satisfactory for the graphical representation.

(54)

4.3.1 Decreasing wind speed, decreasing load

The first test environment is where the wind speed starts high and decreases. In figure 4.11 around 13:29:00, there can be seen a decrease in the set value of the wind which results in decrease of wind production. To compensate the grid is increasing power availability. This system is made for the load to keep constant at 2000kW

After 13:29:10 one can see that the load has decreased. This leads to decreased power from the grid and since the wind power is already producing at maximum capacity it is not changing the production at all. This satisfies the criteria for wind power to be prioritized if available.

Figure 4.11: Graph of low wind speed, 1 kW load

Towards the end of the graph in figure 4.11 the set value never reaches a steady state but changes slightly around the wanted set value and never reaches a "perfect" state in which the set value and the output is the same.

4.3.2 High wind speed, 1 kW load

Following case is when wind power is available and there is a small load. As seen in Figure 4.12, the results are sub optimal. In the beginning of the graph wind power is available and the wind set value is increasing but it overcompensates and the wind production is producing more power even than the load. To compensate, the wind set point value is decreased and the wind power is controlled down to a too low wind power production value and then it

(55)

repeats.

Figure 4.12: Graph of high wind speed, 1 kW load

4.3.3 High wind speed, 2kW load

Last case is with high wind speed and high load, as in previous case, this results in Figure 4.13 are similar, the wind set value is trying to increase the wind power but it overcompensates and does not seem to find a stable point repeating the similar pattern of oscillating,

(56)

5. Conclusion

5.1 Simulink model

The Simulink model was designed to represent the real system specifications. The system with its logical conditions was successfully replicated. The important of the tests were for the PID to function correctly weighting the quickness of the system and still stable. The importance of a stable PID in wind power made it necessary for a slower than a fast system. The cases were made to be extreme were the load or wind may jump a big portion of the previous value. The PID and system still behaved to a satisfactory degree.

Using a model to understand the problem is a good way to approach it. Using the graphical programming in Simulink is an easier method to obtain the understanding. With the logic figured out and the test cases the exporting from the model to the lab environment became an easier task since there where tools that could convert Simulink code into PLC-programming used in the later models.

The conclusions that can be made from the Simulink model is that a system designed to constantly prioritize the wind power over the electrical power from the grid is hard to design without flaws. Problems occur due to an unbalanced load and since the wind power may be increasing or decreasing in an unwanted fashion there will be situations were the production and consumption of power is not balanced which is unwanted.

(57)

5.2 Lab simulation

The work completed with the simulation mode of a micro grid where a varying power pro-duction, grid power and a load are present, the simulation mode can be used to evaluate that particular system. The resulting product can be seen as a plug-and-play for any micro grid system uses. For this project, lab simulation results were satisfactory as the system set up, communication and HMI all worked as intended. The idea of having a simulation mode in the first place is to be able to test a system before plug-in and activating it in real-life. The figures in section 4.2 shows that in theory the product is ready for implementation in a real-life system.

Unfortunately the redundant TechiNode system was never implemented and tested. But as the purpose of implementing the TechiNode system is only to transfer data with re-dundant communication, the system would still produce the same result. The reduntant communcation is hence a saftey precaution for the entire system.

5.3 Lab environment

The hardware used to set up and to build the lab environment in this master thesis was not ideal for analog automatic control. The Phoenix contact SAS was not able to send an analog signal representing the calculated control signal from the Brodersen PLC. The solution implemented by converting the set point signal to 8 binary signals and then converting them back in the Arduino is an unnecessary step resulted in a noticeable time lag around 1 second. This is a fundamental failure in the description of the master thesis and project plan and should be avoided by using more suitable equipment.

The Lab environment results are unsatisfactory, the aim was for the system to be stable through all cases, this was not reached. In some cases the system worked as planned but that is not good enough to be implemented in a real system.

The unstable nature of the PID being used in the Lab environment can be explained by several factors, firstly the PID parameters may be wrong and hence the instability. This is

(58)

unlikely since the same parameters was used in the lab simulation and similar oscillations did not occur.

Most likely there is a problem with the communication, graphically explained in Figure 3.10 the communication goes through 4 conversions. There is not only an algorithm calculating the binary value output which when controlled took around one second to change, but also an analog signal sent out from the Arduino as a PWM-signal. This signal is measured by the Phoenix SAS with a range from 0 to 5 with increments of 0.25V. In total there can be a maximum of 20 different values from the wind power production output. With this resolution there seems to be a too big difference from the set and output value and the PID is spinning away and creating an oscillating system. This is more prevalent when there is a large quantity of wind power available and the system is changing larger values leading to bigger faults that is not compensated for.

(59)

6. Future work

6.1 Simulink model

The Simulink model were made to have a broader understanding of the project, future work on the model is not an important part for the development of this project to be implemented. What could be interesting to further work with is to implement "fail proof" safety limits i.e. the wind power can never go under 0kW or set the limits of what is an actual possible wind power production or load for better simulation environment.

There is room for improvement in the general function of the Simulink model with how the PID works. When transferring the parameters at face value from the Simulink model to the simulation and lab environment did not give the same results.

Since this model is built on a smaller grid the electrical frequency increases when power production is too high and the electrical frequency decreases when the power is too low. One might create a system where the wind is trying to balance out the power consumption and production over time to be stable. meaning that an overproduction of wind for a while when the wind is increasing, increases the electrical frequency, one might later decrease the wind production over time until the electrical frequency is back at 50 Hz.

6.1.1 Automatic control

The automatic control used during the thesis is simple and did not become the main focus. An improved model of the Simulink model would implement several different varieties of

(60)

PID control, i.e. being able to go into several different PID parameters depending on the wind power or the power consumption or model predictive control.

6.2 Lab simulation

The Lab simulation in this project were developed to a satisfactory degree, there is always room for improvements in the HMI and PLC-coding. Making the user interface easier and more compatible for new users, implementing an easier way to record and store data, adding an additional simulation mode between using the knobs from the equipment but not communicating with the simulated variable power plant, keeping it in an simulation mode.

6.3 Lab environment

In general there is always room for improvement to replicate a real model, the model used can be improved to reach a better representation and more accurate results.

6.3.1 Communication

There is potential to fully implement the Techinode solution with radio communication from the PLC to the Phoenix IED. The SCADA system can receive the signals and able to switch the communication from IP to radio when one is lost. This was not implemented due to time constraints.

The communication between the Phoenix contact to the Arduino UNO was made with binary signals and returned in an analog read value. In future work we highly recommend improving this communication process. Preferably sending an actual digital signal with normal IP communication to recieve the information in the Arduino. Furthermore the return signal, wind mill output, increasing the resolution. This may be fixed to have a larger span of the voltage out from the arduino or other windmill representation.

The overall communication can also be improved by the use of a more stable communication forms than used in this project, instead of binary and digital signals being sent to the wind

(61)

mill, having correct equipment meant for sending and receiving analog and digital signals since that is not the primary purpose of an Arduino.

6.3.2 Equipment

The equipment used in the thesis can be improved, in general having a digital state space on an Arduino UNO is not necessary. In ideal conditions there would be a physical device in form of a synchronous motor which can simulate the real conditions even better. Using this would had created a better understanding and sending the correct information that is needed to regulate an electrical machine in any form.

(62)

Bibliography

[1] _{NASA. Global Temperature. url: https : / / climate . nasa . gov / vital - signs /} global-temperature/. (2020-02-20).

[2] _{United Nations. The Paris Agreement. url: https://unfccc.int/process-} and-meetings/the-paris-agreement/the-paris-agreement. (2020-06-04).

[3] _{Vattenfall. Tidig vindkraft. url: https : / / historia . vattenfall . se / sv / from} -hydro-power-to-solar-cells/tidig-vindkraft. (2020-06-04).

[4] _{Nilsson Jonas. Vindkraft. url: https://www.gotland.se/76458. (2020-06-04).} [5] Ching-Lai Hor and Peter A. Crossley. “Knowledge Extraction from Intelligent

Elec-tronic Devices”. In: (2005), pp. 82–111. doi: 10.1007/11427834\_4. url: https: //doi.org/10.1007/11427834%5C_4.

[6] _{PHOENIX CONTACT. Bussanslutning - AXL F BK SAS - 2701457. url: https:} //www.phoenixcontact.com/online/portal/se?uri=pxc- oc- itemdetail:pid= 2701457&library=sesv&tab=1. (2020-06-04).

[7] _{Arduino. ARDUINO UNO REV3. url:} https://store.arduino.cc/arduino-uno-rev3.

[8] _{Arduino. Arduino Uno Picture. url: https : / / content . arduino . cc / assets /} Pinout-UNOrev3_latest.png. (2020-05-22).

[9] _{Inductive Automation. What is SCADA? url: https://www.inductiveautomation.} com/resources/article/what-is-scada. (2020-06-05).

Automatic control of renewable energy sources at varying load

Examensarbete 30 hp

Juni 2020

Automatic control of renewable

energy sources at varying load

Patrik Zenkert

Douglas Lowén

Abstract

Automatic control of renewable energy sources at

varying load

Patrik Zenkert, Douglas Lowén

Populärvetenskaplig sammanfattning

Acknowledgements

List of Acronyms

Contents

1. Introduction

1.1

Description and background

1.2

Purpose

2. Theory

2.1

IED

2.1.1

Brodersen RTU32M

2.1.2

Phoenix Contact SAS

2.2

Arduino

2.3

SCADA and HMI

2.3.1

SCADA

2.3.2

Zenon Energy

2.4

TechiNode

2.5

Protocol

2.6

IEC 61850

2.6.1

Logical node

2.6.2

IEC 60870-5

2.7

Automatic Control

2.7.1

PID

2.7.2

State-space representation of a controlled system

2.7.3

Tuning

3. Implementation

3.1

Model

3.1.1

Original

3.1.2

SIMULINK model

3.1.3

Wind power calculations

3.1.4

Brodersen RTU configuration

3.1.5

HMI implementation

3.1.6

Lab environment

3.1.7

Arduino UNO set up and communication

4. Results and Discussion

4.1

Simulink model

4.1.1

PID tuning

4.1.2

Increase of wind, constant load

4.1.3

Variable load

4.1.4