Deployment of IEC61400-25-4etd.dtu.dk/thesis/221247/ep08_53.pdf · Master of Science Deployment of...

A Thesis Submitted for the Degree Master of Science

Deployment of IEC61400-25-4 -

Mapping to Web services on an industrial PLC platform.

Author: Thomas Køhrsen

Supervisiors:

Bjarne Poulsen & Knud Johansen

Kongens Lyngby 2008 IMM-M.Sc.-2008-53

Deployment of IEC6100-25-4 - Mapping to Web services on an industrial PLC platform

June 2008

ii

Technical University of Denmark Informatics and Mathematical Modelling Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected]


June 2008

iii

Abstract In the resent times wind power plant vendors have showed increasingly inter-est in the international standard IEC 61400-25 for communication, monitoring and controlling of wind power plants. Before this vendors had their own speci-fication on how to communicate, monitor and control. But due to rapid marked growth and demands, standardizing in this field is crucial for further expansion. Previous thesis’s by Andreas Kargård Olsen, Baris Özdil and Umutz Kork-maz has done various concept proofing of the IEC 61400-25 standard. This thesis builds on top of these and moves the domain from standard PC’s to industrial PC’s. The industrial PC being a Brodersen RTU 32 running windows CE v5.0 as an operating system. The implementation language is C# running in .NET com-pact framework 2.0. The program is a simple server, compiled of various modules ranging from information model, communication profile, client handling and user association verification. The communication part is mapped to web services as of part 4 annex A in IEC 61400-25. On the client side a dynamic link library (DLL) act as a configurable proxy stub to all IEC 61400-25 servers implementing web services as communication profile. This DLL is tested by the conformance tests as of part 5 of the IEC 61400-25. The testing method used is based on test driven development, and incorpo-rates unit tests.


June 2008

iv

Preface This report is the product of the master thesis submitted for the master degree of computer science at Technical University of Denmark, DTU juni 2008. This master thesis has been conducted in correlation with department of Informat-ics & Mathematical Modelling (IMM), Centre for Electric Technology (CET) and wind power plant manufacture Gamesa. Bjarne Poulsen (IMM), Knud Johansen (Gamesa) has been project advisors on this thesis. Special thanks to Brodersen Controls for supplying industrial PC hardware and to Beggi Oskarsson from Brodersen Controls for technical support on RTU32 unit. This thesis has been carried out in the period from October, 2007 to June, 2008


June 2008

v

Table of contents 1 INTRODUCTION ......................................................................................1

1.1 Back ground & Motivation..................................................................1 1.1.1 Environmental aspect .................................................................1 1.1.2 Business aspect .........................................................................1 1.1.3 Technical aspect.........................................................................2

1.2 Main problem and starting point ........................................................3 1.3 Vision.................................................................................................4

1.3.1 The grand vision .........................................................................4 1.3.2 The personal vision ....................................................................4

1.4 Project descriptions ...........................................................................5 1.5 Report outline ....................................................................................6

2 ANALYSIS................................................................................................7

2.1 The IEC 61400-25 standard - State of the art....................................8 2.1.1 Previous work and general principles of IEC 61400-25 ..............8 2.1.2 Part 2 of IEC 61400-25, Information Model ..............................11 2.1.3 Part 3 of IEC 61400-25, Information Exchange ........................17 2.1.4 Part 4 of IEC 61400-25, Mapping to communication profile .....19

2.2 Test cases and IEC 61400-25-5 ......................................................20 2.2.1 Incitement for choosing test cases ...........................................21 2.2.2 Testing bench setup .................................................................22 2.2.3 Chosen test cases ....................................................................22

2.3 Brodersen RTU32............................................................................25 2.4 Specification and requirements .......................................................27

2.4.1 IEC61400-25-3 Client framework .............................................27 2.4.2 IEC 61400-25 Server................................................................27 2.4.3 Simple web server ....................................................................27 2.4.4 IEC 61400-25-5 conformance testing .......................................27 2.4.5 Wind Power Plant Simulator .....................................................27

2.5 Sub conclusion ................................................................................28

3 DESIGN..................................................................................................29

3.1 Overall system architecture .............................................................29 3.2 Server design ..................................................................................30

3.2.1 Main server module ..................................................................30 3.2.2 Simple web server module .......................................................33 3.2.3 Service interface module ..........................................................34 3.2.4 Client handling module .............................................................36 3.2.5 Data handling logic module ......................................................38 3.2.6 Type library module (including information model) ...................39 3.2.7 Access control module .............................................................42 3.2.8 Overall Class and sequence diagram.......................................42

3.3 Client framework design ..................................................................44 3.4 Sub conclusion ................................................................................45


June 2008

vi

4 IMPLEMENTATION ...............................................................................46 4.1 XML documents and schemas definitions .......................................46

4.1.1 Creating type safe classes .......................................................46 4.1.2 Serializing and deserializing XML documents ..........................47 4.1.3 Validating XML documents.......................................................47

4.2 Server implementation.....................................................................47 4.2.1 Main server module ..................................................................48 4.2.2 Simple web server module .......................................................49 4.2.3 Service interface module ..........................................................52 4.2.4 Client handling module .............................................................52 4.2.5 Data handling logic module ......................................................53 4.2.6 Type library module (including information model) ...................53 4.2.7 Access control module .............................................................55

4.3 Client implementation ......................................................................56 4.3.1 IEC 61400-25-3 client framework .............................................56

4.4 Sub conclusion ................................................................................58

5 TEST AND PRINCIPLES .......................................................................59

5.1 Test driven development .................................................................59 5.1.1 Software requirements .............................................................59 5.1.2 The test driven cycle.................................................................60

5.2 Unit tests..........................................................................................61 5.2.1 Microsoft unit testing framework ...............................................61

5.3 Test results ......................................................................................62 5.3.1 Manual testing ..........................................................................62 5.3.2 Automated tests........................................................................63 5.3.3 Unit test results.........................................................................63

5.4 Sub conclusion ................................................................................64

6 MAIN CONCLUSION .............................................................................65

6.1 IEC 61400-25 Server .......................................................................65 6.2 IEC 61400-25-3 Client framework ...................................................66 6.3 Future work......................................................................................66

6.3.1 Improvements to the IEC 61400-25 Server ..............................66 6.3.2 Additional improvements to the IEC 61400-25 server ..............67

7 APPENDIX .............................................................................................68

7.1 Original project description ..............................................................68 7.2 Expanded view of information model class diagram........................69 7.3 Type Library module class listing.....................................................70 7.4 XML Schema definitions ..................................................................71

7.4.1 Access control module - UserDataBase.xsd ............................71 7.4.2 IEC61400-25-3 Client framework - configFile.xsd ....................71 7.4.3 Type library module – typeLibary.xsd .......................................72

7.5 XML documents...............................................................................75 7.5.1 Access control module – userdatabase.xml .............................75 7.5.2 IEC61400-25-3 Client framework – wsconfig.xml .....................75 7.5.3 Information model – informationModel.xml...............................76


June 2008

vii

7.5.4 Examples of SOAP service requests and responses ...............86 7.6 Reference list...................................................................................87 7.7 Literature .........................................................................................88 7.8 Software used..................................................................................89 7.9 CD-Rom Contents ...........................................................................89 7.10 Glossary ..........................................................................................90 7.11 Brodersen RTU32 data sheet ..........................................................91


June 2008

viii

List of figures Figure 1 - IEC 61400-25 Domain model ..........................................................8 Figure 2 - System architecture proposal ..........................................................9 Figure 3 - Client domain in this thesis ............................................................11 Figure 4 - Concept of mapping WWP data ....................................................11 Figure 5 - Information model node composistion and example......................13 Figure 6 - General visualization of data model...............................................14 Figure 7 - Concrete example of data model representation ...........................14 Figure 8 - Data Attribute Component and example........................................15 Figure 9 - Data Sets groups object references to visible data........................16 Figure 10 - General protocol sequence..........................................................19 Figure 11 - Intersection diagram: Unit test in this thesis ................................21 Figure 12 - Test bench setup for unit tests.....................................................22 Figure 13 - A Brodersen RTU ........................................................................25 Figure 14 - Project scope...............................................................................27 Figure 15 - Overall system architecture .........................................................29 Figure 16 - Petri net of threading scheme......................................................31 Figure 17 - class diagram for Server module .................................................32 Figure 18 - Form layout of GUI ......................................................................33 Figure 19 - Sequence diagram for simple web server....................................34 Figure 20 - Class diagram for simple web server...........................................34 Figure 21 - Service Interface..........................................................................35 Figure 22 - Sequence diagram of Service interface module ..........................36 Figure 23 - Class diagram for Client handling module ...................................36 Figure 24 - Sequence diagram of client handling module ..............................37 Figure 25 - Sequence diagram of service calls in client handling module......37 Figure 26 - Class diagram for Data handling logic .........................................38 Figure 27 - Sequence diagram for data handling logic module......................39 Figure 28 - Sequence diagram for Non-persistent data set ...........................39 Figure 29 - Class diagram for Information model ...........................................40 Figure 30 - Class diagram for ServerExeption and inheritance......................41 Figure 31 - Class diagram for Access control module....................................42 Figure 32 - Sequence diagram for the Server ................................................42 Figure 33 - Class diagram for the whole server .............................................43 Figure 34 - Class diagram of Client framework ..............................................44 Figure 35 - XML processing...........................................................................46 Figure 36 - States in TDD ..............................................................................59


June 2008

ix

List of tables Table 1 - Difference between RTU32 and Standard PC ..................................4 Table 2 - Common Data Class entries ...........................................................15 Table 3 - Data set category differences .........................................................17 Table 4 - Table of ACSI methods in this thesis ..............................................18 Table 5 - Abbreviated terms used in chosen test case describtions ..............25 Table 6 - IResponder.Responder parameter description ...............................50 Table 7 - Information model names mapped to types ....................................54 Table 8 - Exception Error messages and details............................................55 Table 9 - Test results of chosen IEC 61400-25-5 test cases .........................64


June 2008

1

1 Introduction This chapter describes the motivation and the previously work preformed, to-gether this comprises into the section Back ground & Motivation. The main problem and starting point, is a short description of previous IEC 61400-25 thesis and general key differences. Vision of the project, and comprises of the collective achievements that should be intended to be realized by the end of the project. Report outline, is a short description of the various chapters in this paper.

1.1 Back ground & Motivation

1.1.1 Environmental aspect In the resent years more and more focus has been directed to the claim that the use of fossil fuel and CO2 emissions are contributing to global warming way more than anticipated. One such example is Al Gore’s much discussed documentary “An Inconvenient Truth” As a result of this much heated debate, alternative and CO2 emission free en-ergy will likely gain more and more focus in the following years, as politicians becomes aware of the climate changes in progress. One way of dealing with the ever increasing energy demands and lower CO2 emissions of tomorrow is to harness the power of the wind. Even though the first WPP emerged decades ago, it is only in the recent times wind power has become increasingly more popular both among politicians and power compa-nies. Since then power suppliers have increasingly focused their attention to in-clude WPP as a part of their power grid. According to WWEA [2] the power capacity has grown 988,68% the last 10 years worldwide. From 7.475 MW in 1997 to 73.904 MW in 2006. Further more WWEA [2] predicts that the power capacity will rise to 160.000 MW worldwide by the year 2010.

1.1.2 Business aspect As power suppliers gradually decentralize their power production in the form of wind power, it will also make greater demands to control and monitor WPP farms or singular WPPs. Such systems are in place, but are by no means standardized. Historically, WPP vendors have supplied their own control and monitoring solutions to their product line. Each vendor having their own way of dealing with control and monitoring is by far an optimal solution for power suppliers who own WPPs from multiple vendors. Therefore the IEC has taken on the task to suggest a complete standard for control and monitoring of WPPs.


June 2008

2

1.1.3 Technical aspect IEC or “International Electrotechnical Commission” is a non profit organization, which suggests and publishes international standard for all electri-cal/electronical devices and electrically related technologies. This standard is enumerated the IEC 61400-25 series. The vision of this stan-dard is to make a framework for communication on which vendors of WPPs can standardize the control and monitoring aspect of their products. This is beneficial for both vendors and power suppliers. Power suppliers will get the most benefits, as deploy time is shortened and overall system com-plexity is reduced to a single open standard. The IEC 61400-25 standard series is split into 5 parts.

• Part 1, subtitled “Overall description of principles and models” describes the mere essence of the hole standard. From general WPP properties, to information modelling approach, information exchange, and communication principles.

• Part 2, subtitled “Information models” Is a detailed description of the information model and data structures of the standard. Ranging from abstract WPP logical devices to detailed descriptions of specific WPP component.

• Part 3, subtitled “Information exchange model” describes how information is exchanged and the message sequences to different operational functions. Also including is the mechanisms of report and logging aspect of the standard.

• Part 4, subtitled “Mapping to communication profile” is a detailed describes of various protocol mappings to the information exchange model (part 3) and information model (part 2). The communi-cation protocols described are:

o Annex A: web services o Annex B: OPC XML-DA o Annex C: ISO 9506 o Annex D: IEC 60870-5-104 o Annex E: DNP3

• Part 5, subtitled “Conformance testing”

describes the testing procedures and extensive test cases which must be fulfilled for any product which integrates the IEC 61400-25 standard and to become IEC 61400-25 certified.


June 2008

3

1.2 Main problem and starting point Previous master thesis at DTU has proven the IEC 61400-25 standard in working prototypes. The two contributing thesis’s are:

• Prototype for an IEC 61400-25 Compliant Generic Server [3], dealing with server system design and client interaction. Implementation of modularized software components and general security. Pros and cons for a Service Oriented Architecture (SOA) in 61400-25, and why SOA was chosen as implementation strategy. Four test cases elaborating on different deployment schemes and settings. From cross platform sce-narios, WPP farm setups to protocol configuration. Development re-sulted in a running prototype on a standard PC, supplied with a WPP simulator. Further more part of the thesis was published in the Interna-tional Journal of Distributed Energy Resources [6] as groundbreaking research.

• Reporting and logging in compliance with IEC 61400-25 [4], dealing with the reporting and logging feature of the standard. Two reporting modes where supported namely non-buffered and buffered, used re-spectively in offline and online conditions. The thesis also included an XML based Wind Power Plant Configuration Language (WPPCL), for setting up IEC 61400-25 server information model and general initiali-zation. Development resulted in a running prototype on a standard PC, supplied with a WPP simulator to trigger events for logging and proc-essing.

Common for these thesis are that they where proven on a regular domestic PC system in a laboratory setting operating in a Windows XP environment. In reality this will in most cases not transfer directly to real industrial implementa-tions of the IEC 61400-25 standard. One reason for this is the harsh requirements that industrial PCs must fulfill to be accepted for software deployment. This includes hardware requirements, and quality assuring production methods. Like the ISO9001 certifications. For the sake of argument the following will hold true for the industrial PC RTU32 from Brodersen Controls versus a common home or office PC. In the table below differences from a RTU32 and a standard PC can be reviewed. Property RTU32 Standard PC Processing power 300 MHz 2-3 GHz Memory 64 mb (up to 256 mb) Over 1 Gb Storage 64 mb (up to 512 mb) Over 100 Gb Operating system Windows CE 5.0 Windows XP/2000/Vista .NET version .NET CF1 2.0 .NET 2.0 / 3.5 Web server Basic HTTPD server Microsoft IS2 1 CF is an adverb for Compact Framework 2 IS (Information Server) is an advanced web server from Microsoft.


June 2008

4

Data base None SQL Server Dimensions 189mm * 111mm *

111mm A lot larger

Power usages Max 40 Watt 50 – 120 Watt3 Table 1 - Difference between RTU32 and Standard PC

Source: RTU32 data sheet can be found in appendix 7.11. When examining the table it is obvious that the standard PC is far more pow-erful in every aspect compared. But one must not forget that reliability is a key factor for industry consumers, physical size and power consumption is less. Since this thesis deploys on the RTU32 one must consider performance, and limitations closely when moving implementations from standard PCs to indus-trial PCs. Finally this thesis will mainly build upon the work of Andreas Kargård Olsen & Baris Özdil [3] but will also contain fragments of the work done by Umut Korkmaz [4].

1.3 Vision

1.3.1 The grand vision Bringing the IEC 61400-25 standard into the final stages of concept proofing. Envisioning the IEC 61400-25 standard series running on an industrial PC, serving SCADA clients and hosting real wind power plants data. Data ac-quired from a physical wind power plant interfaces. Long term vision is to break the vendor specific monitor and control monopoly, by showing that open standards as web services can act as communication interface for the IEC 61400-25 standard. Making it easy for power suppliers to incorporate new WPPs from different WPP vendors in their existing power grid and control scheme. Owners of sin-gle WPPs would benefit from this, as hobby programmers or small companies could easily produce simple monitor webpage’s and applications with web service technologies.

1.3.2 The personal vision Creating a prototype system implementation of the IEC 61400-25 standard specifically targeted towards industrial PC’s is the main vision of this master thesis. With special consideration of mapping Web services to communication profiles as described in the IEC 61400-25-4 standard.

3 According to http://www.tomshardware.com/reviews/truth-pc-power-consumption,1707-2.html


June 2008

5

1.4 Project descriptions This project description is an elaborated version of project advisor Knud Johansen project proposal found in appendix 7.1. Previous work has created the basic foundation for the software architecture of a prototype IEC64100-25 server. These concepts are to be analysed and ported to an industrial PC. Which includes the following:

- Study the contents of the IEC61400-25 standard. - Study the work of previous master thesis [3] and [4]. - Port architecture to industrial PC, possible adapt concept to fit software

and hardware environment. The industrial PC is provided by Brodersen controls A/S.

- Study software and hardware environment, and make design decisions on advantages and limitations.

- .NET compact framework 2.0, short comings, and how this influences the design decisions.

Validating the solution against selected conformance test defined in IEC61400-25-5:

- Selecting system crucial test cases from IEC61400-25-5, and driving implementation in a test case driven fashion. Ensuring the developed software meets IEC61400-25 compliance.

Developing interfaces to connect real running wind turbines

- Instead of focusing on WPP simulators, the IEC64100-25 server is to be connected to a WPP situated at Risø.

- Consider interfacing and how to do. Since this is out of scope of the IEC61400-25 standard.

Develop and analyse Web services according to IEC 61400-25-4 Annex A.

- Analyse web services in accordance with .NET CF and the target in-dustrial PC platform.

- Implement a proof of concept web services on the IEC61400-25 server - Connect a monitor and control client via web services to the IEC61400-

25 server. Possible a SCADA client or other kind of web service en-abled client ware.


June 2008

6

1.5 Report outline The main purpose of this report is to document the efforts put into this thesis. The reader should be aware that knowledge of software in general is a per-quisite for reading chapter 3 through 6. Chapters in the report:

- Introduction, Chapter 1: A short appetizer.

- Analysis, Chapter 2: This chapter will focus on key components of the IEC 61400-25 standard. Especially with attention on part 4 of the stan-dard, namely mapping to web services.

- Design, Chapter 3: This chapter will incorporate designs from pervious work, and elaborate on overall software design.

- Implementation, Chapter 4: This chapter emphasizes on how things ac-tually where implemented. Showing code fragments and explaining mechanisms.

- Testing and principals, Chapter 5: This chapter will discuss some of the principals behind Test Driven Development, and applying these to some of the implementation. Further more shows test results, and what was learned

- Main conclusion, Chapter 6: This chapter concludes on the entire pro-ject.

- Future work, Chapter 7: This chapter reasons for unfinished business, and suggests improvements to the current state of the project.

- Appendix, with various documents.


June 2008

7

2 Analysis The intention of this chapter is to analyze the knowledge required which are important to this thesis. Mapping web services to IEC61400-25-4 on an indus-trial PC, places the core knowledge base on the IEC 61400-25 standard. The implementation should therefore consist of the following.

• Previous work • Information model • Information exchange model • Mapping communication profile to web services. • Conformance testing

The information model as defined in IEC 61400-25-2 describes which data the server and client must be able to communicate. Further more, the information model also contain a definition on how data is represented and stored in sys-tem memory. The information model is analyzed in section 2.1.2. The information exchange model as defined in IEC 61400-25-3 specifies the methods and protocol procedures which server and client must follow to ex-change data successfully. The information exchange model is analyzed in section 2.1.3 The methods mentioned are abstract and can be mapped to any communica-tion protocol. The most common and used protocol mapping are defined in IEC 61400-25-4. This thesis uses SOAP- and XML- web services for protocol mapping, which is defined in annex A of the IEC 61400-25-4. Mapping of web services to communication profiles is described in section 2.1.4 To ensure a system is compliant with the IEC 61400-25 standard, part 5 of the standard defines test cases and conformance tests. Section 2.2 analyses these tests and determines which cases are suited for test driven develop-ment. Even through previous work is not officially a part of the IEC 61400-25 stan-dard. It has to be said that the contents of these thesis are invaluable as a starting point of this thesis. Central designs from previous work regarding IEC61400-25 will be taken info into account in section 2.1.1. Subjects not covered by IEC61400-25 but neither than less important to the thesis are:

• Mapping of WWP data to IEC 61400-25-2 information model. • WWP simulator • Brodersen RTU32 industrial PC.

By the end of this chapter, parts of the IEC 61400-25 standard and important subjects has been analyzed to make ground for specification and require-ments. These specifications and requirements are defined in section 2.4.


June 2008

8

2.1 The IEC 61400-25 standard - State of the art The IEC 61400-25 standard is an adaptation of the IEC 61850 standard series, with special concern on controlling and monitoring wind power plants. The IEC 61850 standard series is essential a standard for substation automation. Therefore the IEC 61400-25 standard series is merely not a replica of IEC 61850, but reuses the terms and definitions that will apply to all substations. Further more the IEC 61400-25 standard series extends the IEC 61850 with unique information models which only apply to wind power plants. Such unique features could include rotor speed, turbine or other vendor specific components. The IEC 61400-25 standard series can be categorized into 5 different subjects. These are:

- Overall description of principles and models (IEC 61400-25-1), partly described in section 2.1.1

- Information models (IEC 61400-25-2), see section 2.1.2 for more de-tails.

- Information exchange models (IEC 61400-25-3), se section 2.1.3 for more detail.

- Mapping to communication profile (IEC 61400-25-4), se section 2.1.4 for more details.

- Conformance testing (IEC 61400-25-5)

2.1.1 Previous work and general principles of IEC 61400-25 The IEC 61400-25 domain model, contains part 2,3 and 4 of the standard. Figure 1 illustrates the correlation between the three categories.

Server

Information Exchange Model

IEC 61400-25-3

Information ModelIEC 61400-25-2

Wind Power Plant

Client

Communication profileIEC 61400-25-4

Information Exchange Model

IEC 61400-25-3

Information ModelIEC 61400-25-2

SCADA or other

actor

Figure 1 - IEC 61400-25 Domain model

Out of scope for the domain is the interaction between the client side and SCADA client.


June 2008

9

Another out of scope is the interaction between WPP and information model. From previous thesis [3] it has been showed that server side of the IEC 61400-25 domain model can be abstracted into an overall design. This thesis will analyze this model. Figure 2 is the system architecture proposal from the thesis “Prototype for a IEC 61400-25 Compliant Generic” [3].

Main server

ServiceInterfaceIEC61400-25-4Facade

Data Handling Logic

Client Handling

WWP Device Connector

CommonWindPowerPlantFacade

Client communicationinterface

WS

MMS

WPPsupplierinterface

Supplier interface

Supplier interface

Access Control Data storage

4. 9.

6.

8.

2.

5. 7.

11.10.

1.

12.

Configuration Contract

3.

PolicyContract

13.

Figure 2 - System architecture proposal

Each numbered element in the figure is explained in accordance to this thesis. Even through many of the explanations will be similar to the original sounding.

1. Client The client consumes the service by which the server is offering. Client can be any in application domain, from SCADA systems to web clients. In This thesis the client is a web service framework consuming the service thru a discovery service provided by the server.

2. Client communication interface. The client can use different methods to conduct the communication with the service. Different protocol map-ping include methods like MMS etc. For this thesis the client communi-cation interface is a simple web server hosting an IEC 61400-25-4 an-nex A web service implementation.

3. Policy files define communication specific information for the commu-nication. This include security information, use of transport protocol etc. This is how ever not considered in this thesis. Mainly because the web server implementation is very simple and only will support the most ne-


June 2008

10

cessary and basic web server functionality.

4. Service interface. A common interface for acquiring the services of the system. Common interface assures that the service can always be reached through the client communication interface as long as it obli-gates itself to use the interface defined in IEC 61400-25-4.

5. Access control. A simple access and user management scheme, to verify credentials and grant access if authentication was successful.

6. Client handler. When communicating with the service the client can ask for specific data. The client handler handles the association be-tween different clients and the service. The client handler must at all time keep track of associated clients, and disconnect clients which ses-sions have expired.

7. Data storage. In this thesis the data store is an XML based data file.

8. Data handler logic. Acting as an expert in data handling. The Data handler logic keeps track of information model data.

Point 9-13 has been left unchanged from the original descriptions of the figure [3] (page 37)

9. WPP Device Connector. Different WPP suppliers produce different data. The device connector gathers the necessary data from each WPP. The information model in IEC 61400-2 defines this

10. Common supplier interface. There is no generally approved standard for how the data must be supplied by the WPP, but by defining one, supplier modules are easier to replace in the system.

11. Supplier interface. When connecting a WPP to the service, the sup-plier has to create an interface file. The file has knowledge of the sup-plied nodes that a WPP can expose, and how often pooling is neces-sary for the WPP.

12. Configuration contract. The contract must contain information of the data each WPP can deliver. Also the contract defines how often the data is to be pooled. This must be done in compliance to the IEC 61400-25-2 information model

13. WPP. Each supplier exposes its capabilities to get and set data through their own interface.

For this thesis the client side of the IEC 61400-25 domain is modelled much like what previous thesis [3] did on the client side. Figure 3, shows how the domain for this thesis is supposed to perceived.


June 2008

11

Client domain

WAN or LANClient Communication

Interface(IEC 61400-25-4)

ClientWS messages

Figure 3 - Client domain in this thesis

A client will then use the Client Communication Interface to interact with the IEC 61400-25 server. Since the Client Communication Interface is the gate-way to a IEC 61400-25 server, it will also be subject to IEC 61400-25-5 con-formance testing. See section 2.2 “Test cases and IEC 61400-25-5” for more details.

2.1.2 Part 2 of IEC 61400-25, Information Model Data representation is an important part of the IEC 61400-25 standard, and the information model is a way to represent actual WPP components in a data structured manner. Generally WPP components are mapped to a virtual world from real WPP components. Consult Figure 4 for the conception of virtualiza-tion.

Figure 4 - Concept of mapping WWP data

Arched arrows point both ways in the figure. This is because real WPP com-ponents also can be controlled via the model.


June 2008

12

2.1.2.1 Data Model The composition of the data model is a hierarchical tree structure, where the server resides at the top node. Only one instance of the server class is al-lowed, and from the server node all child nodes will propagate. The server class is also the entry point to the data model, and contains 0 to n Logical de-vices. Which in terms mean that the server class is the container of a real WWP or a WPP farm. The type and class of child node is defined as follows:

• Logical device class or LD, is a virtual representation of a real WPP. A LD can hold 3 to n Logical Nodes.

Two of these logical nodes are mandatory and must be contained in every LD residing on the server. These 2 logical nodes are: LLN0 - Logical Node Zero, is a representation of common information of the logical device which the LLN0 resides in. There can be only one instance of LLN0 in any given LD. LPHD - Physical Device Information, is a representation of common informa-tion regarding the physical devices present in the particular WWP. As the LLN0 logical node, only one instance of LPHD can exist in a given LD. The third and last logical node of the mandatory logical nodes is must be pre-sent, but can be chosen from a verity of Logical Node classes. To inspect the-ses classes consult IEC 61400-25-2 page 14.

• Logical Node class or LN, is a virtual representation of main compo-nents in a WPP. One example of such a virtual account is the LN class WROT, which holds information about the wind turbine rotor. A LN can hold zero to n Common Data Classes.

• Common Data Class or CDC is a virtual representation of a sub com-ponent on a specific element. For example a WWP rotor has several sub components attached. One being the Temperature in the rotor hub an other being the angular position of the rotor. Both defined by CDCs as HubTmp and RotPos. A CDC can hold 0 to n Data Attribute classes, and [0…n] CDCs. One CDC can contain another CDC. This property is explained later.

• Data Attribute class or DA is the actual data which can be read or modified.

Figure 5 shows how nodes are connected to classes and the general hier-archical structure of the information model.


June 2008

13

Serv

LD1 LD2 LDn

Server

Logical Device

LN2LN1 LNnLogical Node

CDC1

CDC2

CDCn

Common Data

Clases

LD2

LD2/LN1

LD2/LN1.CDC2

DA1

DA2

DAn

Data Attribute LD2/LN1.CDC2.DA1

Classes Class indexing example

Entry point

Figure 5 - Information model node composistion and example

According to the IEC 61400-25 standard, object reference is a unique path to a given object in the data hierarchy. LDs are delimited by a forward slash to indicate the next level in the data hierarchy, where all other classes are delim-ited by a period to indicate the next level. So when following the colored path to the leaf node, it will produce a object reference path of

LD2/LN1.CDC2.DA1 A more concrete example of this would be:

myWPP/WGEN.W.d Generally the above statements can be written as: LogicalDevice/LogicalNode.CommonDataClass.DataAttribute

Or LD/LN.CDC.DA

As seen in the figure, the CDC can contain instances of other CDC’s. In reality this is more likely to be true for the common case of an instantiated data model. Figure 6 shows a more real picture of the general hierarchical structure, and Figure 7 shows a concrete example of the hierarchical data model.


June 2008

14

Logical Device

Logical Node

Common Data Class

Common Data Class

Data Attribute

Data Attribute

Data Attribute

Data Attribute Figure 6 - General visualization of data model

Figure 7 - Concrete example of data model representation

In the above example the unique object reference path is written as:

myWPP/WTUR.OpTmRs.actTmVal.q The q part in the object reference above is a data attribute. Data attributes are described in the next section.

2.1.2.2 Data Attributes Data attributes are always found at the leaf node of an information breach. This makes the data attribute class the lowest available information in the IEC 61400-25. Besides containing simple types several properties are associated with the data attribute. In Table 2 these properties are described. Property Descriptions Attribute name The Name of the attribute Attribute type The type of the attribute: e.g: String, Int, Boolean

etc. Functional constraints Which operations are allowed to be preformed on

the attribute! Trigger options Used for Report and Logging. If this is present the


June 2008

15

type of the trigger option decides under which cir-cumstances a Report or Logging event should be fired.

Explanation / Range Description and range of the attributes content. Mandatory Whatever or not a given attribute is Mandatory or

Optional to include. Table 2 - Common Data Class entries

To examine the complete list of data attributes consult IEC 61400-25-2 for more information. Attribute name defines the name of the data attribute, and attribute type de-fines the type which is associated with the attribute name. An attribute type can be simple or more complex. Examples of basic types are Strings, Integers, booleans or floates. Data attribute components Or DAcomponent is a more complex type that a data attribute can hold. Basi-cally DAcomponents are a composite of basic type representing the same value. This feature adds another node to the bottom of the information model hierarchy. Figure 8 shows the relation of data attribute component to the in-formation model.

mag

float int

DA1

Dac1

Dac2

Dacn

Basic 2

Basic 2

Basic n

Basic type

Data Attribute

Component

Data Attribute

General Example

f i

Can point to 1 to n DAC

Figure 8 - Data Attribute Component and example

The example in the figure above corresponds to the following example:

myWWP/WGEN.W.PhsA.cVal.mag.f myWWP/WGEN.W.PhsA.cVal.mag.i

(above: f is type floate. i is type integer) Where mag is a data attribute type and f, i is data attribute component type contained in mag. Each data attribute component holds a basic type repre-senting the same value, but in different type formats. So if the value of one of the basic type values changes the server is obligated to change the other ba-sic type value according to conversion rules. This converting scheme is how-ever not examined further in this thesis.


June 2008

16

2.1.2.3 Data sets A data set is a collection of object references pointing to a specific node in the information hierarchy. Figure 9 illustrates the concept of referring data in the data set.

Figure 9 - Data Sets groups object references to visible data

Data Sets can contain 1 to n object references. An object reference in the data set is essentially a pointer to a specific node and all its child nodes in the information model. This can be perceived as access to visible data. Example wise would

myWPP/WTUR.OpTmRs.manRs

not be visible nor accessible from using Data Set object reference

myWPP/WTUR.OpTmRs.actTmVal But

myWPP/WTUR.OpTmRs.actTmVal.q would be accessible. This idea differs from previous work “Prototype for an IEC 61400-25 Compli-ant Generic Server” [3] and “Reporting and logging in compliance with IEC 61400-25” [4], where data sets are perceived as a collection of data attribute references, thus referencing the leaf nodes of the information model tree. In


June 2008

17

this thesis any part of the information model can be referenced as explained with object reference to visible data4. Data sets can be categorized into two groups. Mainly there are persistent data sets and non-persistent data sets. Persistent Non-persistent

Object reference myWPP/WTUR.myDataSet1

@myDataSet1

Time to live Until the Data Set is deleted by DeleteDataSet method.

Until the session from the creator is terminated or DeleteDataSet method is called on the particular data set.

Table 3 - Data set category differences As the word suggests are persistent data sets, continual. They are created in logical nodes and reside there until they are manually deleted. To reference a particular data set, one must use the below general object reference:

LogicalDevice/LogicalNode.DataSetName It can be assumed that persistent data sets are saved to the data storage, to maintain continuality even if a server restarts occurred. On the other hand, non-persistent data set are closely tied to the user asso-ciation of a session between a client and server. If the session for some rea-son is closed, associated data sets must be deleted as well. Non persistent data object references is a “@” sign followed by the actual name of the data set. Since non-persistent data set are temporally objects it can be assumed that these data sets only reside in the memory of the device.

2.1.3 Part 3 of IEC 61400-25, Information Exchange The information exchange presented in IEC61400-25-3 defines which ser-vices and methods are available to the client. This is described in section 2.1.3.1. It also defines in which order service methods must be run in order to perform certain tasks. This is described in section 2.1.3.2.

2.1.3.1 Exposed exchange methods The methods exposed by IEC61400-25-3 are abstract and does not contain any specific constraints on how the service is implemented. This concept is generally called ANSI (Abstract Communication Service Interface). This thesis uses the following abstract methods from IEC61400-25-3 as listed in Table 4.

4 Knud Johansen supplied documentation for this difference compared to previous work.


June 2008

18

Abstract method Description Category : Authorization services

Associate Before a client can perform any operations on the server. The client must make an attempt to associate with the server. If the server accepts the terms of the association (e.g. User-name/Password), the server will issue a associa-tion ID for the client to use in further communica-tion.

Release When the client has finished the session of op-erations it will issue a release to the server. The server can then take the appropriate actions to cleanup client allocations.

Category : Data directory services GetServerDirectory Retrieves a list of WPP names or logical devices

hosted on the server. GetLogicalDeviceDirectory Retrieves a list of logical nodes names contained

in a specific logical device. E.g. WTUR, WGEN ect.

GetLogicalNodeDirectory Retrieves a list of data names contained in a specific logical node.

GetDataDirectory Retrieves a list of data attribute values contained in a specific CDC.

GetDataSetDirectory Retrieves a list of dataset names contained in the specified logical node reference.

Category : Data retrieval and delivery services GetDataValues Retrieve the data attribute values of all specified

object references. SetDataValues Set the data attribute value of all specified object

references to their new values specified in the request.

GetDataSetValues Retrieves the data attribute values of specified object references, but only if the value is visible to the dataset object reference.

SetDataSetValues Set the data attribute value of all specified object references to their new values specified in the request, but only if the value is visible to the dataset object reference.

CreateDataSet Creates a named dataset with all the specified object references.

DeleteDataSet Delete a dataset with the specified name. Table 4 - Table of ACSI methods in this thesis

2.1.3.2 Data exchange protocols The IEC 61400-25-3 also defines the sequence in which the abstract methods must be executed in order to perform certain tasks. Figure 10 shows the basic protocol sequence for IEC 61400-25-3 methods used in this thesis.


June 2008

19

½

Client

½

Server

Ask for remote authentication

Operational information

- GetDataValues- GetLogicalNode- ect.- ...

Close association

Check credential

Prossing of client requests

Operations

Close association

Associate

Release

Figure 10 - General protocol sequence

The protocol sequence can be considers as a three step phase. The first method a client should always send is the association method. Therefore association method is also a method the server can not reject. Second phase is followed by a successful association comes a variety of op-erations. If following the scheme from Table 4 - Table of ACSI methods in this thesis. Operations are in the category of “Data directory” and “Data retrieval and delivery” services. Final and third stage is when the client is finished with its business; it will send a release method to the server. Provided that the client has not timed out prior to the release request.

2.1.4 Part 4 of IEC 61400-25, Mapping to communication profile The IEC 61400-15-4 describes different protocol mappings a developer can choose from when deciding which communication scheme to map to the ex-change model. The standard offers five different such protocol mapping, where one of them is mapping to SOAP-XML web services. Consult IEC 61400-25-4 to inspect all available mappings. SOAP-XML web services mapping is the chosen protocol mapping in this the-sis. Generally web services can use either the HTTP or the SMTP as transport protocol. In this thesis it has been chosen to use the HTTP as transport proto-col for web service messages. This approach also corresponds to what was done in previous work [3] and [4]. Therefore it is posed as an obvious choice.

2.1.4.1 Web Service Description Language Or WSDL is a complete description of a given web service. The format of the WSDL is defined like a XML schema file. Not only does the WDSL describe the available messages, their parameters and response types. But also de-fines complex data structures, which can be used in a message call.


June 2008

20

When some one decides to purchase the IEC 61400-25 standard, a WDSL file is included in the acquisition. This particular WSDL file contains a complete definition of the IEC 61400-25-4 Annex A “Definition and mapping to Web Services”. The WSDL document used in this thesis was supplied by Knud Johansen.

2.1.4.2 Server side mapping On the server side it is important to construct request and response system as accurate as possible to the original description in the WSDL supplied. Without code generating tools, one must examine the contents of a web service mes-sage. An http web service message consists of the following elements. <Http header/> <soap:Envelope> <soap:Body> <XML document>

Actual XML message data </XML document>

</soap:Body> </soap:Envelope> When removing the http header and the soap body from the equation the only thing left is a XML document. This XML document can be compared to the message definitions in the WSDL document. From these message definitions in the WSDL document request and response classes can be constructed.

2.1.4.3 Client side mapping On the client side of the system Visual studio is able to create stubs which are able to consume web services located at a specific URL. This can be done provided the target web server is able to publish the WSDL for a given web service. This publishing scheme is also called service discovery in web service termi-nology. Therefore it is crucial that the web server in this thesis is able to pub-lish its IEC 61400-25-4 WSDL file.

2.2 Test cases and IEC 61400-25-5 This section will describe test cases from the IEC 61400-25-5 standard, which are found useful to the development and implementation of the project in question. Since the conformance tests in IEC 61400-25-5, is required to verify that soft-ware comply with the IEC 61400-25 standard, it would make sense to make design decisions upon these tests. Further more these test cases would also serve as unit tests in a Test-Driven Development [1], see Chapter 5 for more details on TDD. Basically the IEC 61400-25-5 test cases are divided in two main groups. Re-spectably these groups are test cases for the server and test cases for the client part.


June 2008

21

The server includes subparts for testing: • Server, Logical Device, Logical Node, and Data model • Data set model • Reporting model • Log model • Control model • Time and time synchronization

The client includes subparts for testing:

• Application association • Server, Logical Device, Logical Node, and Data model • Data set model • Reporting model • Log model • Control model

o Direct control with normal security o SBO control with normal security o Direct control with enhanced security o SBO control with enhanced security

2.2.1 Incitement for choosing test cases When deciding which test cases from IEC 61400-25-5 to proceed, it is impor-tant to know the limitations of unit test and the scope of the project. Figure 11 shows how different subjects of the thesis conceptually intersect.

Figure 11 - Intersection diagram: Unit test in this thesis

Subsets of the IEC 61400-25 domain in the figure can be explained as follows:

• Project scope, is not a full implementation of the IEC 61400-25 stan-dard, and thus it must limit some of the tests specified in IEC 61400-25-5 conformance testing

• Unit test, are not capable of conducting some of the advanced testing procedures in IEC 61400-25-5. This is because some of the tests de-scribed are not considered a “unit” in a unit test sense.


June 2008

22

Taking the tree sets (Project scope, Unit test and conformance test) into con-sideration when choosing test for test implementation, will produce a list of doable IEC 61400-25-5 conformance test cases. The chosen test cases are listed in section 2.2.3.

2.2.2 Testing bench setup The implementation of the test cases is dependent of several factors as de-scribed in the previous section. This will consequently lead to decisions where and what are going to be tested in this thesis. Since the client domain only is a subset of the full IEC 61400-25 standard, all IEC 61400-25-5 tests on the client part has been rejected. This leaves test cases for the server part. This thesis will try and implement and execute as many as the project scope allows. Figure 12 shows the testing setup for the chosen test cases form the IEC 61400-25-5 conformance testing part.

Interface

Figure 12 - Test bench setup for unit tests

Unit tests will interact with the methods defined in the interface of the Client Communication module. The result of these test are then outputted to verify that the chosen tests comply with IEC61400-25-5. Chapter 5 will summarise the result of these tests.

2.2.3 Chosen test cases This section will showcase the test cases chosen to be written and executed. To view all available test cases in conformance testing consult IEC 61400-25-5 standard. To view implementation and test case results consult chapter 5 ”Test and principles”. This chapter will also examine if it where possible to implement and execute all of the listed test cases, and why if not. Consult section 2.2.3.4 for a list of abbreviated terms used solely in the chosen test case descriptions.

2.2.3.1 Application association Positive Test case

Test case description

S_Ass1 Associate and release TPAA association (IEC 61850-7-2 7.4) S_Ass2 Associate and client-abort TPAA association (IEC 61850-7-2 7.4) S_Ass3 Associate with maximum number of clients simultaneously (PIXIT)


June 2008

23

Negative Test case


S_AssN1 Check that with incorrect authentication parameters and authentication turned on at the server, the association fails, and with authentication turned off, the server associates (IEC 61850-7-2 7.4)

S_AssN2 Check that with incorrect association parameters at server or client the associa-tion fails (IEC 61850-7-2 7.4 PIXIT)

S_AssN3 Set up maximum +1 associations, verify the last associate is refused. S_AssN4 Disconnect the communication interface, the DUT shall accept an association

request when ready. S_AssN5 Interrupt and restore the power supply, the DUT shall accept an association re-

quest when ready.

2.2.3.2 Server, Logical Device, Logical Node, and Data model Positive Test case


S_Srv1 Request GetServerDirectory(LOGICAL-DEVICE) and check responses (IEC 61850-7-2 6.2.2).

S_Srv2 For each GetServerDirectory(LOGICAL-DEVICE) response issue a GetLogicalDe-viceDirectory request and check response (IEC 61850-7-2 8.2.1).

S_Srv3 For each GetLogicalDeviceDirectory response issue a GetLogicalNodeDirec-tory(DATA) request and check response (IEC 61850-7-2 9.2.2).

S_Srv4 For each GetLogicalNodeDirectory(DATA) response issue a - GetDataDirectory request and check response (IEC 61850-7-2 10.4.4). - GetDataDefinition request and check response (IEC 61850-7-2 10.4.5). - GetDataValues request and check response (IEC 61850-7-2 10.4.2).

S_Srv5 Issue one GetDataValues with the maximum number of data values and check response.

S_Srv6 For each write enabled DATA object, issue a SetDataValues request and check response (IEC 61850-7-2 10.4.2)

S_Srv7 Issue one SetDataValues with the maximum number of data values and check response.

S_Srv8 Request GetAllDataValues for each functional constraint and check response (IEC 61850-7-2 9.2.3)

Negative Test case


S_SrvN1 Request the following data services with wrong parameters (unknown object, name case mismatch, wrong logical device or wrong logical node) and verify response- service error

- ServerDirectory(LOGICAL-DEVICE) (IEC 61850-7-2 6.2.2). - GetLogicalDeviceDirectory (IEC 61850-7-2 8.2.1). - GetLogicalNodeDirectory(DATA) (IEC 61850-7-2 9.2.2). - GetAllDataValues (IEC 61850-7-2 9.2.3). - GetDataValues (IEC 61850-7-2 10.4.2). - SetDataValues (IEC 61850-7-2 10.4.3). - GetDataDirectory (IEC 61850-7-2 10.4.4) - GetDataDefiniction (IEC 61850-7-2 10.4.5)

S_SrvN2 Request SetDataValues of ENUMERATED data with out-of-range value and verify response- service error (IEC 61850-7-2 10.4.2)

S_SrvN3 Request SetDataValues with mismatching data type (e.g. int-float) and verify


June 2008

24

response- service error (IEC 61850-7-2 10.4.2). S_SrvN4 Request SetDataValues for read-only values and verify response- service error

(IEC 61850-7-2 10.4.2).

2.2.3.3 Data set model Positive Test case


S_Ds1 Request GetLogicalNodeDirectory(LOGICAL-DEVICE) and check response (IEC 61850-7-2 9.2.2). For each response, issue a:

- GetDataSetValues request and check response (IEC 61850-7-2 Sub-clause 11.3.2).

- GetDataSetDirectory request and check response (IEC 61850-7-2 Sub-clause 11.3.6).

S_Ds2 Request a persistent CreateDataSet with one member and with maximum possi-ble members and check response (IEC 61850-7-2 11.3.4) and verify that the non-persistent data set is visible for another client.

S_Ds3 Request a non-persistent CreateDataSet with one member and with maximum possible members and check response (IEC 61850-7-2 11.3.4) and verify that the non-persistent data set is not visible for another client.

S_Ds4 Create and delete a persistent dataset, create it again with the same name with one extra data value/re-ordered member and check the members.

S_Ds5 Create and delete a non-persistent dataset, create it again with the same name with one extra data value/re-ordered member and check the members.

S_Ds6 Create a non-persistent dataset, release/abort the association, associate again and check that the dataset has been deleted (IEC 61850-7-2 11.1)

S_Ds7 Create a non-persistent dataset, release/abort the association, associate again and check that the dataset is still present (IEC 61850-7-2 11.1)

S_Ds8 Create and delete a persistent dataset and verify that every data can be created normally: repeat the process of creating and deleting once.

S_Ds9 Create and delete a non-persistent dataset and verify that every data can be created normally: repeat the process of creating and deleting once.

S_Ds10 Verify SetDataSetValues/GetDataSetValues with GetDataValues and SetData-Values.

Negative Test case


S_DsN1 Request the following data services with wrong parameters (unknown object, name case mismatch, wrong logical device or wrong logical node) and verify response- service error

- GetDataSetValues (IEC 61850-7-2 11.3.2) - SetDataSetValues (IEC 61850-7-2 11.3.3) - CreateDataSetValues (IEC 61850-7-2 11.3.4) - DeleteDataSetValues (IEC 61850-7-2 11.3.5) - GetDataSetDirectory (IEC 61850-7-2 11.3.6)

S_DsN2 Create a persistent dataset with the same name twice, and verify response- service error.

S_DsN3 Create a non-persistent dataset with the same name twice, and verify response- service error.

S_DsN4 Create more than maximum of persistent datasets and verify response- service error.

S_DsN5 Create more than maximum of non-persistent datasets and verify response-


June 2008

25

service error. S_DsN6 Create a persistent dataset with more than maximum number of elements and

verify response- service error. S_DsN7 Create a non-persistent dataset with more than maximum number of elements

and verify response- service error. S_DsN8 Create a persistent dataset with unknown members and verify response- service

error. S_DsN9 Create a non-persistent dataset with unknown members and verify response-

service error. S_DsN10 Delete a (pre-defined) non-deletable dataset and verify response- service error. S_DsN11 Delete a persistent dataset twice, and verify response- service error. S_DsN12 Delete a non-persistent dataset twice, and verify response- service error. S_DsN13 Delete a dataset referenced by (report) control class, and verify response- ser-

vice error (IEC 61850-7-2 11.1) S_DsN14 Request SetDataSetValues with one or more read-only members, and verify

response- service error.

2.2.3.4 Test case acronyms This section is a help for understanding abbreviated terms in the descriptions of the test cases. Acronym Description DUT Device Under Test PIXIT Protocol Implementation eXtra Information for Testing TPAA Two Party Application Association

Table 5 - Abbreviated terms used in chosen test case describtions

2.3 Brodersen RTU32 In order to specify the general requirement of the developed solution, it is im-portant to know the capabilities and limitations of the target device chosen for deployment. The industrial device available to this thesis is a Brodersen RTU32 from the company Brodersen Controls A/S. The RTU is a fully capable industrial PC RTU is an abbreviation of “Remote Terminal Unite”. Figure 13 shows a picture of a Brodersen RTU32.

Figure 13 - A Brodersen RTU


June 2008

26

The RTU32 runs Windows CE 5.0 which is a highly compact edition of stan-dard Windows. Windows CE is mostly used on embedded and handheld de-vices, and Windows CE is often refereed to as Windows embedded CE. Win-dows CE is therefore designed to run on minimalistic devices configuration such as the RTU32 and in the common sense has most of the features the grander versions of Windows have. But just in a smaller scale. Every Windows CE is configured and deployed by the Windows CE image. The image decides which components must be included in the build. All Win-dows CE images in this thesis where created by Brodersen Controls. Compo-nents included which are important to this analysis are:

• .NET compact framework 2.0 or .NET CF is the second generation of Microsoft’s efforts to make a .NET compatible framework for minimalis-tic devices. The .NET compact framework is a lot smaller than its non-compact equivalent. For comparison the .NET CF class library is ap-proximately 30% less than the full .NET class library (according to Mi-crosoft5). For this particular reason a lot of functionality is not available in the .NET version supplied with the Brodersen RTU32. Such func-tionality missing includes, web services and SOAP formatting to name the most important. During the preparation of this thesis Microsoft released version 3.5 of the .NET compact framework. Even though this will not be covered by this thesis its worth mentioning.

• Httpd web server. The web server included is a very simple version of the IS from Microsoft. Therefore the web server is not capable of host-ing web services, or running any kind of .NET scripting. It is possible to host web services using unmanaged ATL objects. This is however not indorsed in this thesis.

5 “Differences Between the .NET Compact Framework and the .NET Framework” http://msdn.microsoft.com/en-us/library/2weec7k5.aspx


June 2008

27

2.4 Specification and requirements Based upon the previous sections it is possible to define what must be de-signed, according to the project description. Figure 14 shows the scope of the thesis in a graphical way.

Figure 14 - Project scope

2.4.1 IEC61400-25-3 Client framework A client framework must be constructed, which consists of a DLL file. A proof of concept client which uses this DLL is to be constructed as well. For verification and IEC 61400-25-5 conformance testing of IEC 61400-25 server unit tests are preformed on client DLL functionality. Conformance test cases chosen are those who can be implemented in the thesis setup.

2.4.2 IEC 61400-25 Server A compliant IEC 61400-25 Server must be constructed using the design prin-ciple purposed by previous master thesis. Due to the vast size of the IEC 61400-25 standard report and logging are left out but are considered in future work chapter 0. Further more the server must be able to run in a .NET com-pact framework 2.0 environment.

2.4.3 Simple web server Since the RTU32 and .NET CF 2.0 does not support web services via the available HTTPD server, a very simple web server and web service imple-mentation must be constructed.

2.4.4 IEC 61400-25-5 conformance testing A series of test cases from the IEC 61400-25-5 has been chosen for deploy-ment of Test Driven Development and unit test.

2.4.5 Wind Power Plant Simulator The WPP simulator will be a very simple simulator, capable of generating a few values alternating (random) values for mapping to server information model.


June 2008

28

2.5 Sub conclusion This chapter has analyzed the elements required to create an IEC 61400-25 compliant system server and an IEC 61400-15-4 Client framework. The server design is analyzed according to the system proposal by Anders and Baris in their previous work [3]. Which has resulted in a module based server design. One of the more important aspects of the IEC 64100-25 is the information model. A large part of this model has been analyzed, and it reveals the hierar-chical nature of the information model. LogicalDevice/LogicalNode.CommonDataClass.DataAttribute Data attributes define the last element in the information model hierarchy, and can hold both simple types as strings, integers and floats but also composite types, which can combine 2 or more simple types to represent the same value. Data sets are perceived differently than previous work, as previous work [3-4] had data sets reference Data Attributes. In this thesis data set can reference any part of the information model. Analysis reveals that object references in data sets point to visible data in the information model hierarchy. 2 types of data set exist, persistent and non-persistent. Persistent data set are refer-enced by: LogicalDevice/LogicalNode.DataSet Where as non-persistent data sets are referenced by: @DataSet To test the server, the IEC 61400-25-5 conformance testing has been ana-lyzed and specific test cases form the standard has been chosen. These tests were chosen on the combination of the project scope, unit test capabilities and testing procedures in IEC 61400-25-5. The Brodersen RTU32 has been analyzed to reveal its short comings to a regular pc. Instead of the full .NET platform the .NET CF is used for imple-menting the solution. The use of .NET CF forces the implementation to con-struct a simple web server instead of hosting on a advanced web server to make the implementation accept web services. From the IEC 61400-25-3 information exchange model, a limited set of meth-ods have been chosen to be implemented. Not considered are service meth-ods regarding Report, logging and Control.


June 2008

29

3 Design This chapter will propose a system design based on the analysis. This design is a reflection of the requirements analyzed in the previous chapter. The overall system design is described in section 3.1, and includes a general approach to the whole system. The server design, described in section 3.2, is an outcome of the system pro-posal from chapter 2 section 2.1.1, but will contain more specific design deci-sions The client design is partly based on some of the ideas concepted in the server design, and will elaborate on how these design ideas are used on the client side of the system. This is described in section 3.3. The general approach for designing the system is by using UML sequence diagrams to show the dynamics of the design and UML class diagrams for showing the static structure within.

3.1 Overall system architecture This section will summarize the overall design of the system, and will also help to classify the major buildings blocks of the entire design. Figure 15 illustrates the overall design.

PC domain RTU domain

WAN or LAN

Client Interface

IEC 61400-25 compliant

server

ClientWS

SoapMessage

WSSoap

Message

WPP simulator

WPPsimulator

Figure 15 - Overall system architecture

The system will consist of tree different elements

• Client Interface and simple Client • IEC61400-25 Server • WPP simulator


June 2008

30

3.2 Server design This section describes the design of an IEC 61400-25 compliant server. The overall structure of the server design is a reflection of the system proposal described in chapter 2 section 2.1.1. Further more the proposal was originally suggested by Baris and Anders [3] in their paper “Prototype for an IEC 61400-25 Compliant Generic Server”. This section will reference this proposal and elaborate on each element in a design oriented matter. Design elements to consider in this section are:

• Simple web server • Service interface • Client handling • Data handling logic • Information model and type library. • Access control

Each of these points represents a module within the server, and should be treated as encapsulated components. Each module is an expert in their de-fined field. Since many of the elements used in the information model are also used in other places, the information model has been encapsulated into a special module called typeLibrary. Besides the information model the typeLi-brary also contains all request and response classes of the IEC 61400-25-3 service interface. Further more all types used by these request response classes are also included in the type library. This is discussed in section 3.2.6.

3.2.1 Main server module When considering server designs in general, it is of great importance to de-sign the treading model for the server. Single threaded servers are simply not an option in this thesis because the server has to perform several tasks simul-taneously, and be able to handle multiple clients at the same time. To keep things simple, the following threading model has been proposed.

• Web server will have its own worker thread. This thread is used for list-ing for clients, and will spawn new threads when ever a client connects.

• Main server thread will be an event based thread, or in .NET terminol-ogy a GUI thread. This way the main server thread will only react when certain events rises.

• WPP device connector will have its own worker thread. The server thread will spawn both the Web server thread and the WPP device connector thread before going into its listening loop. Figure 16 illustrates the threading scheme by using petri net notation.


June 2008

31

Figure 16 - Petri net of threading scheme

Short after the server starts, the server will fork out in tree threads.

• Main server thread - Will go into the message loop at place “Wait for events”. It will stay here until a subscribed event is incoming. The server thread now move to the place “Perform Event” to execute whatever event might have trig-gered. When the code associated with the event has finished, it will re-turn to place “Wait for events”.

• Web server thread - will stay at place “Wait for client” until a new client arrives. It will then synchronize with the client at transition “Connect client”. In practical terms this means a client processing thread is created. This new thread will process any service requests and return a response as well before terminating. Meanwhile the Web server thread has gone back to “Wait for clients” ready to accept new clients.

• WWP device connection thread - Will start pooling for data at place “Pool for WPP Data”. Once the WPP connects the WPP device connection thread will synchronize with the connecting WPP and exchange WPP data. This is done in transition “Receive WPP Data”. Now at place “Process WPP Data”, the WPP de-vice connector thread can process the received WPP Data. Once this is done it will return to place “Pool for WPP data”.


June 2008

32

All threads in this threading scheme will remain active as long as the parent thread of the main server thread stays alive. The main server thread is also responsible for terminating all other threads when it is told to terminate. As shown in the petri net the transition “join Threads” do just that. The resulting class diagram for the server can be seen in Figure 17.

Figure 17 - class diagram for Server module

The Server class inherits from the Form class which is a part of .NET common classes for displaying GUI’s. This inheritance also enables the server to run as an event based thread. The idea with the class CommunicationInterface is to host different IEC 61400-25-4 communications profiles. In this case the class only hosts the WebServer class. The WPPDeviceConnector class is handling connections to WPPs.

3.2.1.1 GUI thread events The idea with by running an events based GUI thread has two main purposes:

• Show simple GUI components. Mainly used for onsite WWP techni-cians and for debugging in the development phase of the project.

• Be able to react when certain conditions arise in the server. In this thesis the GUI thread shows a simple GUI form with some button com-ponents attached. Se Figure 18 for GUI form layout.


June 2008

33

Figure 18 - Form layout of GUI

Descriptions of the GUI form buttons:

• Online users, show the current online users and their last interaction with the system.

• Purge Associations, removes all online users from the server. • Show reference tree, outputs the whole reference tree of the informa-

tion model. Further more, the form has also attracted a GUI timer object, which will fire a cleanup check event every second. When the event fires the UpdateAssocia-tionSessions method will be executed in the clientHandeling class.

3.2.2 Simple web server module The job of the simple web server is to accept incoming http messages from the network and process these messages according to the soap protocol. The simple web server is extended upon the work of Richard Jones’s “Web Ser-vices On Devices” [5]. The http server part has been modified to meet the re-quirements of this thesis. These changes where applied when the need arose during development. How the server processes incoming requests are shown in the sequence dia-gram in Figure 19.


June 2008

34

Figure 19 - Sequence diagram for simple web server

The IResonder interface, is a definition of what the server can respond to. Classes implementing this interface define both what http request and http responses that are accepted. According to the class diagram in Figure 20, the class webServiceResponder implements the IResponder interface. The web-ServiceResponder is then programmed to handle HTTP web service mes-sages, and in particular the web service definition of IEC 61400-25-4. The soapFormatter is a simple helper class designed to wrap and unwrap soap messages from and into real object instances.

Figure 20 - Class diagram for simple web server

3.2.3 Service interface module The interface IServices61400_25_4 is an interface defining all services avail-able in IEC 61400-25-3 information exchange model. In this case the class


June 2008

35

ServiceInterfaceFade implements the IServices61400_25_4 interface. This makes object instances of ServiceInterfaceFacade class into a gateway to the server. This is commonly also called a facade pattern. Figure 21 show the IServices61400_25_4 interface and the interface using class ServiceInter-faceFacade

Figure 21 - Service Interface

Every communication profile is obligated to use the IServices61400_25_4 in-terface when establishing contact to the server. By using an interface, the communication modules can easy be interchanged or added to the system. In this thesis the IServices61400_25_4 is used by the web server module communication profile. Figure 22 show the interaction between the Web server module and the client handling module.


June 2008

36

Figure 22 - Sequence diagram of Service interface module

3.2.4 Client handling module The client handling module manages clients which are associated in the server. It is an expert in user management and user rights. The class diagram for the client handling module can be seen in Figure 23.

Figure 23 - Class diagram for Client handling module

Only one instance of the clientHandeling class must exist in the server at any-time. To design this feature the singleton pattern is used. The static class cli-entHandleSingleton holds one instance of the clientHandeling class. To gain access to the clientHandeling object one must call the static getHandle func-tion from the clientHandleSingleton. See Figure 24 for sequence diagram.


June 2008

37

Figure 24 - Sequence diagram of client handling module

When the clientHandeling instance has been acquired by an appropriate actor the thread enters a critical section. The actor then locks the usage of the clien-tHandeling instance so that other actors acquiring the instance can not pro-ceed until the instance is released. When the actor has completed its usage of the clientHandeling instance, a call to releaseHandle in the clientHandleSingleton class releases the clientHan-deling instance from the critical section. Awaiting actors can now claim the critical section and proceed processing. Processing of service calls inside the client handling module is described in Figure 25.

clientHandeling AccessControl

Associate

hasCredentials

Grant / Deny access

clientConnection

addClient(ID,Username)Return Association ID

isConnected(ID)

Data Handling logic module

Service request

Process service

Service response

Service response

Service request

Add the clientto the connetedlist

Figure 25 - Sequence diagram of service calls in client handling module


June 2008

38

To gain access to the services provided. The client must associate with the server fist. This is handled by the AccessControl class, by calling the hasCre-dentials function and the class then grants or denies based on the supplied username and password. If the authorization was successful the username and generated association ID is added to the list of connected clients. When requesting a service, the association ID supplied by the service will be checked in the client connection list. If the association exists the service is granted to proceed processing in the data handling module.

3.2.5 Data handling logic module The data handling module manages data and information processing and is an expert in its field. The module also houses the information model which is an important part of the IEC 61400-25 standard. Figure 26 shows the class diagram for the data handling logic module.

Figure 26 - Class diagram for Data handling logic

The data handling module has the same principles as the client handling module (section 3.2.4). Only one instance of the dataHandleLogic class may exist, and thus meaning a singleton pattern is used. Acquiring the dataHan-dleLogic instance is done in the same procedure as in section 3.2.4. The same goes for the mechanism of the critical section. Figure 27 shows the interaction between the services and the information model. Generally service requests use the findReference function in the tServer class. The findReference function will return a typeLibTools object if the particular object reference is found otherwise a null reference is returned. Since all classes in the information model inherits from typeLibTools it just a matter of using polymorphism to operate on the acquired object. If the service request was a get request the virtual function GetDataAttributeValue is called on the on the typeLibTools instance. Visa versa if the service request was a


June 2008

39

set request, the virtual function SetDataAttributeValue is called on the type-LibTools instance. It is then up to the information model hierarchy to deter-mine if the requested operation can be preformed on the particular object.

Figure 27 - Sequence diagram for data handling logic module

The dataHandleLogic class also contains a dataSetManager. The dataSet-Manager class keeps track of non-persistent data sets. For non-persistent data sets it is a bit different. Figure 28 shows the interac-tion between the dataHandlingLogic class and the dataSetManager class.

dataSetManager dataSetContainerdataHandlingLogic

Get/Set-DataSetValues request

GetDATASetByReference

find the data setReturn data set

Process data set

Service response

Figure 28 - Sequence diagram for Non-persistent data set

Instead of calling the findReference function as other service calls do. A ser-vice request with a non-persistent data set will call GetDATASetByReference. From this stage data sets are processed as regular data sets.

3.2.6 Type library module (including information model) The type library functionality and classes are practically accessible in every server side module. This is because many of the types included is used in


June 2008

40

service function parameters and return objects. A complete list of classes found in the type library module can be found in appendix 7.3. The type library contains a total of 100 different classes and an additional 22 enumerator classes. Classes in the type library module can be categorized into 4 main groups:

• Information model • Container objects for IEC 61400-25-3 service requests and responses. • Complex parameter classes for IEC 61400-25-3 service requests and

responses. • Server exception classes

3.2.6.1 Information model The information model is a part of the type library module. The information model is designed based on Table A.4 – XML schema for wind power infor-mation model in IEC 61400-25-4 page 35 and the analysis in section 2.1.2.1. See Figure 29 for class diagram of the information model.

Figure 29 - Class diagram for Information model


June 2008

41

All classes in the information model inherits (except the tServer class) from typeLibTools. The class typeLibTools is a super class to all the mentioned classes.

3.2.6.2 Class typeLibTools The typeLibTools class defines the common attribute “reference” which holds the object reference in the information model hierarchy. Generally typeLib-Tools should not be instantiated, but should be inherited by information model classes. Therefore typeLibTools can be considered an abstract class. The methods in typeLibTools are all defined as virtual functions. This is done to capture the benefits of polyphormism. This mechanism is extremely useful when dealing with recursive functions, and in particular when the next object in the information tree can be one or another type.

3.2.6.3 Server exceptions classes The server exceptions classes are made for the sole purpose of throwing server specific errors. See Figure 30 for class diagram of all defined server exceptions.

Figure 30 - Class diagram for ServerExeption and inheritance.

The general ServerException class inherits from the .NET Exception class to inherit the ability of exception handling. The ServerException class is only used as a base class for the more specialised exception classes of Associa-tionExeption and ServiceNotAvalibleException.

- AssociationException is thrown when a client is not able to provide a valid association ID.

- ServiceNotAvalibleException is thrown from all the IEC 61400-25-3 ser-vices which are not implemented in this thesis.

Finally, general ServerException’s are caught in the web server module to produce a SOAP fault. A SOAP fault which is consequently sent to the client.


June 2008

42

3.2.7 Access control module The Access control module is a simple module which acts as a user database and authentication service. Figure 31 shows the class diagram for this module.

Figure 31 - Class diagram for Access control module

Even through the Role field is not used in this thesis it has been added for future work concerning role based security.

3.2.8 Overall Class and sequence diagram This section is a short summarization of the whole server design. Figure 32 shows the general sequence diagram for the server, and how each module in the server interacts.

Web server module Service interface module Client handling module Data handling logic module Information model

Service request

Service request

Service request

Get information model data

Return requested data

Service response

Service response

Service response

WS request message

WS response message

Figure 32 - Sequence diagram for the Server

Figure 33 shows the class diagram for the whole server. All modules are pre-sented in this diagram, and how they statically are associated.


June 2008

43

Figure 33 - Class diagram for the whole server


June 2008

44

3.3 Client framework design This section describes the design of the client framework. The class diagram of the framework can be viewed in Figure 34.

Figure 34 - Class diagram of Client framework

The framework consists of 3 elements.

• IServices61400_25_4 interface is a slightly modified version of the IS-erverces61400_25_4 interface found in the server design. See section 3.2.3. These changes where added to accommodate the few differ-ences in system architecture. This has mainly to do with the way the web service stub was generated and the extra information needed to call IEC 61400-25-4 Web services.

• WSconnector is basically a class for simplifying the service calls be-tween the client and the web service stub. Return values are wrapped into appropriate response objects, while service parameter values have been simplified. When creating an instance of the WSconnector class,


June 2008

45

one must supply a configuration file which contains information of where the service can be acquired.

• The WebserviceConfig class is a container class for the web service stub configuration.

3.4 Sub conclusion In this chapter the system for an IEC 61400-25 compliant system and an IEC 61400-25-3 client framework has been designed. The design is focused on object oriented design and principles. The general design philosophy is based on the use of UML class diagrams and UML sequence diagrams to show both the static structure and the dy-namic properties of the design. An overall system architecture as been proposed to indentify the major build-ing blocks of the system. This system consists of Client interface, IEC61400-25 server and a WPP simulator. The server being the largest part, it has been split into multiple modules. These modules consist of Simple Web Server, Service Interface, Client han-dling, Data handling, Type Library including information model and Access Control. The main server creates tree threads for different purposes. These threads are:

• Web server thread, which handles HTTP and Web Services requests. • WPP device connector thread, which handles connections to WPP • Main Server thread which is a GUI thread. This makes this thread

event driven, and is able to respond to events when they happen in the server.

To ensure object enclosure for global available objects the client handling module and the data handling logic module has been enclosed in a singleton pattern. Entering the singleton object also make the thread enter the critical section, so no other threads can modify the data in these classes. This en-sures data consistency within the server. This is especially true for the data handling logic module which also contains the implementation of the information model. All types in the information model hierarchy inherit from typeLibTools class which makes information model types inherit virtual functions. These functions are very useful when the information model is traversed when service re-quests are made to the module. The Client framework is basically an implementation of a service interface IS-ervices61400_25_4. This maps these to the web service stub generated by Visual studio.


June 2008

46

4 Implementation This chapter will discuss in details how some of the more important aspect of the design is implemented. The structure of the chapter will be similar to the design chapter, subdividing the server design into modules.

4.1 XML documents and schemas definitions The only way .NET CF is capable of serializing objects is through the use of XML. Therefore this thesis will use XML technology to accomplish all of the serialization tasks. This is both through XML files on storage and XML docu-ments in web services requests and responses. To define the structure of these XML documents this thesis uses XML schema definitions. XML schema definition files are indirectly used in large parts of the implementation of this thesis as explained later. XML schema definition files are structural definitions of how a particular XML document is structured.

4.1.1 Creating type safe classes Preceding the creation of a serializeable C# class, a corresponding XML schema definition was made. From these XML schema definitions it is then possible to generate type safe C# classes using the XSD utility. Figure 35 shows how XML technology is handled in this thesis.

XML schema definition

C# Class1 XML document

2

Objectinstance3 4

Figure 35 - XML processing

1. The XSD utility generates C# classes corresponding to the XML

schema definition used. 2. The XML schema definition is used to validate the contents of

the corresponding XML document. 3. The C# Class is instantiated in the application. 4. The XML document is serialized into the object instance. From

this point on it is possible to extract the data from the object in-stance.

The output of the XSD utility is a collection of classes capable of serializing XML documents which are valid according to the corresponding XML schema document. To view XML schema definitions and XML documents used in this thesis con-sult appendix 7.4 and 7.5.


June 2008

47

4.1.2 Serializing and deserializing XML documents Deserializing XML documents is done in the following way: XmlSerializer s = new XmlSerializer(type of object); TextReader r = new StreamReader(“fileName”); Data = (type)s.Deserialize(r); Serializing XML documents is done in the following way: XmlSerializer s = new XmlSerializer(type of object); StringWriter w = new StringWriter(); s.Serialize(w, Object to Serialize);

4.1.3 Validating XML documents To make sure XML documents where able to be serialized into the schema generated C# classes, the XML documents where validated against the corre-sponding XML schema definitions. This can be done on the fly with autocomplete when using Visual Studio.

4.2 Server implementation The implementation of the IEC 61400-25 server shall be based on the analy-sis and the constructed design in the previous chapters. As stated in the design of the server. The server is a combination of modules making up the whole server structure. Each of these modules represents a DLL file within the server. The whole solution of the project is constructed in Visual Studio Team System 2008 where each of the modules represent a single project with own name-space. The complete server solution named “61400-25” contains the following 8 pro-jects:

• IEC61400-25.ClientHandeling The client handling module, functionality to handle client association. Namespace: ClientHandeling

• IEC61400-25.DataHandleLogic The data handle logic module, functionality to handle and process ser-vice request and responses. Namespace: DataHandleLogic

• IEC61400-25.Server Main Server module and the main entry point for the server execution. Namespace: IEC61400_25


June 2008

48

• IEC61400-25.typeLibary Type library module, functionality for information model usability and type commonly used throughout the whole server. Namespace: typeLibary

• IEC61400-25.UserDatabase Access control module, functionality for loading user database and au-thenticate users. Namespace: UserDataBase

• IEC61400-25-4.ServiceInterface Service interface module, functionality to map communication protocols to server side services. Namespace: ServiceInterface

• IEC61400-25-4.Webserver Simple web server module, functionality to receive and send HTTP SOAP messages. Namespace: IEC61400_25_4Webservice

• WPPdeviceInterface WPP device interface module, functionality to receive data from WPPs. Namespace: WPPdeviceInterface

Each project is created as a C# Smart Device project with target platform to Windows CE and .NET compact framework 2.0 as the implementation runtime environment. The Server module is solely created as a Device Application to gain the property of a GUI, while others are created as class library. Device Application setting produces an executable (*.exe) file, while Class Library setting produces a dynamic link library (*.dll) file.

4.2.1 Main server module As mentioned in the design section, the server class inherits from System.Windows.Forms which makes this class a GUI enabled event driven thread. To make the server go into its event loop and show the GUI on the screen the following code must be run. // Start Server Gui thread Server Serv = new Server(); Application.Run(Serv); The last line in the code makes the server go into the GUI event loop. Once the server starts the Load event is triggered. To make the server react to the Load event the event has to be subscribed. Subscribing the Load event is done as follows:


June 2008

49

this.Load += new System.EventHandler(this.StartServer); This makes the server call the StartServer function. The StartServer function is responsible for initializing the server and starts the thread for the web server module and the thread for the WWP device connector module. Further more the client handling module and the data handle logic module is also created. The server implements a timer, which fires an event every 1 second. The timer is implemented with the following code: timerServer.Enabled = true; timerServer.Interval = 1000; timerServer.Tick += new System.EventHandler(this.timerServer_Tick); When the timer event fires, the timerServer_Tick function is called. The timerServer_Tick function is responsible for calling the UpdateAssociationS-essions function in the client handling module. The UpdateAssociationSes-sions function is explained in section 4.2.4. When the server is closed, the Closing event is fired. This event is also sub-scribed by the server and makes it call the shutdown function. The shutdown function is responsible for joining the different threads running in the applica-tion domain.

4.2.2 Simple web server module The class WebServer is the core class in this module; it is a self contained thread meaning it has functions to spawn the main web server thread. This is done through the public function Start(). public void Start() { wsthread = new Thread(new ThreadStart(run)); wsthread.Name = "Web Server"; wsthread.IsBackground = true; wsthread.Start(); } Once the web server thread has started it goes into its listening state where it will wait until a client connects. // Wait for a client to connect Socket clientSocket = server.Accept(); new ProcessClientRequest(clientSocket, responder); This will create a new ProcessClientRequest instance, and the server will en-ter the constructor of ProcessClientRequest. public ProcessClientRequest(Socket clientSocket,IResponder responder) { this.responder = responder; m_clientSocket = clientSocket; new Thread(processrequest).Start();


June 2008

50

} In this constructor a new thread will be made for every connecting client. This is consistent with the petri net defined in Figure 16 - Petri net of threading scheme in the design chapter.

4.2.2.1 webServiceResponder class The webServiceResponder class implements the IResponder interface and is therefore obligated to implement the Responder function. The Responder function is defined as follows: string Responder(string method, string page, string querystring, string fullquery, string remoteip,

out int responsecode, out string doctype); Table 6 below describes each parameter in the Responder function. Parameter Descriptions Method Specify the HTTP method. Page Specify the page request e.g “/ews” or “/ews?disco” Querystring Specify the URL Fullquery The full query of the HTTP header Remoteip Specify the IP address of the connecting client. Not used. Responsecode Specify is the request was success full or not. Response

code 200 is OK, and response code 500 represent an inter-nal server error like a SOAP fault.

Doctype Specify the document type of the HTTP response for WS its set to “text/xml” where as normal http responses set this to “text/html”

Table 6 - IResponder.Responder parameter description One of the main functions of the Responder function is to determine which particular service has been requested. This is done by performing a switch operation on the extracted service request name. The code below show the code for the SOAP associate requests message. case "AssociateRequest":

// Read the message into a Association request Object AssociateRequest associateReq = (AssociateRequest)soapFomatter.DeserializeSoapMessage(

new AssociateRequest(),soapMessageBody); // Call interface: AssociateResponse associateResp = Service.Associate(

associateReq.UserName, associateReq.Password, associateReq.LocalID, associateReq.MaxMessageSize, associateReq.UUID);

s += soapFomatter.SerializeSoapMessage(associateResp); break;


June 2008

51

All services captured by the switch statement follows the described approach:

1. Deserialize the requested service into the proper request object by using the soapFormatter.DeserializeSoapMessage function.

2. Call appropriate service with defined parameters. 3. Serialize the return response object by using the soapFormat-

ter.SerializeSoapMessage function. Consult appendix 7.5.4 for examples of SOAP message request and re-sponses.

4.2.2.2 SoapFormatter Class The SoapFormatter static class is an important part in converting SOAP mes-sages to object instances and object instances to SOAP. Each service request and response has its own defined classes. For instance the associate service has class AssociateRequest for storing Associate pa-rameters and class AssociateResponse for storing Associate return values. The request and response classes have been implemented to support XML serialization and deserialization. The static function DeserializeSoapMessage deals with deserializing service requests. static public object DeserializeSoapMessage(

object requestObject, string soapMessageBody)

{ string XMLmessage = unwrapSoapMessage(soapMessageBody); StringReader SR = new StringReader(XMLmessage); XmlSerializer XMLse = new XmlSerializer(requestObject.GetType()); requestObject = XMLse.Deserialize(SR); SR.Close(); return requestObject; } The function unwrapSoapMessage removes all SOAP elements from the SOAP message body returning the XML defined service parameters. This re-sult is then deserialized into the appropriate request object by: requestObject = XMLse.Deserialize(SR); The static function serializeSoapMessage deals with serializing service re-sponse objects into SOAP response messages. static public string SerializeSoapMessage(object responseObject) { XmlSerializer XMLse = new XmlSerializer(responseObject.GetType()); StringWriter SW = new StringWriter(); XMLse.Serialize(SW, responseObject); return soapFomatter.wrapSoapMessage(SW.ToString()); } The function wrapSoapMessage wraps the newly created XML in a SOAP response message. Consult appendix 7.5.4 for examples.


June 2008

52

4.2.3 Service interface module The service interface module contains the class ServiceInterfaceFacade. This class implements the IServices61400_25_4 interface which requires the Ser-viceInterfaceFacade class to implement all functions defined in the interface. The job of the ServiceInterfaceFacade class is to make a gateway into the server, hence the name façade. All services are directed into the server in the same manner. The code below shows this structure for the Association service. public AssociateResponse Associate( string UserName, string Password, string LocalID, uint MaxMessageSize, string UUID) { // Get and lock handle AssociateResponse AR = clientHandleSingleton.GetHandle().

Associate(UserName,Password,LocalID,MaxMessageSize,UUID); // release the handle and unlock clientHandleSingleton.releaseHandle(); return AR; } All implemented services follow the described approach.

1. Get the handle to the client handling module. 2. Call appropriate service with defined parameters. 3. Release the handle to the client handling module. 4. Return the service response object (defined in type library mod-

ule) If the service is not implemented in the server, the service function will throw an exception as follows: throw new ServiceNotAvalibleException(); The ServiceNotAvalibleException class is described in section 4.2.6.3.

4.2.4 Client handling module The main class in the client handling module is the clientHandeling class. This class holds several functions regarding the handling of user association.

• AddClient(string AssocID) , adds a client to the list of connected clients. • isConnected(string AssocID), check to see if the client is associated. • PurgeAssociations(), removes all clients from the clients connected list. • RemoveClient(string AssocID), removes the client with the specified

association ID. • UpdateAssociationSessions(), Updates the client connected list, and

removes all clients which has timed out.


June 2008

53

• UserIsConnected(string Username), check the client connected list to determine if the specified username is already associated.

Common for all service request made to the clientHandeling class is to check the client has been associated previously. This is done in the following way: if (isConnected(AssocID)) { // Performe requested operation } else { // Association not found. clientHandleSingleton.releaseHandle(); throw new AssociationExeption(); } If the Association ID check fails, an AssociationException is thrown. This ex-ception is described in section 4.2.6.3.

4.2.5 Data handling logic module The main class in the data handling logic module is the dataHandlingLogic class. The class holds the instance of the information model and the instance of the dataSetManager. The dataSetManger manages non-persistent data sets. // IEC 61400-25-2 Information model tServer Data; // Data set manager for non-persistent data sets. dataSetManager dataSetMan; These are initialized in the dataHandlingLogic constructor. // Load information model into memory LoadInformationModel("\\hard disk\\data\\informationModel.xml"); Console.WriteLine("Information model loaded into memory."); Data.BuildReferenceTree(); Console.WriteLine("Building Reference Tree of model."); dataSetMan = new dataSetManager(); Once the information model has been loaded into memory, the Data.BuildReferenceTree() function is called on the Data object. This function is described in section 4.2.6.1. To view the sample XML data of the information model used in this thesis; consult appendix 7.5.3.

4.2.6 Type library module (including information model) The type library module is a collection of commonly used classes. To view all class names consult appendix 7.3.


June 2008

54

4.2.6.1 typeLibTools class This class is the base class for classes in the information model hierarchy, and contains virtual functions for the information model classes to inherit. The class contains the following functions:

• BuildReferenceTree(string subReference), is a recursive function for building the object reference in every information model node.

• findReference(string objReference), is a recursive function for finding the object instance which are associated with the parameter objRefer-ence.

• GetDataAttributevalues(List<tDataAttributeValue> AttrList, tFC FC), is a function for getting all data attribute values at the leaf node of a hier-archy branch.

• SetDataAttributeValue(tDataAttributeValue, tFC), is a function for set-ting data attributes at the specified node.

The attribute reference is the current object reference to a specific node in the data hierarchy.

4.2.6.2 Information model The implementation of the information model is a result of the analysis in sec-tion 2.1.2 and the design in section 3.2.6.1. Classes in the analysis are mapped to types in the implementation. Consult Table 7 for mapping.

Model node name Implemented class type Logical device tLD Logical Node tLN Common Data Class tData Data attribute tDataAttribute Data attribute tDAtype Data attribute component tDAtype

Table 7 - Information model names mapped to types The types in the information model where generated by the XSD tool de-scribed in section 4.1. The generated C# classes all spawned with the “partial” keyword in the class definition. public partial class tLD {…} This feature makes it possible to spread the class definition over 2 or more files. This is an advantage in this case, because all information model types where generated. Therefore additional contents to the class definition can be added in a second file without changing the generated code. If there is a re-generation of the code for some reason the added code would not be lost.


June 2008

55

4.2.6.3 ServerException class This section describes the implementation of the custom Exceptions used in this thesis. The ServerException class inherits from System.Exception to gain the proper-ties of exceptions. The class contains two properties

• ERRORMESSAGE, SOAP formatted fault code. • ERRORDETAILS, details about the error.

Both the AssociationExeption and the ServiceNotAvalibleException class in-herits from the ServerException class. The only thing changed is the sounding of the error details. Table 8 shows the message. Exception class ERRORMESSAGE ERRORDETAILS ServerException Server.AErrorOccoured The Server generated a error AssociationExeption Client.MustAssosiate Client must associate to perform

requested operation ServiceNotAvalibleException Server.NoSuchService The requested service was not

Available Table 8 - Exception Error messages and details

Common for all the Server exception classes is that they are couth in the web server module and translated into SOAP fault messages. Fault messages which consequently are sent to the client.

4.2.7 Access control module The accessControl class is a simple class for storing and authentication of users. The class contains one function: public bool hasCredentials(string username, string password) { foreach (User Usr in UserDB.User) { if (Usr.UserName == username && Usr.Password == password) return true; } return false; } The hasCredentials iterates the user database to check username and pass-word match up. Besides this, the XML user database is loaded into the class UserDataBase on creation of the accessControl object. To view a sample of the XML docu-ment containing the defined users, consult appendix 7.5.1.


June 2008

56

4.3 Client implementation The implementation of the IEC 61400-25-3 client framework shall be based on the analysis and the constructed design in the previous chapters. The implementation of the client solution contains the following projects.

• Client-IEC61400-25, is a simple GUI client using the framework to make service requests to an IEC61400-25 compliant server. Namespace: Client_IEC61400_25

• IEC61400-25-5, is the test project for this thesis and contains unit tests for testing the client framework. Consult chapter 5 for more details. Namespace: IEC61400_25_5

• IEC64100-25-4WS, is the IEC61400-25-3 client framework module, which is designed to consume any web services compliant with the IEC 61400-25-4 WSDL document. When compiled the binary output is a DLL file. Namespaces:

o IEC64100_25_4WS , hosting the interface mapping. o IEC64100_25_4WS.iecWS, hosting the WS stub generated file. o ServiceInterface, hosting the ServiceInterface borrowed from the

server implementation and modified to fit the mapping in ques-tion.

4.3.1 IEC 61400-25-3 client framework The framework uses the WSconnector class as the entry point for the frame-work. All service calls must use this class to be able to connect to a IEC 61400-25 compliant server.

4.3.1.1 WSconnector class When initialising the WSconnector class, one must supply a XML configura-tion file containing WS addressing to the WSconnector constructor. Otherwise the default internet address is selected (http://127.0.0.1:8000/ews). This con-figuration file is based on the XML schema definition shown in appendix 7.4.2. The class holds one member type, the WSobject which is an instantiation of the generated web service proxy stub. Typically the service functions are implemented as in the following example: public AssociateResponse Associate( string UserName, string Password, string LocalID, uint MaxMessageSize, string UUID) {


June 2008

57

AssociateResponse AR = new AssociateResponse(); AR.Items = WSobject.Associate( UserName,Password, LocalID, MaxMessageSize, ref UUID); AR.UUID = UUID; return AR; }

1. New service response object is created 2. The proper service function is called in on the WSobject. 3. Depending on the out put of the WSobject service call,

some return values might require conversion to service response objects.

4. The service response object is returned to the client using the framework.

4.3.1.2 Building requests for WSconnector functions Some services require more complex parameters than just simple types. This section gives examples on how some of these parameters are constructed. The following example is taken from the unit test case S_svr6, and involves the parameter building for the service SetDataValues. tFcdFcdaType oFC = new tFcdFcdaType(); oFC.FC = tFC.MX; oFC.Ref = "Orestad/WTUR.W"; tDataAttributeValue[] oDataAttr = new tDataAttributeValue[1]; oDataAttr[0] = new tDataAttributeValue(); oDataAttr[0].DataAttrRef = "Orestad/WTUR.W.mag.i"; tDataAttribute oData = new tDataAttribute(); oData.FC = oFC.FC; // Build a basicType tBasicType oBasic = new tBasicType(); oBasic.ItemElementName = ItemChoiceType.int32; oBasic.Item = (string)"32"; // Build A container for DAType tDAType oDAType = new tDAType(); oDAType.DAName = "i"; oDAType.Items = new object[1]; oDAType.Items[0] = oBasic; // Wrap the result into DataAttributeValue object. oData.DAType = oDAType; oDataAttr[0].Value = oData; SetDataValuesResponse SDV = DUT.SetDataValues(oFC, oDataAttr, UUID, AssocID); This particular service request will attempt to set the value at object reference “Orestad/WTUR.W.mag.i" to integer value 32.


June 2008

58

4.4 Sub conclusion This chapter has presented the implementation of an IEC 61400-25 compliant server, and the implementation of an IEC 61400-25-3 Client framework. The implementation explains how XML documents and XML schema defini-tions where used to parse XML information into service request and response objects. This feature is used in the web server, and makes the parsing of XML very simple through the use of SOAP formatting classes. Further more XML schemas based on the IEC 61400-25-4 WSDL was re-sponsible for creating the type library module. Many of the type are not actu-ally used in this thesis, but are present if one decides to expand the server with more services or IEC 61400-25 report and logging. Even through the implementation of the WPP simulator is left out, the basic design and implementation are in place for further development.


June 2008

59

5 Test and principles This chapter will test the implemented solution, to confirm the compliance with the IEC 61400-25-5 conformance testing test cases chosen. The chosen test cases where selected in chapter 2 section 2.2.3. Aspects of test driven development have been used to carry out the chosen tests. These principles are discussed in section 5.1. The test result of the IEC 61400-25-5 conformance tests are discussed in sec-tion 5.3.

5.1 Test driven development As described by the inventor of TDD, Kent Beck states “Clean code that works – now”. Test Driven Development is as the name states, driving the development in a test driven fashion. Even through most software projects uses test driven de-velopment in the sense of the word it does not necessarily mean TDD princi-ples where used. An example of this:

• The authors of this thesis, is familiar with visual confirmation running of written code behaviour. This usually includes writing of code and ob-serving what the code execution is doing what is supposing to do. If the code behaves unexpectedly then repeat the process all over again.

This is essentially what the principles behind TDD does, but just in an auto-mated way or by unit testing, as explained later.

5.1.1 Software requirements The fist step in any software project is the requirements of the developed software. In this thesis some of the requirements are defined by the IEC 61400-25 standard and some are chosen within the scope of what can be achieved within the standard. By applying TTD to the software requirements would involve writing the tests before the actual code implementation. In a sense of manner the written tests can be considered as the requirements of the actual code. Figure 36 shows the process of states in TDD.

Requirements Unit test / Automated test

Feature codeTest execution results

Run the test

Implement test code

Define in code

Figure 36 - States in TDD


June 2008

60

• Requirements are defined. In this thesis the requirements where in the analysis chapter.

• Requirements are defined in test code. • Test code is implemented. • The Feature code is implemented. • All defined tests are run and the test execution results shows if the fea-

ture code is fulfilling the specified requirements. In this thesis the requirements states that test cases from the IEC 61400-25-5 must be applied to the solution in a TDD fashion.

5.1.2 The test driven cycle The TTD cycle is a tree step phase, which is also referred to as the Red/Green/Refactor process. This process cycle is a development technique which provides fast response to the changes made in the application and will let the application grow ensuring all requirements are met. This is because when adding new additional feature to the application, one can rely on the growing number of unit test to make sure code is not broken by the additional new feature. In this thesis only the two first cycles have been used. This is because TDD was introduced relatively late in the project period.

5.1.2.1 Red step Before creating any application code, the corresponding test code should be constructed. Since there is no featured code in the application, one has to cre-ate empty shells to tests up against. This shell will eventually become the im-plementation but not in this step. It is important to make sure the test fails at this point. Hence the name Red step. Intuitively it makes sense that a test against an empty class or method should fail.

5.1.2.2 Green step The next step in the process cycle is to create the actual logic in the applica-tion code. The implemented logic does necessarily not make the defined test pass, but is an indicator that the chosen algorithms might be wrong. That is why the developer, must continue to rewrite the chosen logic until it passes the specific test. Hence the name Green step. One of the fundamental aspects in TDD is the statement that implementation must be as simple as possible. This can however sometimes be hard to ac-complish with very complex algorithms and logic. Therefore TDD allows falsi-fication of logic to make the test pass for the time being. In the longer terms this means the logic is too complex to be handled by a single function or class. This will in the end result in more sub functions or classes and thus tests to confirm these.


June 2008

61

5.1.2.3 Refactoring step Once the test passes it is time to refactor the implementation logic. Refactor-ing means cleaning up the code and making the code correspond to good de-sign principles. One important aspect of refactoring is that it does not fix bugs or change the functionality of the design. Rather it makes the code more understandable, or improves the design and structure to make future maintenance easier for the developer. Once the last step has been completed new features can be added by going back to the Red step. Lastly but not least, TDD does not make good designs but ensures the design chosen works. Good system designs are still up to the skill of the developer.

5.2 Unit tests Unit tests are what the name applies. A test on a unit. In this thesis “the unit” is the IEC 61400-25-3 client framework. Some may argue this is a large unit, but nevertheless a unit. The mechanism of a unit test is a part of a larger generic testing framework. Several testing frameworks exist for the implementation language chosen in this thesis. To name the most pronounced are NUnit and Microsoft’s unit test-ing framework. NUnit is an open source testing framework, where as Microsoft’s unit testing framework is only available in the professional edition of Visual Studio 2005/2008. For this thesis the Microsoft’s unit testing framework was chosen to implement the tests. The incitement for this choice is based on the fact that the testing framework where already available in the development environment.

5.2.1 Microsoft unit testing framework The unit testing framework from Microsoft is only available in the professional and higher editions of Visual studio 2005 / 2008. The framework is an inte-grated part of the Microsoft.VisualStudio namespace. The full namespace for the unit testing frame work is:

Microsoft.VisualStudio.TestTools.UnitTesting To begin using the test functionality in Visual Studio, a test project must be created. In this thesis the test project is a part of the IEC 61400-25-3 client framework solution. The project name is denoted “IEC 61400-25-5” as for the coherence with the IEC 61400-25-5 conformance test cases. The namespace of this test project is “IEC61400_25_5”


June 2008

62

Once the project has been created, its time to add a test class. The method used in this thesis to create a test class is a follows:

• Right click on the function to be tested and choose “Create unit tests…” in the context menu.

• This will prompt for the creation of a test class. The test class in this thesis is called “WSconnectorTest”. Definition of the test class can be seen in the code below. [TestClass()] public class WSconnectorTest {…} The syntax [TestClass()] tells Visual Studio that this class is a test class. Now its time to add the actual unit tests. Unit test defined in Visual Studio is actually functions with special syntax. To define such a function, view the fol-lowing example: [TestMethod()] public void UNIT_Test_Name() {…} The above example will generate a unit test with the name “UNIT_Test_Name”. An empty unit test will always pass. Therefore it is the responsibility of the developer to use the testing framework functions and ca-pabilities to test the target class or function. Below is a list of commonly used testing functions in this thesis.

• Assert.IsInstanceOfType(Actural, Target); This function check that the actual type is equal to the Target type.

• Assert.AreEqual(Actual, Target); This function check that the Actual object value are equal to the Target value.

The Microsoft Unit testing framework contains a lot more testing function than mentioned here. Descriptions of these can be found on the Microsoft website6.

5.3 Test results The IEC 61400-25 server implementation has been tested both manually and with automated unit tests. Emphasis is however applied to automated test, as these results can easily be documented.

5.3.1 Manual testing Through out the implementation manual testing has been carried out to re-solve overall system behaviour. This was mainly done by using a simple GUI

6 http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.assert_methods(VS.80).aspx


June 2008

63

client which uses the IEC 61400-25-3 client framework for communication to the server. The result of these manual tests is however not documented in this thesis, but should be mentioned that the method is used.

5.3.2 Automated tests The automated test or the application of unit test methods where introduced relatively late in the project period. These test proved invaluable as they dis-covered runtime scenarios where the system would fail. These errors are however not described in this thesis as they resulted in rewriting of the code logic. The errors found while using automated tests did not change the overall design of the server, as issues with the overall design where resolved using manual testing.

5.3.3 Unit test results The table below shows the result of the executed unit tests. Test case State Description S_Ass1 No Test The test was not possible in the current test setup. S_Ass2 No Test The test was not possible in the current test setup. S_Ass3 Passed The test was limited to one client instead of a maxi-

mum numbers of clients. S_AssN1 No Test Due to authentication is always on. S_AssN2 Passed S_AssN3 No Test Due to server not supporting a maximum association. S_AssN4 No Test Can not be preformed with unit tests S_AssN5 No Test Can not be preformed with unit tests S_Ds1 Passed S_Ds2 Passed Maximum data set members are set to 2 S_Ds3 Passed Maximum data set members are set to 2 S_Ds4 Passed S_Ds5 Passed S_Ds6 Passed S_Ds7 Passed S_Ds8 No Test Due to S_Ds1-7 covers this test S_Ds9 No Test Due to S_Ds1-7 covers this test S_Ds10 Passed S_DsN1 Passed S_DsN2 Passed S_DsN3 No Test S_DsN4 No Test Due to Server has no maximum # allowed data sets S_DsN5 No Test Due to Server has no maximum # allowed data sets S_DsN6 No Test Due to Server has no maximum # allowed members

on data sets. S_DsN7 No Test Due to Server has no maximum # allowed members

on data sets.


June 2008

64

S_DsN8 Passed S_DsN9 Passed S_DsN10 No Test No predefined data set available in the server. S_DsN11 Passed S_DsN12 Passed S_DsN13 No Test Report control class not implemented in server. S_DsN14 No Test Server does not support read only values. S_Svr1 Passed S_Svr2 Passed S_Svr3 Passed Only WTUR Logical Node is examined with GetLogi-

calNodeDirectory. S_Svr4 Passed Only WTUR Logical Node is examined. GetDataDefini-

tion not implemented and is left out of test. S_Svr5 No Test Server does not support a maximum on GetDataVal-

ues S_Svr6 Passed All values are write enabled. Tested one branch

WTUR.W.mag.i S_Svr7 No Test Maximum data value cap not supported by server S_Svr8 No Test GetAllDataValues not supported S_SvrN1 Passed S_SvrN2 No Test Out-of-range not supported by server S_SvrN3 Passed S_SvrN4 No Test Read only values not supported by server Color legend 44 total Test has passed 23 Passed Test has failed 0 Failed Test not implemented 21 No Test

Table 9 - Test results of chosen IEC 61400-25-5 test cases

5.4 Sub conclusion Even though TDD was introduced late in the project period, TDD proved to be very valuable regarding tests. TDD helped remove some errors which other-wise would have been left undiscovered. Unit test cases where based on IEC 61400-25-5 conformance testing and chosen test cases in this standard. Before TDD was introduced manual testing was done through a simple GUI interface using the IEC 61400-25-3 client framework. See in the back mirror this method is both cumbersome and slow compared to the techniques from TDD. The test result descriptions also gives clues to where and what to improve in the server. E.g the description reads “Server does not support read only val-ues.” Suggest improvements to the Data attribute value in supporting the read/write property.


June 2008

65

6 Main conclusion A study of the IEC 61400-25 standard has been preformed, as well as studies of previous work of the IEC61400-25 standard. These studies have resulted in the implementation of an IEC 64100-25 compliant server and an IEC 64100-25-3 Client framework.

6.1 IEC 61400-25 Server The main contributor from pervious work has been the work of Andreas Kar-gård Olsen & Baris Özdil - Prototype for a IEC 61400-25 Compliant Generic Server. Which contributed with their proposal to a IEC 61400-25 system archi-tecture. This resulted in a module based server design. Each module has been analysed according to the IEC 61400-25, and designed to fit the overall proposal. Other contributor from previous work has been the work of Umut Korkmaz - Reporting and logging in compliance with IEC 61400-25. This work has been great inspiration for solving various IEC 61400-25 problems and understand-ing the essentials of the IEC 61400-25 standard. Key differences from pervious work are the deployment platform. Where pre-vious work deployed on standard PC’s, this thesis is deploying on an industrial PC, which posses a whole different environment. The industrial PC used in this thesis is supplied Brodersen Controls A/S. The product in question is a RTU32. The implementation environment is the Microsoft .NET Compact framework 2.0 which generically does not support web services. Therefore a simple web server had to be included in the design and implementation of the project. This web server is also responsible for the mapping of web services to IEC 61400-25-3. From the out side, it will appear as the IEC 61400-25 server supports the mapping of web services to IEC 61400-25-4 annex A. The web service supports all types and SOAP messages defined in the official IEC 61400-25-4 WSDL document. Even though some of the services are not supported by the inner working of the server, important services for directory requesting, data sets and data manipulation have been implemented. Ser-vices not supported are services regarding IEC 61400-25 report and logging. XML technology was used extensively in this thesis as all of the types defined in the IEC 61400-25 standard was generated using XML schema definitions. Generation from these XML schema definitions made for string type safe li-braries. This was done to ensure complete type compatibility with the defined web services in IEC 61400-25-4 Annex A.


June 2008

66

The IEC 61400-25-2 information model was analysed and designed accord-ingly to the standard. More specific the model approach was chosen from the model described in IEC 61400-25-4. The implementation of the information model is a very basic model compared to the functionality but not on the hier-archical structure. The model is capable of holding any structure desired by an developer of a IEC 61400-25 system. User authentication is done in a simple way, and only to decide if users has access or not. User association has a degree of handling, as the server sup-ports session timeouts and resource clean up after a session has been termi-nated. The cases from the IEC 61400-25-5 conformance testing was analysed and selected test cases where chosen. The IEC 61400-25 server was tested by using techniques from Test Driven Development and unit tests. The unit test framework chosen to implement these tests was the testing framework from Microsoft. Testing was done thru the IEC 61400-25-3 client framework, and revealed several errors which had not been found using conventional visual testing. The implementation of the WWP simulator has not been implemented, nor has the connection to a real WWP. Despite these are missing, the analysis and design takes these into consideration. Basic structure and threading scheme has been considered and partly implemented.

6.2 IEC 61400-25-3 Client framework The IEC61400-25-3 client framework is a framework designed to connect to any IEC 61400-25 compliant server which offers web services as communica-tion profile to the server. The output of the implementation is a .NET class library which other .NET en-abled applications can use. In this thesis a very small GUI client was made to use the interface the library provided.

6.3 Future work This section will discuss future work.

6.3.1 Improvements to the IEC 61400-25 Server

• Since this point was left out of this thesis, it would be obvious to sug-gest this as future work. Connecting the server to a real wind power plant and to device an implementation which in a smart way maps real wind power plant data to the information model. Making the mapping of the wind power plant in such a way that the operate class in IEC 61400-25 makes it possible to control certain aspect of the wind power plant.


June 2008

67

• Improving the simple web server. The current web server, is all too sim-ple to handle anything else than web services. Currently the web server has no security which poses a major threat to security issues. As for now an attacker could easily gain access to the IEC 61400-25 server with a simple line tap. Enhancing the web server to handle more ad-vanced security would greatly improve the usability of the web server in a commercial aspect.

• The access control in the implementation of the IEC 61400-25 server is a simple user authentication. The access control module has been pre-pared to handle role based security. But other access control schemes could also be coupled with the information model. An example could be group based security used in windows. Further more a configuration language to handle these security features could be deviced.

6.3.2 Additional improvements to the IEC 61400-25 server

• Adding IEC 61400-25 report and logging. These topics have been cov-ered in previous work, but they are still to be proven on an industrial PC.

• Making a complete IEC 61400-25-5 conformance testing system which not only relies on the limitations of unit tests.

• Construction of a full IEC 61400-25 system which is equilant to Figure 1 - IEC 61400-25 Domain model. This would involve also implementing the information model on the client side. Which in terms would raise questions on how the client side should be designed and constructed. Connecting this system to a real commercial SCADA system.


June 2008

68

7 Appendix

7.1 Original project description Project description Previous master thesis has created some of the basic software platform for an implementation of IEC61400-25 in real running environment. The main objec-tive for this thesis is to evaluate the basic software platform prepared, make necessary improvements and deploy the solution on an industrial PC platform, ready to run in a real wind turbine. The project includes as well a validation and test of the solution created. Tasks to be performed

- Study of the standard IEC61400-25 series - Study of work done by Andreas Kargård Olsen & Baris Özdil – A Proto-

type for a IEC 61400-25 Compliant Generic Server, November 2006 - Study of work done by Umutz Korkmaz – Reporting and Logging in

compliance with IEC 61400-25, July 2007 - Identify improvements on previous study in order to have a complete

solution running for IEC61400-25-4 Annex A. Mapping to Web services. - Specify the environmental requirements for a solution to IEC61400-25-

4 Annex A. Mapping to Web services. - Implement a solution to IEC61400-25-4 Annex A. Mapping to Web ser-

vices. - Deploy the solution on an industrial PC platform - Brodersen type

RTU32 - Validate the solution against compliance test defined in IEC61400-25 - Test the deployed solution against a real running wind turbine – Risø

xxxx Expected output of the project - deliverables

- Report on o study work performed o proposals for improvements on previous work performed o implementation considerations and environmental requirements o validation and tests performed o analysis of results obtained o proposal for improvements for implementations on other plat-

forms o conclusion of the work performed

- Running PC system adapted to the test wind turbine including

o Specification of PC hardware and software platform selected o Source code for the PC system o Compiler scripts required if any o Specify any other support application required to run the solution


June 2008

69

7.2 Expanded view of information model class diagram

This appendix is the expanded view of the information model class diagram. Please note the inheritance of class typeLibTools is not includes in this dia-gram. To view the correlation with class typeLibTools reference Figure 29 at page 40.


June 2008

70

7.3 Type Library module class listing Class Class Class AbortRequest AbortResponse AddSubscriptionRequest AddSubscriptionResponse AssociateRequest AssociateResponse AssociateResponseItem-sChoiceType

AssociationExeption CancelRequest

CancelResponse CommandTerminationRe-quest

CommandTerminationRe-sponse

CreateDataSetRequest CreateDataSetResponse DeleteDataSetRequest DeleteDataSetResponse GetBRCBValuesRequest GetBRCBValuesResponse GetDataDefinitionRequest GetDataDefinitionResponse GetDataDirectoryRequest GetDataDirectoryResponse GetDataSetDirectoryRequest GetDataSetDirectoryRe-

sponse GetDataSetValuesRequest GetDataSetValuesResponse GetDataValuesRequest GetDataValuesResponse GetLCBValuesRequest GetLCBValuesResponse GetLogicalDeviceDirectoryRe-quest

GetLogicalDeviceDirec-toryResponse

GetLogicalNodeDirec-toryRequest

GetLogicalNodeDirectoryRe-sponse

GetLogStatusValuesRequest GetLogStatusValuesRe-sponse

GetServerDirectoryRequest GetServerDirectoryResponse GetURCBValuesRequest GetURCBValuesResponse ItemChoiceType ItemsChoiceType ItemsChoiceType1 ItemsChoiceType2 ItemsChoiceType3 ItemsChoiceType4 ItemsChoiceType5 ItemsChoiceType6 ItemsChoiceType7 OperateRequest OperateResponse QueryLogAfterRequest QueryLogAfterResponse QueryLogByTimeRequest QueryLogByTimeResponse ReleaseRequest ReleaseResponse RemoveSubscriptionRequest RemoveSubscriptionRe-

sponse ReportRequest

ReportResponse SelectRequest SelectResponse SelectWithValueRequest SelectWithValueResponse ServerExeption ServiceNotAvalibleException SetBRCBValuesRequest SetBRCBValuesResponse SetDataSetValuesRequest SetDataSetValuesResponse SetDataValuesRequest SetDataValuesResponse SetLCBValuesRequest SetLCBValuesResponse SetURCBValuesRequest SetURCBValuesResponse tAddCause tArray tBasicType tCheck tCodedEnum tControlValue tData tDataAttrBasicType tDataAttribute tDataAttributeDefinition tDataAttributeValue tDataAttrType tDATASet tDAType tDetailQual tEntryData tEnumerated tFC tFcdFcdaType tIEMcls TimeActivatedOperateRe-

quest TimeActivatedOperateRe-sponse

tLD tLN tLOGEntry tObjectClass tOptFldsBRCB tOptFldsLCB tOptFldsURCB tOrcat tOrcatValue tOrigin tPresence tQuality tRCBType tReportFormat tResult tServer tServiceError tSimpleData tSource tTimeStamp tTimOperRsp tTrgCond tValidity typeLibTools


June 2008

71

7.4 XML Schema definitions

7.4.1 Access control module - UserDataBase.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="Users" targetNamespace="http://tempuri.org/Users.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/Users.xsd" xmlns:mstns="http://tempuri.org/Users.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:simpleType name="Role"> <xs:restriction base="xs:string"> <xs:enumeration value="Server-administator"/> <xs:enumeration value="WPP-Operator"/> <xs:enumeration value="Guest"/> </xs:restriction> </xs:simpleType> <xs:complexType name="User"> <xs:sequence> <xs:element name ="UserName" type ="xs:string"/> <xs:element name ="Password" type ="xs:string"/> </xs:sequence> <xs:attribute name ="FirstName" type="xs:string"/> <xs:attribute name ="LastName" type ="xs:string"/> <xs:attribute name ="Role" type ="Role"/> </xs:complexType> <xs:element name="UserDataBase"> <xs:complexType> <xs:sequence> <xs:element name="User" type="User" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

7.4.2 IEC61400-25-3 Client framework - configFile.xsd <?xml version="1.0" encoding="utf-8"?> <xs:schema id="configFile" targetNamespace="http://tempuri.org/configFile.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/configFile.xsd" xmlns:mstns="http://tempuri.org/configFile.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="WebserviceConfig"> <xs:complexType> <xs:sequence> <xs:element name="Site" type ="xs:string" default="127.0.0.1"/> <xs:element name="Port" type ="xs:unsignedInt" default="80"/> <xs:element name="Folder" type ="xs:string" default="ws"/> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>

June 2008

72

7.4.3 Type library module – typeLibary.xsd This appendix is 30 page plus, and can be found on the appendix CD-Rom. Below is shown secments of the actual file.

7.4.3.1 Associate Request and Response  <s:element name="AssociateRequest"> <s:complexType> <s:annotation> <s:documentation> AssociateRequest is the message used when a client try to establish an association to a server</s:documentation> </s:annotation> <s:sequence> <s:element name="UserName" type="s:string"/> <s:element name="Password" type="s:string"/>  <s:element name="LocalID" type="s:string" minOccurs="0"/> <s:element name="MaxMessageSize" type="s:unsignedInt"/> </s:sequence> <s:attribute name="UUID" type="ews:tstring36" use="optional"/> </s:complexType> </s:element>  <s:element name="AssociateResponse"> <s:complexType> <s:choice> <s:sequence> <s:element name="MaxMessageSize" type="s:unsignedInt" minOccurs="0"/> <s:element name="AssocID" type="ews:tAssocID"/> </s:sequence> <s:element name="ServiceError" type="ews:tServiceError" minOccurs="0" maxOccurs="1"/> </s:choice> <s:attribute name="UUID" type="ews:tstring36" use="optional"/> </s:complexType> </s:element>

7.4.3.2 Information model tDAType <s:complexType name="tDAType"> <s:annotation> <s:documentation>Container for DAType</s:documentation> </s:annotation> <s:sequence> <s:choice minOccurs="1" maxOccurs="unbounded"> <s:element name="DAComp" type="ews:tDAType" minOccurs="0" maxOccurs="unbounded"/>

June 2008

73

<s:element name="PrimComp" type="ews:tBasicType" maxOccurs="1"/> </s:choice>  </s:sequence> <s:attribute name="DAName" type="ews:tObjectName" use="required"/> <s:attribute name="ix" type="s:integer" use="optional"/>  </s:complexType> tDataAttirbute  <s:complexType name="tDataAttribute"> <s:annotation> <s:documentation>Container for DataAttributes</s:documentation> </s:annotation> <s:sequence> <s:element name="DAType" type="ews:tDAType"/> <s:element name="TrgOp" type="ews:tTrgCond" minOccurs="0" maxOccurs="1"/> </s:sequence> <s:attribute name="FC" type="ews:tFC" use="required"/> </s:complexType> tSimpleData  <s:complexType name="tSimpleData"> <s:sequence maxOccurs="unbounded"> <s:element name="DataAttr" type ="ews:tDataAttribute"/> </s:sequence> <s:attribute name="DataName" type="ews:tObjectName"/> </s:complexType> tData  <s:complexType name ="tData"> <s:sequence> <s:choice maxOccurs="unbounded"> <s:element name= "DataAttr" type="ews:tDataAttribute" minOccurs="0" maxOccurs="unbounded"/> <s:element name= "CompositeCDC" type ="ews:tData" minOccurs="0" maxOccurs="unbounded"/> <s:element name= "SimpleCDC" type ="ews:tSimpleData" minOccurs="0" maxOccurs="unbounded"/> </s:choice> </s:sequence> <s:attribute name="DataName" type ="ews:tObjectName"/> </s:complexType> tLN  <s:complexType name="tLN"> <s:sequence> <s:element name = "Data" type="ews:tData" minOccurs="0" maxOccurs="unbounded"/>

June 2008

74

<s:element name = "DataSet" type ="ews:tDATASet" minOccurs="0" maxOccurs="unbounded"/> </s:sequence> <s:attribute name ="LNName" type ="ews:tObjectName"/> <s:attribute name ="LNRef" type ="ews:tObjectReference"/> </s:complexType> tLD  <s:complexType name ="tLD"> <s:sequence> <s:element name="LN" type="ews:tLN" minOccurs="3" maxOccurs="unbounded"/> </s:sequence> <s:attribute name ="LDName" type ="ews:tObjectName"/> <s:attribute name ="LDRef" type ="ews:tObjectReference"/> </s:complexType> tServer  <s:element name="tServer"> <s:complexType> <s:annotation> <s:documentation> Container for Server objects </s:documentation> </s:annotation> <s:sequence> <s:element name ="ServerAccessPoint" type="s:string" maxOccurs="unbounded"/> <s:element name ="LD" type ="ews:tLD" maxOccurs="unbounded"/> </s:sequence> </s:complexType> </s:element>


June 2008

75

7.5 XML documents

7.5.1 Access control module – userdatabase.xml <?xml version="1.0" encoding="utf-8" ?> <UserDataBase xmlns="http://tempuri.org/Users.xsd"> <User FirstName ="Thomas" LastName="Køhrsen" Role="Server-administator"> <UserName>Admin</UserName> <Password>minda</Password> </User> <User FirstName ="John" LastName="Doe" Role="WPP-Operator"> <UserName>JohnDoe</UserName> <Password>IamNoOne</Password> </User> <User FirstName ="Guest" LastName="Guest" Role="Guest"> <UserName>Guest</UserName> <Password>Guest</Password> </User> </UserDataBase>

7.5.2 IEC61400-25-3 Client framework – wsconfig.xml <?xml version="1.0" encoding="utf-8" ?> <WebserviceConfig xmlns="http://tempuri.org/configFile.xsd"> <Site>10.0.0.1</Site> <Port>8000</Port> <Folder>ews</Folder> </WebserviceConfig>

June 2008

76

7.5.3 Information model – informationModel.xml This XML document is loaded into the server memory to build the information hierarchy. <?xml version="1.0" encoding="utf-8" ?> <tServer xmlns="http://iec.ch/61400/ews/1.0/"> <ServerAccessPoint>ServerRTU32</ServerAccessPoint> <LD LDName="Orestad" LDRef="Orestad">  <LN LNName="LLN0" LNRef="Orestad/LLN0"> <Data DataName="NamPlt"> <DataAttr FC="DC"> <DAType DAName="Vendor"> <PrimComp> <visibleString>WindCorp</visibleString> </PrimComp> </DAType> </DataAttr> </Data> </LN>  <LN LNName="LPHD" LNRef="Orestad/LPHD"> <Data DataName="PhyNam"> <SimpleCDC DataName="WDPL"> <DataAttr FC="DC"> <DAType DAName="vendor"> <PrimComp> <visibleString>WindCorp windpower</visibleString> </PrimComp> </DAType> </DataAttr> <DataAttr FC="DC"> <DAType DAName="hwRev"> <PrimComp> <visibleString>41.10a</visibleString> </PrimComp> </DAType> </DataAttr> <DataAttr FC="DC"> <DAType DAName="tmOffset"> <PrimComp> <int16>60</int16> </PrimComp> </DAType> </DataAttr> <DataAttr FC="DC"> <DAType DAName="tmUseDT"> <PrimComp> <Boolean>1</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="DC"> <DAType DAName="tmAutoDT"> <PrimComp> <Boolean>1</Boolean> </PrimComp>

June 2008

77

</DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="PhyHealth"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int16>0</int16> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Source="process" Validity="good"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="33"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="Proxy"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int16>0</int16> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Source="process" Validity="good"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="33"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> </Data> </LN>  <LN LNName="WTUR" LNRef="Orestad/WTUR">  <Data DataName="OpTmRS">

June 2008

78

 <SimpleCDC DataName="manRS">  <DataAttr FC="CO"> <DAType DAName="ctlVal"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CO"> <DAType DAName="origin"> <PrimComp> <visibleString>Some Where</visibleString> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" test="false" Source="process" operatorBlock="false"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="10"/> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CF"> <DAType DAName="ctlModel"> <PrimComp> <codedEnum numBits="1">1</codedEnum> </PrimComp> </DAType> </DataAttr> </SimpleCDC>   <SimpleCDC DataName="hisRS"> <DataAttr FC="CO">  <DAType DAName="ctlVal"> <PrimComp> <codedEnum numBits="1">0</codedEnum> </PrimComp> </DAType>


June 2008

79

</DataAttr> <DataAttr FC="CO"> <DAType DAName="origin"> <PrimComp> <visibleString>Some Where</visibleString> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" test="false" Source="process" operatorBlock="false"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="10"/> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CF"> <DAType DAName="ctlModel"> <PrimComp> <codedEnum numBits="1">1</codedEnum> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="actTmVal"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" test="false" Source="process" operatorBlock="false"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr>

June 2008

80

<DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="10"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="oldTmVal"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" test="false" Source="process" operatorBlock="false"> <DetailQual/> </quality> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp FracOfSec="10" TA="11" SecSE="10"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> </Data>  <Data DataName="TotWh"> <SimpleCDC DataName="manRs"> <DataAttr FC="CO"> <DAType DAName="ctlVal"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CO"> <DAType DAName="origin"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType>


June 2008

81

</DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality operatorBlock="true" Source="process" test="false" Validity="good"/> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" CNS="true" FracOfSec="10" LSK="true" SecSE="10" TA="10"/> </PrimComp> </DAType> <TrgOp qchg="true"/> </DataAttr> <DataAttr FC="CF"> <DAType DAName="CtrlModels"> <PrimComp> <codedEnum numBits="1">0</codedEnum> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="hisRs"> <DataAttr FC="CO"> <DAType DAName="ctlVal"> <PrimComp> <int128>0</int128> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CO"> <DAType DAName="origin"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality operatorBlock="true" Source="process" test="false" Validity="good"/> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST">


June 2008

82

<DAType DAName="t"> <PrimComp> <timeStamp CF="true" CNS="true" FracOfSec="10" LSK="true" SecSE="10" TA="10"/> </PrimComp> </DAType> <TrgOp qchg="true"/> </DataAttr> <DataAttr FC="CF"> <DAType DAName="CtrlModels"> <PrimComp> <codedEnum numBits="1">0</codedEnum> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="actCtVal"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality operatorBlock="true" Source="process" test="false" Validity="good"/> </PrimComp> </DAType> <TrgOp qchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" CNS="true" FracOfSec="10" LSK="true" SecSE="10" TA="10"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> <SimpleCDC DataName="oldCtVal"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int32>0</int32> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality operatorBlock="true" Source="process" test="false" Validity="good"/> </PrimComp> </DAType>

June 2008

83

<TrgOp qchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" CNS="true" FracOfSec="10" LSK="true" SecSE="10" TA="10"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> </Data>  <Data DataName="TurSt"> <SimpleCDC DataName="actST"> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" operatorBlock="false" Source="process" test="true"/> </PrimComp> </DAType> <TrgOp qchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" FracOfSec="10" LSK="false" CNS="false" SecSE="10" TA="10"/> </PrimComp> </DAType> </DataAttr> </SimpleCDC> </Data>  <Data DataName="W"> <DataAttr FC="MX"> <DAType DAName="mag"> <DAComp DAName="f"> <PrimComp> <float32>0.0</float32> </PrimComp> </DAComp> <DAComp DAName="i"> <PrimComp> <int32>0</int32> </PrimComp> </DAComp> </DAType> <TrgOp dchg="true"/> </DataAttr>

June 2008

84

<DataAttr FC="MX"> <DAType DAName="q"> <PrimComp> <quality Validity="good" operatorBlock="false" Source="process" test="true"/> </PrimComp> </DAType> </DataAttr> <DataAttr FC="MX"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" FracOfSec="10" LSK="false" CNS="false" SecSE="10" TA="10"/> </PrimComp> </DAType> </DataAttr> </Data>  <Data DataName="SetTurOp"> <SimpleCDC DataName="actSt"> <DataAttr FC="CO"> <DAType DAName="ctlVal"> <PrimComp> <int128>0</int128> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="CO"> <DAType DAName="origin"> <PrimComp> <visibleString>Blabla</visibleString> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="stVal"> <PrimComp> <int128>0</int128> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="ST"> <DAType DAName="q"> <PrimComp> <quality Validity="good" operatorBlock="false" Source="process" test="true"/> </PrimComp> </DAType> </DataAttr> <DataAttr FC="ST"> <DAType DAName="t"> <PrimComp> <timeStamp CF="true" FracOfSec="10" LSK="false" CNS="false" SecSE="10" TA="10"/> </PrimComp> </DAType> </DataAttr>


June 2008

85

<DataAttr FC="ST"> <DAType DAName="stSeld"> <PrimComp> <Boolean>false</Boolean> </PrimComp> </DAType> <TrgOp dchg="true"/> </DataAttr> <DataAttr FC="CF"> <DAType DAName="ctlModels"> <PrimComp> <codedEnum numBits="1">0</codedEnum> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CF"> <DAType DAName="sboTimeout"> <PrimComp> <int32u>1</int32u> </PrimComp> </DAType> </DataAttr> <DataAttr FC="CF"> <DAType DAName="sboClass"> <PrimComp> <visibleString>SboClass</visibleString> </PrimComp> </DAType> </DataAttr> </SimpleCDC> </Data> </LN> </LD> </tServer>


June 2008

86

7.5.4 Examples of SOAP service requests and responses In this appendix SOAP messages for the Associate request and Associate response are shown. Examples for other services are avalible on the appendix CD-rom.

7.5.4.1 Associate request <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> <AssociateRequest UUID="S_Svr6" xmlns="http://iec.ch/61400/ews/1.0/"> <UserName>Admin</UserName> <Password>minda</Password> <LocalID>DK</LocalID> <MaxMessageSize>25</MaxMessageSize> </AssociateRequest> </soap:Body> </soap:Envelope>

7.5.4.2 Associate response <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <AssociateResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" UUID="S_Svr6" xmlns="http://iec.ch/61400/ews/1.0/"> <MaxMessageSize>25</MaxMessageSize> <AssocID>486835106</AssocID> </AssociateResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>


June 2008

87

7.6 Reference list [1] Title A short introduction to Test-Driven development. Link http://en.wikipedia.org/wiki/Test-driven_development [2] Title New World Record in Wind Power Capacity Author World Wind Energy Association Link www.wwindea.org/home/images/stories/pdfs/pr_statistics2006_290107.pdf

[3] Title Prototype for a IEC 61400-25 Compliant Generic Server Author Andreas Kargård Olsen & Baris Özdil [4] Title Reporting and logging in compliance with IEC 61400-25 Author Umut Korkmaz [5] Title Web Services On Devices Full Source Author Richard Jones link http://www.binaryrefinery.com/main/default,month,2007-08.aspx [6] Title International Journal of Distributed Energy Resources


June 2008

88

7.7 Literature IEC 61400-25-1 Communications for monitoring and control of wind power plants - Overall description of principles and models. IEC 61400-25-2 Communications for monitoring and control of wind power plants - Information models. IEC 61400-25-3 Communications for monitoring and control of wind power plants - Information exchange models. IEC 61400-25-4 Communications for monitoring and control of wind power plants - Mapping to communication profile. IEC 61400-25-5 Communications for monitoring and control of wind power plants - Conformance testing.


June 2008

89

7.8 Software used Microsoft Visual Studio Team System 2008 – For development and imple-mentation of the system described in this thesis. Tcpmon - for observing HTTP network data flow between client and server XSD - for generation of C# classes by using XML schema definition files. XSD is a command line tool supplied with Microsoft SDK.

7.9 CD-Rom Contents

Root directory. Containing this thesis Source code Solution directory for IEC 6100-25 server Solution directory for IEC 61400-25-3 client framework XML Directory for misc. XML documents Examples of SOAP Service requests Examples of SOAP Service responses

Directory for misc. XML Schema files


June 2008

90

7.10 Glossary .NET CF .NET Compact Framework ACSI Abstract Communication Service Interface CDC Common Data Class DA Data Attribute DLL Dynamic Link Library GUI Graphical User Interface HTTP Hypertext Transfer Protocol HTTPD Hypertext Transfer Protocol Daemon ID Identifier IEC International Electrotechnical Commission IS Information Server (Also referred to as web server) LAN Local Area Network LD Logical Device LN Logical Node RTU Remote Terminal Unite SCADA Supervisory Control and Data Acquisition SMTP simple mail transfer protocol SOAP Simple Object Access Protocol TDD Test Driven Development UML Unified Modelling Language WAN Wide Area Network WPP Wind Power Plant WS Web Service WSDL Web Service Description Language XML Extensible Markup Language XSD Xml Schema Definition


June 2008

91

7.11 Brodersen RTU32 data sheet

Brodersen Controls A/S * Industrivej 3 * DK-4000 Roskilde * Denmark * Tel (+45) 4674 0000 * Fax (+45) 4675 7336

40200/02.07 1

Utility Outstation and ControllerRTU32

INTRODUCTION

The Brodersen RTU32 controller series based on a 32-bit platformprovides the RTU with power and leading edge functionality. Theplatform is based on a fanless industrial PC platform with WinCE 5.0.NET operating system. It provides an open and adjustable platformwith both the power and functionality required to control advancedindustrial applications.

The BC RTU32 is in general based on the flexible hardware layout anddesign, known from the existing RTU8 and RTU870 product series. Itis supplied in a robust aluminium enclosure and can be used with thewide range of Brodersen I/O expansion modules. It is in standardmodule kept in the modular size of 189mm.

Ethernet and TCP/IP are the basic communication and data environ-ments, however, serial communication interfaces are still an importantpart of the RTU32 for interfacing to various system parts.

The RTU32 is available with or without integrated I/O. Different softwarefunctionality is provided.

Features

• Powerful RTU and Industrial Controller.

• Open Platform with WinCE Operating System.

• Integrated Powerful EN/IEC61131 Control Software.

• Several Communication Protocols Supported Including the

full Modbus suite.

• EN/IEC60870-5-101/104 Protocol Support.

• Global Distribution and Subscription of Event Based TimeStamped Variables.

• Dual Ethernet and COM Interfaces.

• Robust Design for Industrial Applications.

• Optional drivers available, e.g. SMNP agent for network

monitoring, alarming etc.

UCN-26IOA/xxx

VERSIONS/ORDERING CODES

UCN-26IOA/1 2 1 B 01 30. DTypeUCN UCN

26I/O type and counts. versions:RTU32 basic without I/O B16 dig. in/4 relay out./4 analog in./2 analog out. 26IOA

CPU Motherboard type300MHz x 86 CPU 1

RAM/Flash size64MB RAM/64MB Flash 2

Optional drivers etc.Standard (Modbus+IEC870) 1Standard + SNMP 2

BrandingBrodersen B

COMs options2 x RS232 016 x RS232 025 x RS232 + 1 x RS485 031 x RS232 + 1 x RS485 04

Power supply option115-230VAC 10115-230VAC incl. 12V UPSBattery/charger 20*)24-48VDC incl. 12VDCext. supply 30

Input/output optionsNo IO type 0Analogue input/output range:Configurable D

*) Available from autumn 2006.

Special versionsSpecial versions can be delivered as option. Contact us for moreinformation.


2 40200/02.07


CONTENT

Introduction ........................................................................ 1Introduction text ....................................................... 1Module ..................................................................... 1

Version/Ordering code ....................................................... 1

Technical Description ........................................................ 3Input/Output ............................................................. 3Wiring Diagram UCN-B/xx ....................................... 3Wiring Diagram UCN-26I/O ...................................... 4General .................................................................... 5Configuration ........................................................... 5I/O's and Database .................................................. 5STRATON SoftPLC .................................................. 5I/O Drivers ............................................................... 5Fieldbus Configurator ............................................... 5EN/IEC60870-5-101/104 .......................................... 5Data Logging ........................................................... 5Modem Control ........................................................ 5Real-Time / Real-Time Clock ................................... 6

Technical Data .................................................................... 6Basic 32-bit system................................................. 6

CPU .................................................................. 6BIOS ................................................................. 6System chipset ................................................. 6I/O Chip ............................................................ 6System memory ............................................... 6SSD .................................................................. 6Watchdog timer ................................................. 6Expansion ......................................................... 6MIO ................................................................... 6USB .................................................................. 6Display chipset ................................................. 6Display memory ................................................ 6Resolution ......................................................... 6VCA/LCD interf. ................................................ 6Ethernet chipset ................................................ 6

Physcial Interfaces .................................................. 6Dual Ethernet .................................................... 6COMS ............................................................... 6USB .................................................................. 6VGA/LCD .......................................................... 6PS/2 .................................................................. 6I/O Expansion ................................................... 6

Industrial I/O ............................................................ 7Expansion I/O ................................................... 7Integrated I/O .................................................... 7

Integrated Digital I/O ............................................... 7Inputs ................................................................ 7Indicators .......................................................... 7

Integrated Relay Outputs ......................................... 7Relay Outputs ................................................... 7Lifetime (relay) .................................................. 7Contact material ................................................ 7Isolation ............................................................ 7Indicators .......................................................... 7

Integrated Analogue Input ........................................ 7Inputs ................................................................ 7Input Configuration ............................................ 7Input measuring ranges .................................... 7

Resolution ......................................................... 7Impedance ........................................................ 7Absolute maximum ratings ............................... 7Sampling interval .............................................. 7Measuring accuracy .......................................... 7Linearity ............................................................ 7Temperature stability ......................................... 7Common mode voltage ..................................... 7Common mode ratio .......................................... 7Series mode rejection ....................................... 7Isolation ............................................................ 7

Integrated Analogue Output ..................................... 7Outputs ............................................................. 7Output ranges ................................................... 7Resolution ......................................................... 7Absolute maximum ratings ............................... 7Sampling interval .............................................. 7Accuracy ........................................................... 7Linearity ............................................................ 7Temperature stability ......................................... 7Isolation ............................................................ 7

SoftwareOperating system ............................................. 7EN/IEC61131 SoftPLC ...................................... 7Standard drivers ................................................ 7Optional drivers ................................................. 7

Power Supply ........................................................... 8Power supply versions ...................................... 8Power consumption ........................................... 8Isolation ............................................................ 8

General .................................................................... 8Indicators .......................................................... 8Ambient temperture .......................................... 8EMC .................................................................. 8Protection ......................................................... 8Mounting ........................................................... 8Housing ............................................................. 8Dimensions ....................................................... 8

Code Switch/Address Selector .......................................... 8

Circuit Configuration (Digital) ............................................ 8Circuit Configuration (Analogue) ........................................ 8


40200/02.07 3


TECHNICAL DESCRIPTION

Input/outputThe RTU32 basic I/O fit can include up to 32 input/output terminals. I/O options available:

Version UCN- 26IO

Digital inputs 16 Can also be used as

(10-30V DC) S0 counter inputs (ZI)

Digital outputs 0

(PNP o. c.)

Analogue inputs 4

(Configurable)

Analogue outputs 2 Sources outputs

(Configurable)

Relay outputs (NO) 4

All digital I/O´s are equipped with opto-couplers. The analogue inputshave galvanic isolation between the individual channels. Solid staterelays are used for multiplexing the analogue inputs. No isolation onanalogue outputs.

Wiring diagramUCN-B/xx


4 40200/02.07


Wiring diagramUCN-26IOA/xx

C

VV

VV

A


40200/02.07 5


TECHNICAL DESCRIPTION

GeneralThe RTU32 offers 2 main functions:

• A powerful stand-alone RTU with I/Os to perform embeddeddata processing, data control, data logging and monitoring.

• A networking communicator for collecting, managing andcommunicating data via protocols on different physicalinterfaces upwards and downwards in industrial applications.

The RTU32 Outstation and Industrial Controller is based on an IndustrialPC platform running WinCE operating system with all the well knownembedded Microsoft environment facilities. A range of industrial powersupplies is integrated to support industrial supply levels and functionssuch as UPS. The basic IPC includes a range of communication andother interfaces. The RTU32 provides additional interfaces like LocalBusfor expansion I/O and integrated I/O via the internal PC104 interface.

The RTU32 software is stored on a removable Flash. During start-up, theoperating system and applications are moved to RAM where it isexecuted. System configuration settings are stored on the Flash.Retained variables are stored on flash when required.

WinCE is the RTU32 operating system. Integrated I/O and LocalBus forexternal I/O connectivity are controlled in an implemented I/O database.A STRATON SoftPLC VM (Virtual Machine) is ported to the WinCE real-time task. This enables the STRATON SoftPLC runtime applicationprogram to be executed in the RTU32.

Using the Ethernet network for primary communication provides all theadvantages of existing TCP/IP networking communication facilities(FTP, HTTP etc). Fast, reliable and secure communication are the mainfeatures and all networking components (software, routers, switches,etc.) are available. In addition, serial ports for interfacing to applicationspecific protocols (e.g. Modbus, Fieldbus, utility protocols, networkmanagement and traffic proprietary protocols etc.) are available.

ConfigurationRTU32 main settings, such as network settings, time settings and otherbasic configuration parameters, are configured via the RTU32 WebPages.In addition a number of configuration files in the WinCE file system areused for driver specific settings and are adjusted either from the editorprovided in the Webpages or remotely via the RTU32 configuration tool.

I/O’s and DatabaseInternal I/O and expansion I/O are managed in an independant database.The I/O database structure is designed as a multi-accessible database.The database runs in its own task providing fast and reliable I/Ocommunication. The STRATON SoftPLC has drivers to access thedatabase both at board level where the I/O is accessed in I/O sections,and in single level where each I/O can be accessed individuallyaccording to the specific application requirement.

In addition, an API for WinCE provides access to the database fromyour own C++ program. It can even be used as gateway access to aSTRATON application program.

STRATON SoftPLCThe STRATON programming tool fully supports EN/IEC61131 and isused for making SoftPLC programs in the RTU32. The applicationprogram kernel is implemented and runs in WinCE real-time task.STRATON offers complete SoftPLC functionality and supports allfeatures needed in today’s industrial environment. STRATON supportsprogramming languages such as Structured Text, Function Block,Ladder, Instruction List and Sequential Function Chart. The STRATONSoftPLC supports cold restart, hot restart and on-line changes.

The STRATON Workbench is used for configuration protocols, program-ming and debugging. It supports several tools for multi-program handlingand documentation. It is also a powerful tool for complete system designand programming, providing unique functions for event basedcommunication. The Global Binding Editor makes it possible to publishand subscribe variables in a large network with minimum communicationload. The events are time stamped and can also be used directly inZenOn SCADA HMI applications.Programming, debugging and upload and download of applicationprograms can be done remotely via Ethernet or RS232.

The basic drivers and protocols available for the RTU32 are:• I/O drivers for integrated I/O and I/O Expansion.• ModbusRTU Master and Slave.• ModbusTCP Client and Server.• EN/IEC60870-5-101 Master and Slave.• EN/IEC60870-5-104 Client and Server.• SNMP Agent driver (optional).

In addition, the RTU32 can run ZenOn CE-runtime application whichexpands the number of available protocols.

I/O DriversThe RTU32 I/O can be accessed in 2 ways, either as boards (I/O isreported in sections as they are connected physically) or as profiles(each I/O is directly addressed). I/O status is reported in a functionblock.

Fieldbus ConfiguratorWith the Fieldbus Configurator Tool in STRATON, the Modbus suite ofprotocols can be configured. It is also possible to publish or subscribeany variables in RTU32 networks or on other STRATON runtimeplatforms and ZenOn HMI platforms.

EN/IEC60870-5-101/104Utility protocols EN/IEC60870-5-10x provide full configuration flexibilityof almost any inter-operability requirements. The protocol links areprovided as a driver in STRATON and the application layer data andprotocol structures are generated in Structure Text (ST). This gives fullaccess to set up any Interrogation and ASDU required for the applica-tion.In addition, the protocol drivers support advanced features for gatewayfunctions where, for example, information in monitor direction can bemoved from one protocol interface to another without compromising theactual value and original time stamp. Also sharing data queue from moreports are possible.

Data LoggingA special data logging function block is available for logging event basedor cyclical data to the flash file system. The data logging also supportsfunctions for formatted log directly exportable to ZenOn HMI andSCADA software. Log files can be downloaded from the RTU32 via FTP.

Modem Control / Dial-up / Dial-inBoth dial-up and dial-in functions via a PSTN, ISDN or GSM modemconnected to the serial port of the RTU32 are possible when using theSTRATON modem function. It can be used for ModbusRTU and EN/IEC60870 serial protocols.


6 40200/02.07


Real-Time / Real-Time ClockThe WinCE real-time task is used for the application program execution.Time stamps and cyclic execution are also based on the WinCE real-time clock. Time stamps are reported in milliseconds. In order to achievehigh time accuracy the clock has synchronisation option with SNTP andspecial clock slave and master function for synchronisation from RTU32to RTU32.

COM communication for NullModem, radio and LeasedLine mo-demsThe RTU32 has implemented extended nessesary data communicationfeatures for communication of ModbusRTU, serial EN/IEC60870-5-101etc. over serial modems and converters. The features cover detailedhandshake control with timing of RTS and CTS.

Power supply optionsThe RTU32 can be delivered with some different built-in power supplies.Option for 24-48VDC and 115-230VAC is available. In addition the mainsversion can be delivered with an UPS for connecting a battery. If themain is disconnected the RTU32 will continue to run on the battery. Sominternal I/O for mains alarm is provided. When the main comes back, thebattery is charged and will be standby fully charged for fall backsituations next time the mains is interupted.The power supply also provide an 12VDC output for used for I/O control.

Other interfacesThe RTU32 include also 2 USB port for future use such as Flash discstorage, WiFi, fast serial communication etc.A VGA port for connecting a monitor and the mouse/keyboard connec-tion provide possibility for work with the RTU directly on the WinCE userinterface.

TECHNICAL DATA

BASIC 32-BIT CPU SYSTEM

CPU: AMD Geode™ GX1 300 MHz

BIOS: AWARD 256KB Flash BIOS

System chipset: Geode™ GX1/CS5530A

I/O chip: W83977F-A

System memory: One 144-pin SODIMM socket supports up to256 MB SDRAM.

SSD: CompactFlash Type I/II socket support up to512MB

Watchdog timer: Reste/IRQx; 16 sec.~127 min. and 30 sec./step.

Expansion: Internal PC104 interface.

MIO: 2 x EIDE (Ultra DMA 33), 2 x FDD, 1 x LPT,1 x RS-232, 1 x RS-232/422/485, 1 x K/B &Mouse.

USB: 2 x USB 1.0 ports

Display chipset: AMD GeodeTM GX1 with integrated 2Dgraphics engine.

Display memory: 1/2/4 MB frame buffer using system memory.

Resolution:CRT mode: 1280x1024@8bbp (60Hz)LCD/Simultaneousmode: 1024x768@16bbp (60Hz)

VGA/LCD Interf.: PCI bus VGA/LCD interface. Support 9/12/18-bit TFT panels.

Ethernet chipset: Dual Realtek RTL8139C

PHYSICAL INTERFACES

Dual Ethernet: 2 x RJ45 Ethernet interfaces, IEEE 802.3c100Base-Tx Fast Ethernet compatible.

COMS: 1 x RS232 and 1 x RS232/RS485.

USB: 2 x USB 1.0 ports.

VGA/LCD: PCI bus VGA/LCD interface

PS/2: Single interface for keyboard and PS/2mouse. Twin interface cable included.

I/O Expansion: RJ45 LocalBus interface for Brodersen I/OExpansion modules. See industial I/O sec-tion.


40200/02.07 7


INDUSTRIAL I/O

Expansion I/O: Expansion I/O is possible via the BrodersenI/O LocalBus system to all Brodersen I/OExpansion modules.Supports up to 32 I/O Expansion modules ofany type.

Integrated I/O: 26IO board integrated supports;16 Digital inputs4 Relay outputs4 Analogue inputs2 Analogue outputs.Scantime better than 5ms for digital I/O forsmaller applications.

INTEGRATED DIGITAL I/O

Inputs:Input voltageactivated: 10-30V DC.Input voltagedeactivated: Max. 3V DC.Input current: 12V DC: Typical 3mA.

24V DC: Typical 6mA.Input delay: Typical 1ms.

Isolation: 1kV AC

Indicators: One LED for each digital input (red) indicatingactive input.

INTEGRATED RELAY OUTPUTS

Relay outputs: 4 potential free SPST-N/O contacts.Output voltage: Max. 240V AC.Output current: Max. 1A AC (resistive).Output delay: Typical 5ms.

Lifetime (relay): Min. 100.000 operations at rated load.

Contact material: Gold overlay silver alloy.

Isolation(coils-contacts): 2kV AC 50Hz 1 min (IEC255-5).

4kV 1,2/50micro s. / impulse withstand(IEC255-5).

Indicators: One LED for each output (yellow) indicatingactive output.

INTEGRATED ANALOGUE INPUT

Inputs: 4 multiplexed analogue channels withsolid state multiplexer.

Input configuration: Differential (+/ -), flying capacitor type.

Input measuringranges: 0 - 10V

0 - 5V-5 - +5V-10 - +10V0-2V/0 - 20mA0,4-2V/4 - 20mASelection between these ranges can be donein STRATON.

Resolution: 14 bit, 0-16383.

Impedance: Voltage: 1M Ohm.Current: 100 Ohm ±0,25%.

Absolute maximum ratings:Input voltage: ±15V DC.Input current: ±30mA DC.

Update time: Better than 250 ms.

Measuring accuracy: 25°C: ±0.1% (typically 0.05%).-10°-55°C: ±0.3%(typically 0.1%).

Linearity: Better than ± 0,05%.

Temperaturestability: Better than ± 50ppm/°C (typical).

Common modevoltage: Max. ±80V DC.

Common moderejection ratio: Min. 72dB.

Series moderejection: Min. 36dB (50-120Hz)

Isolation:(input to input): 500V.

INTEGRATED ANALOGUE OUTPUT

Outputs: 2 sourced analogue channels.

Output ranges: 0 - 10V0 - 5V-5 - +5V-10 - +10V0 - 20mA4 - 20mASelection between these ranges can be donein STRATON.

Resolution: 14 bit, 0-16383.

Absolute maximumratings: Iout: Output voltage: 27V DC.

Load: 1kOhmOutput current: 25mA DC.

Vout: Output voltage: ±15VLoad: 1kOhm

Update time: Better than 100 ms.

Accuracy Iout: 25°C @ 100Ohm: ±0,1%-10°-60C° @ 100Ohm: ±0,2%


Leakage current: Max. 10 µA (typically 3µA)

Temperaturestability: Better than ± 50ppm/°C, @ 100Ohm.

Accuracy Vout: 25°C: ±0.1%-10°-60°C: ±0.2%


8 40200/02.07


CODE SWITCH/ADDRESS SELECTOR

Application I/O

Reserved for STRATONrun modes:- SoftLogic stopped- Run / cold restart- Run / hot restart

The DIL switches can be read from the STRATON application programand can be used for simple end user configuration.

Note: The STRATON runtime modes are not yet implemented. Cancurrently only be managed from the STRATON workbench and theRTU32 .INI config file.

CIRCUIT CONFIGURATION (DIGITAL)

Input

Output (PNP)


Isolation: (input to input): No isolation.

SOFTWARE

Operating system: WinCE 5.0 .NET.Open platform with possibility for developingand running customer application.

EN/IEC61131SoftPLC: STRATON SoftPLC VM Embedded.

Standard drivers: STRATON binding, ModbusRTU,ModbusTCP, EN/IEC60870-5-101/104.

Optional drivers: SNMP Agent driverVia ZenOn several additional drivers.

POWER SUPPLY

Supply Voltageversions: 24-48VDC (20-60VDC).

115-230VAC (90-265VAC).115-230VAC (90-265VAC) with UPS andbattery charger 12VDC.

Power consumption: Max. 40W - Configuration dependent.

Isolation: Power supply to electronics: 3750V

GENERAL

Indicators (LEDS):Power (green): Indicating power ON.System (green): Indicate system status.Run (green): Indicate SoftPLC program status.I/O (green): Indicate status of integrated and

expansion I/O.Com x (yellow): Indicate Rx/Tx activity on the specific

com port.

Ambient temperature: -10 - +60°C.

EMC/LVD: EN55022:1998 Class AEN61000-3-2:2000EN61000-3-3:1995EN55022:1998 Class AEN55024:1998 (EN61000-4-2:1995,EN61000-4-3:1996,EN61000-4-4:1995,EN61000-4-5:1995, EN61000-4-6:1996,EN61000-4-8:1993, EN61000-4-11:1994 )EN 61000-6-2: EMC/ Immunity Industry.EN 61010-1: Safety requirements for electricalequipment for measurement and control.EN 60950:Safety of information technologyequipment.

Protection: IP20.

Mounting: 35 mm DIN-rail, EN50022.

Housing: Black aluminium housing.

Dimensions:HxWxD: 94(+connectors)x189x101 mm.

1 2 3 4 5 6 7 8 9 1 0

ON ON

OFF


40200/02.07 9


CIRCUIT CONFIGURATION (ANALOGUE)

Analogue Input

Analogue Output

I Out

V Out

+

-

24V

27V

IA & IB

0-1K

+

-27V

VA & VB

V

GND

+

-

+

C

+

I

0V

C

12V

I

12V

100E

100E

Deployment of IEC61400-25-4etd.dtu.dk/thesis/221247/ep08_53.pdf · Master of Science Deployment of...

Documents

Transcript of Deployment of IEC61400-25-4etd.dtu.dk/thesis/221247/ep08_53.pdf · Master of Science Deployment of...