1
Real Time OpenDSS framework for Distribution Systems Simulation and Analysis D. Montenegro, Student Member, IEEE, M. Hernandez and G. A. Ramos, Member, IEEE
Abstract— Advanced Distribution Automation (ADA) has become a topic of considerable interest in the electric power industry; moreover, for the development of ADA it is necessary to build new methodologies and computational tools to support the distribution networks (DN) simulation with Real Time Hardware in the Loop (RT-HIL) techniques, reducing the design and testing times at low cost. OpenDSS is a free powerful software platform to simulate DN including the models for distributed generation; the RT-HIL systems improve the OpenDSS capabilities, interfacing the data delivered for this platform using analog and digital signals in Real Time (RT). This way, the design engineer and external hardware can interact with the DN like in the real scenario switching and analyzing the response of the system. As result, in this paper the Real time analytical simulation of the IEEE 13 Nodes system is presented; this with the aim of evaluating the performance of the developed tool. All the developments were made using National Instruments Real Time hardware architectures, OpenDSS software and the LabVIEW® RT software. Finally, the different possibilities with the developed tool and the future developments are presented. Index Terms— Advanced distribution automation, distribution networks, openDSS, real time, simulation.
R
I. INTRODUCTION
time (RT) simulation systems are a key tool for the analysis in electrical engineering; moreover, these systems allow validating designs and decision making with real simulated scenarios generating and reading signals to interact with external equipment [1]. There is a considerable interest in electric industry in computer aided engineering that support rapid development of methodologies, technologies and solutions to the actual challenges in this field [2]. For this reason, the design and operation engineers must be complemented with tools that allow them to be closer to measurements found in real controlled scenarios at low cost. The difference between classic simulation software and real time-hardware in the loop (RT-HIL) simulations [2] - [3] , is the capacity of the RT-HIL simulators to generate and measure signals that can interact with external equipment. EAL
D. Montenegro, M. Hernandez and G. Ramos are with the School of Engineering, University of los Andes, Bogotá, Colombia, (e-mail:
[email protected];
[email protected];
[email protected] ).
The controlled signals generated by the RT-HIL system allow reducing the time needed to evaluate the distribution network (DN) response into a certain scenario using external equipment improving the quality of the simulation [4], [5]. The RT-HIL simulation becomes matured and provides better computational efficiency, flexible and scalable programming, and preserves a preciseness as good as conventional off-line simulation [1]. To simulate the behavior of a DN, the OpenDSS simulator has been used. In contrast with other simulators, OpenDSS includes all the different needs to simulate unbalanced DN including distributed generation. Other characteristic of the software is that it includes a COM interface to communicate with other applications; giving a powerful flexibility and the possibility to modify the source code. The aim of this paper is to present the exceptionally good performance of the OpenDSS running under a RT environment, the different possibilities around this kind of simulation and the developments. The software interface has been selected according to the multi core processing capabilities of the cRIO 9082 to reach the best performance with this hardware platform. This paper is divided in four parts, the first one is the description of the system architecture and technical parameters, the second one presents the COM interface and the data processing delivered by the OpenDSS, the third one presents the results of simulating the IEEE 13 nodes system with user interaction and finally, the conclusions based on the developed work and the future developments are presented. II. SYSTEM ARCHITECTURE The main characteristic of RT hardware is the concurrence of process; this is possible because the RT hardware is a multicore architecture which allows dedicating a single core attending one task in an exclusive way. The general capabilities of RT hardware can be seen in Fig 1. The RT hardware incorporates a programmable Spartan FPGA that provides the possibility of programming hardware sentences using the graphical interface of LabVIEW® FPGA. The cRIO 9082 counts with an Intel Core i7 main processor (2 cores and 4 threads) at 1.33 GHz to attend the operative system (OS) and the programmed tasks using the NI LabVIEW® software running into an embedded OS like Windows 7 embedded (WES7) that is an alternative to the LabVIEW® RT software.
2
Fig. 1. General architecture of the cRIO 9082 RT hardware.
The Hardware can work under LabVIEW® RT 2011 OS too, but for this development the WES7 and its power of the embedded graphic interface for user interaction were used. The FPGA allows defining hardware to attend processes in deterministic time cycles, so the parallelism between different tasks like data acquisition or signal generation can be attended by hardware. One of the advantages working in the WES7 OS is the fact that with this option there is no need of an external computer to program the RT hardware, all the programming can be done directly in the RT hardware, giving more autonomy to the programming and debugging process. Given the hardware capabilities it is possible to dedicate each core to 1 very complex process to guarantee his completion in deterministic computing cycles; moreover, it is possible to complete up to 4 very complex processes in parallel (4 threads) in deterministic computing cycles without affecting the data acquisition/generation stage that runs under the FPGA. III. INTERFACING OPENDSS AND LABVIEW® OpenDSS counts with a COM interface to interchange data with external applications; this interface is a set of methods and properties to interact with the OpenDSS engine in different modes [6]. The general procedure to interact with the COM interface can be seen in Fig 2. The method X refers to one of the different methods included in the COM interface of the OpenDSS; the same case applies to the property Y. The base version of LabVIEW® includes a connectivity library to connect ActiveX objects; as result, the connection with the COM interface do not requires additional toolkits or software licenses. Although the process time depends of the type of method or property invoked the execution time is exceptionally good. In Table I the computing times measured for different methods and properties are presented. To obtain the results of Table I the mentioned methods and properties has been used to solve the unbalanced power flow for the IEEE 13 nodes system in the cRIO 9082 sending requests from LabVIEW® to OpenDSS. The COM interface counts with the Command property to send direct commands to the OpenDSS engine like in the OpenDSS executable.
Fig. 2. General procedure to interact with the OpenDSS COM interface.
The system solution data have to be requested using the Command property; for example, when the SolvePF method is applied to the test system, which solves the power flow iteratively, the power in each line is requested separately and adjusted to the main system format. To complete this request it is necessary to invoke various methods and properties; the algorithm to request this information is shown in Fig 3. The total computing time requesting the power flow method results takes less than 2 ms to be executed; this value is calculated counting the amount of processing cycle ticks accumulated from when the routine starts until it finishes. Because the computing cycle frequency is known, it is possible to translate the counted ticks to a time value as shown in (1). In this expression Nt is the number of ticks counted and Cf is the average computing cycle frequency. Compared with a desktop PC, the time needed to execute the SolvePF method in the RT hardware platform is nearly to the half of the time obtained in the desktop PC as shown in Table II. This result is possible due the dedicated processor for each task of the RT hardware. The obtained data confirm the good performance of the LabVIEW® and OpenDSS applications working together. ∗
1
1
TABLE I COMPUTING TIMES MEASURED FOR DIFFERENT OPENDSS METHODS AND PROPERTIES
Type of procedure Method Method Method Method Method Method Property Property Property Property
Name
Duration (ms)
Start Text Solve SolveDirect SolvePF ActiveCircuit AllBusVolts AllBusVmasPU AllBusNames Command/Result
