Part 5 of the IEC61400-25 series is dedicated to conformance testing. Lots of tests are involved when developing a complete system until it is running properly and satisfying the specified requirements. Testing a complete system involves several kinds of tests. Some of the tests can be completed during the development process, while others must be performed upon completion of the system. The completed system should be tested successfully against all the proposed tests. What to test for varies a greatly but the most common attributes a system should have include capability, reliability, efficiency, portability, maintainability, compatibility and usability. This thesis is about a prototype, and as such it is not intended as a complete system. The prototype is mainly to test aspects of a complete system. In order to create a final system more formal requirements must be specified, and the system should be designed in order to meet those specific requirements.
Part 5 proposes various test procedures in order to make sure the system operates properly according to the IEC61400-25 standard. However, all the procedures involved in the conformance tests are not conducted under the development cycle of this project. This would be far too unrealistic with the limited resources available.
The tests conducted for the developed prototype are limited to the functional testing of the services offered and general unit testing during development of the prototype. The aim of functional testing was to test whether the service methods operated as they should with proper request and reply objects.
Functional tests applied on the service methods also reflect the inner state of the server which makes it possible to trace behaviors of the system under certain conditions which will lead to further structural testing procedures. However the main focus is on functional testing.
In Part 5 of the IEC61400-25 series abstract test cases are defined to test a server.
The structure of the server test cases is as follows:
a) Documentation and version control b) Data model (IEC61400-25-2)
c) Mapping of ACSI models and services (IEC61400-25-3); the corresponding sub clauses that define the abstract test cases are listed below:
• Application association.
• Server, logical device, logical node, and data model.
• Data set.
• Reporting.
• Logging.
The tests conducted for the prototype mostly covers part b) and c) of the list above. The service methods through which the tests are conducted are listed below.
• Logon
• Logoff
• GetServerDirectory
• GetLogicalDeviceDirectory
• GetLogicalNodeDirectory
• GetAllDataValues (Not implemented)
• GetDataValues
• SetDataValues
• GetDataDirectory
• GetDataDefinition
• GetDataSetValues
• SetDataSetValues
• CreateDataSetValues
• DeleteDataSetValues
• GetDataSetDirectory
• Report
• AddSubscription
• RemoveSubscription
• GetBRCBValues
• SetBRCBValues
• GetURCBValues
• SetURCBValues
• GetLCBValues
• SetLCBValues
• QueryLogByTime (not implemented)
• QueryLogAfter (not implemented)
• GetLogStatusValues (not implemented)
Each test clause is divided into two groups as Positive and Negative test cases.
Tests grouped under Positive are test cases where the result is successful whereas negative test cases results in non successful responses. Please refer to the appendix for the relevant test results.
The service tests conducted show that the implemented service methods can generate the expected responses with the correct data types defined for the services. This implies that the business logic executed on the server is correct as well.
Chapter Summary
In this chapter different case studies have been conducted. This is done to make sure that the system meets the requirements defined in Chapter 2.
In the system a wide range of things have been addressed, and a proposal has been presented. It is hard to say if the choices will meet requirements in a real system, unless more formal requirements have been defined, however the case studies do show preliminary success at the conceptual level.
Chapter 5
CONCLUSION AND FUTURE WORK
The goal of this thesis was to implement and test an IEC 61400-25 compliant generic server which will be used to monitor and control wind power plants. During the development of the server there has been no opportunity to test and develop against a real wind power plant device. Instead of working against a real device, a basic device simulator has been created to create a minimum environment to develop a prototype and test it.
The evaluation of the standard is made through the degree on how successful the developed system is working. That is, only the developed communication system has been considered as a base when evaluating the standard. Specific details within the general wind power plant domain are not considered since that is beyond the scope of this thesis. For example, the real behavior, constraints and limitations of a WPP are not reflected in this study.
The main focus has been on the server system and its interaction with clients through the specified web services defined in IEC 61400-25-4. When developing the server system, general considerations such as security and modularized software architecture have been taken into account and implemented, wherever applicable.
From the requirements outlined in chapter 2, a prototype has been implemented and four case studies have been conducted in order to verify that the system meets the specified requirements.
5.1 Chapter summery
Chapter 1
Chapter 1 presents the motivation for having a platform neutral communication and control system for wind power plants. At the same time it argues that such an approach has value in order to communicate without vendor boundaries. It is shown that this is one of the main building blocks towards a large scale monitoring and control of the power grid.
Chapter 2
Chapter 2 presented the architecture of the system and the data model that the system should be in conformance with together with a conceptual model defining the modules constituting the system. Through the analysis it was specified that the system must provide the following features:
• It must represent the wind power plant information model as defined in IEC 61400-25-2
• It must be comprised of replaceable modules.
• It must exhibit secure web service communication between client-server and the different modules the prototype is comprised of.
• It should be an easy to configure, modular architecture.
• It should have the capability to handle data in a way that ensures maximum throughput.
.
Chapter 3
Chapter 3 presents the arguments for using SOA and web services for the prototype implementation. Then a description of what can be expected from the use of today’s standard web services is presented followed by a discussion on how it is handled by Windows Communication Foundation (WCF). WCF was chosen a development platform using .NET C#.
Chapter 4
Chapter 4 presents case studies, where it is demonstrated that the prototype system is capable to work under different conditions. This chapter also describes how the involved modules are implemented together with their capabilities.