Pow-R-Command TM (PRC TM ) SOAP Server

Transcription

1 July 2003 Pow-R-Command TM (PRC TM ) SOAP Server Technical Data Table Of Contents System General 2 Applications For Systems 2 Network Philosophy 2 The Power Of Connectivity 2 What Is Needed For Connectivity & Integration 2 Current State Of Integration & Connectivity 3 Device Level Communication 3 System Level Communication 3 Problems With Current Integration Method 3 Future Of Integration 3 Benefits Of Web Based Connectivity 4 Brief History Of The Development Of Web Based Connectivity 4 Web Communication Basics 5 Development of extensible Markup Language (XML) 6 Development Of Simple Object Access Protocol (SOAP) 7 Basics Of SOAP Communication 7 Understanding SOAP Envelopes 7 Benefits Of Using SOAP 8 Communicating With A System Through SOAP 8 SOAP Server In A Network 9 Network Connection To the SOAP Server 9 Network Specification 9 Connecting To A SOAP Server 10 SOAP Client Abilities When Using A SOAP Server 10 SOAP Server & WSDL 10 Applications For A SOAP Server Start-Up When Using A SOAP Server 13 Notable Standards Being Built Around SOAP & XML 13 Technical Resource Library 14 TD E For More Information Visit

2 Page 2 Effective: July 2003 General System The system is a complete network of devices, which allow a facility s electrical use to be efficiently managed. With the, individual loads can be switched through a network of individual panels, which are influenced by Building Automation Systems, wall switches, time schedules, software, or through telephone commands, etc. See Technical Document TD E for more information on the Pow-R-Command 100 system. HVAC System Fire/Emergency System Security/Access Control System Other Mechanical Control System Building Automation Systems (Modbus/ Ethernet) User User User User Common Communication Platform Applications For Pow-R-Command 100 Systems Lighting Control System (RS-485) Business Systems (Ethernet) The system is primarily designed for larger facilities where multiple nodes need to be networked together and controlled through software. However, Pow-R-command 100 can also be scaled down to the needs of some smaller facilities while offering the same functions as a large networked system. The Pow-R- Command 100 system provides an easy manner to efficiently control electrical loads while maintaining a compact design. In addition, the system can be seamlessly integrated into Building Automation Systems, Security Systems, and Fire/Emergency Systems. Network Philosophy The System is designed to provide the user with the greatest flexibility for interfacing. In most circumstances, the Pow-R-Command system uses an RS-485 protocol and communication standard to send and receive commands between control devices. This RS-485 network is accessed through either RS-232 or Ethernet. For more information on RS-485 to RS-232 & Ethernet please see Technical Document TD E. Beyond these capabilities, the Pow-R- Command 100 system is capable communication using BACnet, Modbus, Johnson Controls N2, OPC, & SOAP. The Power Of Connectivity To any personnel, accurate and timely data is one of the key elements to preforming their activities. This holds true from facility managers to sales personnel to engineering Networked Lighting Panelboards Figure 1: Connection of BAS and Lighting Control System At System Level personnel. To provide accurate and timely data, it is essential that all sources that produce data connect to a common communication platform, which can be accessed through a familiar interface. Such sources include lighting control systems, building automation systems, order processing systems, sales systems, and shipping systems. All of these sources must come together on one communications platform where users can access the data they need, when they need it, and a manner that they can use it. This is a simple concept to envision, but a very hard one to enact. The biggest obstacle to realizing this type of connectivity is finding a common method for formatting, transmitting, and displaying data from all systems. What Is Needed For Connectivity & Integration No matter the system, the fundamental element is data. Data transfers across devices through networks and enables users and devices to know status of elements and actions to take. To be useful data must be in a form that is understood by Sales Reporting Accounting Systems Management Information System Manufacturing Information System the devices and personnel. In order for this to occur, standards have to be produced to dictate the form of data and how it is transferred. Commonly, these standards are called protocols or language. When a specific protocol is used, devices that use the protocol are designed specifically with the ability to understand and communicate in the protocol. Current examples of this include Modbus, Lonworks, and BACnet. Each of these examples is a protocol that is based on standards, and has devices existing that can communicate based on the standard. Being able to speak one protocol is not enough. There also must be a standard for transmission of data. Current industry examples of this standard include RS-485, RS-232, and Ethernet. The last portion of connectivity is the ability for personnel to retrieve, view, and send data. This requires an interface that not only communicates using the proper protocols, but also can display the data in a way that a user can understand and interact with it.

3 Page 3 Effective: July 2003 Current State Of Integration & Connectivity Obviously connectivity is not a new idea, nor is it a new ability. In every industry there are dozens of protocols, with as many standards for sending data. Currently, there are two primary manners to connect and integrate these various system protocols. These two methods are connection at the device level, and integration at the system level. HVAC System Fire/Emergency System Security/Access Control System Other Mechanical Control System Building Automation System Device Level Communication When a system is purchased, there are any number of nodes that hang off of the system. Each node completes its specific task, and is purchased based on its ability to do so. Though the devices perform different functions, there is one common element between all of them. This common element is that they all use the same protocols for communication and transmission of data. In order for new devices to be added to this system, no matter the manufacturer, they must be able to communicate using the same protocols and standards. Each device, no matter the manufacturer, speaks to the others at the device level using a constant protocol and a constant transmission method. System users can send and receive data to/from the system based on their need from a central control point. System Level Communication In some circumstances, it is not possible to have all devices communicating using the same protocol and transmission standards. Reasons for this include a lack of function in devices, or devices that communicate the same protocol, and have the necessary functionality, are not financially justifiable. In instances such as this, the alternative is to communicate at the system level. When two systems are integrated together, there is commonly a software bridge that transfers/ translates messages across systems. Each system acts independently, and requires all of the programming and start-up expenses normally incurred. When this is done the bridge commonly needs to be separately developed and field tested for use. When all components are in place, there will be any number of systems acting and operating independently with all of their necessary parts. At the center of these systems will be common communication platform where each system passes data through. To add new devices to the existing systems is fairly simple, however, they will not necessarily Lighting Control System Networked Lighting Panelboards Figure 1: Connection of BAS and Lighting Control System At System Level be able to speak with other systems without reprogramming the central communication platform. The same holds true for adding new systems. The underlying matter in integration of systems is that the central communication platform, where all systems come together, is not necessarily flexible, nor accommodating when new devices or systems need to be added. Problems With Current Integration Methods Workstation With BAS, Lighting Control System,& Integration Software Installed Among the problems with current integration methods is one underlying inability. This is the ability to simply add on systems and devices, regardless of manufacturer, and affect this change without the need for expensive reprogramming. More so, the addition of devices and systems needs to be transparent to the users, and must work with the interfaces that they are familiar with. This is a very daunting task that current integration methods are not necessarily capable of...yet. Future Of Integration Over the last decade, nothing has shaped the manner that people interact with data more then the Internet and the World Wide Web (a.k.a the Web). Not only has the Web come to be a place for posting data and ideas, but the technology that drives the Web has begun to make its way into other applications. For Microsoft users, this integration can be seen through enhanced Web abilities in application, which are also developing a similar look and feel to Web Pages. The influence of the Web technology and the exchange of data will continue to extend to facility system control.

4 Page 4 Effective: July 2003 Benefit Of Web Based Connectivity Much can be said for the importance of the Web and the technology that drives it. When looking at the common problems of integrating building control systems there are four benefits that are apparent from using Web based technology. These benefits are as follows: Industry Expertise: Because of the business potential of the Web, there have been a great deal of personnel trained in the technologies that drive the Web. This includes experience in integration, and how personnel use data. Standardization: Though there are a significant number of different ways to implement Web based technology, there are still standards for use. Like protocols that transfer data between devices, there are standard protocols used to transfer data across the Web. Governing bodies for Web technologies include the International Standards Organization (ISO) and the World Wide Web Consortium (W3C). These bodies standardize use and syntax of protocols used for the Web. These standards include both transmission of data, format of data, and display of data. To help these bodies meet industry needs, direction is given to them from industry sources. Familiar Interface: The Web and all of its data source are accessed through one primary interface. This interface is a Web Browser. Two of the most popular Web Browsers include Microsoft s Internet Explorer and Netscape Navigator. Because of the popularity of the Web, there are few data users who are not familiar with Web Browsers. While the interface may change slightly through time, critical elements stay the same. This allows users to become comfortable with using the Web, and with accessing new systems through a browser interface. Multiple Industry Adoption: Web technology is making its way into all industries. From personal computing, network architecture, engineering, sales, and control, the technologies that drive the Web are spreading. Because of this, a greater amount of interpretability of applications can be realized. This potentially means that a building control system can send and receive data to and from a Microsoft application, which sends and receives data to and from business order entry systems with comparatively little integration programming. More so, this means that any applications and systems can be added to the communication bus with little effort. Combined with the previously listed benefits, the use of Web technology becomes a very powerful tool. Brief History of The Development Of Web Based Connectivity The concept of making a similar communication platform for application to communicate on is not a new concept. Among the first steps toward this was with Microsoft s Object Linking and Embedding (OLE) technology. OLE allowed monolithic applications (e.g. Microsoft Word, Excel, Access, etc.) to link data from one to the other and update that data without user intervention. This linking was accomplished by defining a set of rules (protocols) and building part of the applications to those rules. In addition, OLE was adopted by other software vendors, allowing their products to link data into Microsoft s products and visa versa. Building upon OLE, was another Microsoft technology titled Component Object Model or COM. Like OLE, COM had a standard set of rules for the form data took when it was transmitted. However, unlike OLE which allowed large monolithic application to speak to each other, COM was created to work with a Client Server architecture. For a more detailed description of Client Server communication please see Technical Document TD E. In this environment the Client would request the Server to take an action, the Server would return with an answer for the client. One restriction of the COM model was the Client and Server both needed to reside on the same physical machine. To overcome the need for the client and server to reside on one machine, Microsoft refined their COM model and created Distributed Component Object Model or DCOM. DCOM follows the same principles as COM, but allows for the client(s) and server to reside on different physical machines. At this same point in time there were other protocols, such as Common Object Request Broker Architecture (CORBA), that effectively did the same thing as DCOM. When applications are built with the ability to communicate in these types of protocols, communication between them is clean and effective. However, one problem persists with these protocols. DCOM, and those like it, are close coupled protocols. This means that a DCOM client can speak to DCOM server but not to a CORBA Server. When a DCOM client tries to send a request to process a command to a CORBA server, the command is not understood. In addition to the disadvantages associated with close-coupled protocols, DCOM, and those like it, are not suited to all communication needs. This is especially true when communicating across the Web and through firewalls. DCOM is a binary based language, which is commonly not allowed to pass through firewalls unless they are configured to allow it. As a result, data sent from a DCOM client to a DCOM server on an opposing side of a firewall is not assured of reaching its destination. In order for the data to pass through a firewall, the administrator needs to open additional ports, which can cause a potential security risk to the network. To help solve some of the problems with close-coupling and communication, we look to Web based technology.

5 Page 5 Effective: July 2003 Web Communication From Client To Server Server Terminal Client Terminal Data Communication Using ISO-OSI Model Layer 7 Application: The Application Layer defines the end transmission protocol the actual application (e.g. Web Browser) uses. Examples of this include HTTP, SMTP, or FTP. Layer 6 Presentation: The Presentation Layer is used for encryption/ decryption of data into a format that can be used by lower levels in the stack Layer 5 Session: The Session Layer defines the format of the data sent over the connections. This is typically used to make Remote Procedure Calls (RPC s), which can come in the form of TCP or even SOAP. Layer 4 Transport: The Transport Layer provides for reliable, accurate, and guaranteed transmission & reception of data. Typically this layer involves the use of TCP. Layer 3 Network: The Network Layer controls the forwarding of messages between point such as routers. Typically this layer involves the use of IP. Layer 2 Data Link: The Data Link Layer describes the physical hardburned addresses of devices and network topology. Layer 1 Physical: The Physical Layer describes the cable or physical medium used for transmission as well as the voltage levels and timing of signal. In most cases the cable is CAT5 and the signal standard is Ethernet. Layer 7 Layer 7 Layer 6 Layer 6 Layer 5 Layer 5 Layer 4 Layer 4 Layer 3 Layer 3 Layer 2 Layer 2 Layer 1 Layer 1 Physical Medium (E.G. CAT5 Cable) Figure 2: Graphic Illustration of ISO-OSI Model For Data Communication. Figure Is For Illustration Purposes Only. Web Communication Basics There is no one technology that drives data communication on the Web. In fact, ISO defines seven layered model, known as the Open System Interconnect (OSI), of protocols and applications necessary for open data exchange (a.k.a ISO-OSI Stack). Briefly speaking the bottom layer represents the physical wire and transmission standard used. Through the middle are protocols used for addressing, confirmation that data transmission/reception, error checking, and data format. At the top of the model are the are protocols that allow a users application to understand data being sent. Many of these protocols have very familiar names. Such include Ethernet, Transmission Control Protocol/Internet Protocol (TCP/IP), and Hyper Text Transfer Protocol (HTTP). Each of these protocols play some part in the transmission of data from one machine to another. A very generic example of a protocol stack can be seen in Figure 2. As each protocol and application rises up the stack it defines the data further, and adds to the total functionality of the transmission. Looking at Figure 2 it may help to think as these protocols in terms of a large box full of wrapped products. At the very center of the box is a product or the content being sent and viewed, which would represent the data. Around the product is a protective layer that helps the product remain intact and undamaged during shipment. The box, representing HTTP, itself holds the product and its protective wrapping. On the box is an address label, which informs handlers where to ship it to and the best method to get it there much like IP addresses and routers. In addition to the address is a tracking code (TCP) that is used to make sure the package arrives to its destination or can be used to report a delivery problem. The planes and trucks that carry the package are representative of standards such as Ethernet and physical transmission media such as CAT5 cable. This example of Web communications is in now way an exhaustive discussion of the subject. It is only meant to help briefly familiarize readers with protocols mentioned later in this document, and to provide an abstract of technologies involved in Web communication. More information on Web technology can be found in multiple places including print and on the Web.

6 Page 6 Effective: July 2003 Development Of extensible Markup Language (XML) XML Address Book Address Book Among the protocols at the top of the ISO-OSI stack is a relative newcomer. This protocol is titled extensible Markup Language or XML. In its most nontechnical description, XML is simply a way of describing commonly used data. Like other Internet protocols such as HTML, XML uses a set of tags to describe a data element. Simply put, a tag is just a name given to data that allows it to be simply and constantly identified. The purpose of creating these tags is to commonly describe all data that is the same. In addition, because many data elements are related to on another, XML supports the use of hierarchical tags. Unlike tags in HTML, which is very structured, XML tags can be anything the user wants them to be. To conceptualize use of XML think of a typical address book. Inside of this address book are all forms of common attributes, and each attribute has data behind it. For example, in most address books entries are defined by the persons name. Under the persons name is their address, phone number, and . Behind each of these common attributes is the appropriate data. In XML these attributes and data would be described in the exact same way. See Figure 3 for an illustration of this example. Translating this example into XML, a tag would be created for Name. Under Name would be other tags including Address, Phone Number, and . For the purpose of this document, the exact XML code for the example is not given. <Name>Cutler-Hammer </Name> <Address>1000 Cherrington Parkway </Address> <CityState> Pittsburgh PA </CityState> <ZipCode>15108 </ZipCode> <Phone> </Phone> < > Cutler-Hammer@Eaton.com </ > <Name>Pow-R-Command Support </Name> <Address>11 Corporte Circle </Address> <CityState> Sumter SC </CityState> <ZipCode>29154 </ZipCode> <Phone> </Phone> < > PowRCommand@Eaton.com </ > <Name>Integrated Facility Systems</Name> <Address>11 Corporate Circle</Address> <CityState> Sumter SC </CityState> <ZipCode>29154 </ZipCode> <Phone> </Phone> < > IFS@Eaton.com </ > Name Name Name Address 1000 Cherrington Parkway Phone # Address Cutler-Hammer City, State Zip Code Pittsburgh, PA Cutler-Hammer@Eaton.com 11 Corporate Circle Phone # Address Pow-R-Command Support City, State Zip Code Sumter, SC PowRCommand@Eaton.com 11 Corporate Circle Phone # Integrated Facility Systems TM Support City, State Zip Code Figure 3: Example Of XML Tags For An Address Book. Figure Is For Illustration Purposes Only. Sumter, SC IFS@Eaton.com Because of its flexibility and simplicity, XML becomes a very useful protocol for describing data. In addition to its simplicity, XML carries other benefits, especially when considering its use in integration. Among these benefits are: Loosely Coupled: There are few restrictions for describing or using data formatted in XML syntax. This means that once data is described, any application that recognizes the description can understand the data. Because of its loose coupling, a system based on data description using XML can be easily added to. Unlike DCOM or CORBA, XML is not owned by any one company. This means problems created with closecoupled proprietary protocols are more or less resolved. Text Based: When looking at the code for a Web page, everything is text based. XML follows this standard. The benefit text based protocols incudes being able to use Hyper Text Transfer Protocol (HTTP) to move data, and the ability to easily go through firewalls. The use of HTTP is described further later in this document. Strong Market Acceptance and Use: Though XML is a relatively new protocol, its benefits have been adopted and put into use throughout many industries. There is a great deal of expertise in using XML, as well as many tools that help personnel use XML. In addition, further protocols have been established based on XML.

7 Page 7 Effective: July 2003 Development Of Simple Object Access Protocol (SOAP) Among the standards built on XML is Simple Object Access Protocol or SOAP. Despite any similarities in its name, SOAP has nothing to do with cleaning. SOAP is actually a way to put structure on how data is presented to different applications. Because SOAP is built on existing Web technology, it can by used with the Web and other applications that understand it. Basics Of SOAP Communication SOAP is not a replacement for XML Rather it is a new protocol built on XML standards. Figure 4 illustrates the structure of a SOAP message, and is described in the following. For the purpose of this document, the syntax of the SOAP message is not given in detail. Each SOAP message is described as an envelope. Each envelope contains a destination, a method of travel, and a data payload. Because SOAP is a text based protocol, SOAP travels across HTTP, and its destination is defined by a URI. HTTP is basically a protocol used to transfer text across the Web. URI s are used as an addresses. The use of HTTP and URI s are seen every time a Web Page is accessed. When you want to visit a Web Page you type in the URI in the address field of the Web Browsers. Typically at the head of the address there is a statement such as followed by the URI such as The HTTP declaration tells the Web Browser how to move data. The gives the address to retrieve data from. Coding built into the Web Browser tells it how to display the data received. Inside of the SOAP envelope are XML declarations (tags) that describe the data being sent. Inside of the declarations is the actual data being sent. These declarations can include anything so long as all parties in the conversation understand what is being said and how it is being said. SOAP Server SOAP Document Transmission Through: HTTP Send To Address: Understanding SOAP Envelopes ISO-OSI Model Involving Stacked Protocols for Communication See Page 5 Layer 7 (HTTP) Layer 6... Message: <Name> Cutler-Hammer </Name> <Address> 1000 Cherrington Parkway </Address> <CityState> Pittsburgh PA </CityState> <ZipCode> </ZipCode> <Phone> </Phone> < > Cutler-Hammer@Eaton.com < > As stated, the data in a SOAP envelope can be described in almost any way wanted. This is part of the nature and flexibility of XML. However, just because data can be described in any way, it does not mean that it can be understood. Computing has not developed to the level that all applications can be made to dynamically assume the intended meaning of data sent to it. Because of this there needs to a standard for what can be said and how it is said at each point on the communication path that data needs to be understood. This is a concept that is used in current industry protocols such as BACnet, Modbus, and Lonworks. In each of these protocols there are defined commands and data descriptions used to send and process commands and status. Taking this concept to the use of SOAP Client SOAP Document SOAP Envelope Figure 4: Illustration Of Communication Of SOAP Messages & Envelopes. Figure Is For Illustration Purposes Only. SOAP and Web technology is yet another language known as Web Service Directory Language or WSDL. Like SOAP, WSDL is a text based language that is created using XML syntax and standards. From an abstract perspective, WSDL is similar to an entry point for SOAP messages. This point outlines what actions can be taken as well as how data is to be described in order for an action to be processed. For the purpose of this document, the syntax of WSDL is not described. The most important point to know about WSDL is it provides the rules for the what can be understood and done in each application when sending data formatted in SOAP.

8 Page 8 Effective: July 2003 Benefits Of Using SOAP The process of integrating systems using SOAP can be somewhat complex. All applications that are intended for integration must have the ability to send and receive SOAP formatted data. In addition, each application must have a common method (WSDL) for describing the actions it can take. Despite this, there are still a great number of benefits for using SOAP when integrating system. Among these benefits are: Loosely-Coupled: As mentioned, any application that can understand SOAP messages can process, display, and act on data sent to it. Expanding an existing system to have this ability is not overly complex. This is in contrast to protocols such as DCOM or CORBA, as these systems are manufactured to work only with like types. Power Connection (+15V dc). Power Cord Provided On/Off Switch RS-485 Network Connection Network Activity LED Designed For Distributed Intelligence: A benefit derived from loose coupling is the ability to distribute and add onto the processing power of a system. Once the rules for communication are created, any device or system that follows those rules can be simply added. When a device or system is added, it does not loose any of its abilities, it simply adds more abilities to the entire larger system. Built On Existing Technologies: As mentioned SOAP is built on existing protocols such as XML. Because of this the strengths of other applications can be leveraged and used to better control systems and devices. Such applications include Web Browsers, which have become a very familiar way for users to interact with the data. Power LED Local RS-485 Test Port Text-Based Protocol: Being a text based protocol affords one great benefit. This is the ability to use HTTP to move the envelops of data. HTTP is the standard protocol used to move data across the Web. As a result firewalls are commonly open to data being sent through HTTP. This yields the ability to send data from systems physically scattered through the world to one common communication platform, and viewed on thousands of terminals. Flexible Transmission Methods: In addition to use of HTTP, SOAP envelopes can also be transported through Simple Mail Transfer Protocol (SMTP), which is used for most traffic, and File Transfer Protocol (FTP), which is commonly used to exchange files. This allows a great deal of flexibility for sending SOAP envelopes. Female RJ45 Port For Connection to Ethernet Figure 5: SOAP Server Ethernet Connection Status LED s Communicating With A Pow-R- Command 100 System Through SOAP To give facilities the ability to integrate lighting control with other systems through SOAP, Eaton s Cutler-Hammer has developed a SOAP server for use with the Pow- R-Command 100 system. The SOAP server is an optional hardware component. The purpose of the SOAP server is to allow SOAP clients to send requests for data or action to a system.

9 Page 9 Effective: July 2003 SOAP Server In A System The SOAP server is an addressed hardware device that hangs off of the main RS-485 Pow-R-Command 100 network. When using the Pow-R- Command 100 SOAP server, all other Pow- R-Command 100 products including hardware and software are available. All programming to the control nodes are completed through the Lighting Optimization Software. Software connection to the Pow- R-Command 100 network is still made through a Network Access Device. In the Pow-R-Command 100 network, each device carries an address. Typically, the Network Interface Device will have an address of 0. All control nodes on the network will have an address ranging from 1 to 120. The Pow-R- Command 100 SOAP server address defaults to a reserved address, which is typically 123. However, at the point of start-up the SOAP server may be given a new network address. Figure shows a typical network with a Pow- R-Command 100 SOAP server. RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device RS-485 Over Twisted Shielded Pair Ethernet Over CAT5 Max Distance 300-Feet From Hub/Router SOAP Client Ethernet SOAP Server Network Access Device (Ethernet Server Shown In Figure) Ethernet Over CAT5 Cable Max Distance 300-Feet From Hub/Router Workstation With Lighting Optimization Software Figure 6: Typical Network With SOAP Server Figure Is For Illustration Purposes Only Network Connection To The Pow-R- Command 100 SOAP Server No matter the type of controller used, network communication is carried out over a twisted shielded pair cable and using an RS-485 standard. The purpose of the SOAP server is to convert SOAP messages transmitted acrose HTTP/Ethernet to an RS-485 protocol. To do this, the SOAP server is externally equipped with the proper termination for both a twisted shielded pair network, and a female RJ45 jack. Figure 7 illustrates network termination to the SOAP server. To Network PWR +15V dc ON OFF To Ethernet Unitary LAN S - + Service Port Ethernet Over CAT5 Cable With RJ45 Connectors. Max Distance From Hub/ Router 300-Feet. ETHERNET DCD ACT LNK Network Specification The network uses RS-485 over a twisted shielded pair cable for communication. Maximum network length is 4,000-Feet from Network Access Device without use of repeater. Twisted Shielded Pair Cable can be: BELDEN 3105A, 300V (Preferred) BELDEN 82841, 300V, Plenum (Preferred) BELDEN 3074F, 600V Network RS-485 Over Twisted Shielded Pair. Maximum Network Distance 4,000-Feet From Network Access Device. Figure 7: Network Connection To A SOAP Server

10 Page 10 Effective: July 2003 Connecting To A SOAP Server As a server, the SOAP server is designed to receive and process requests from SOAP clients. Based upon the request, the SOAP server will also return an answer to the SOAP Client. In order for the SOAP client to send a request/command, it must first be able to find the correct location of the Pow-R-Command 100 SOAP server. As with any Web device, a SOAP server s location is designated by an IP address. This IP address provides the SOAP client the necessary information to constantly find the SOAP server. In all situations, the SOAP server IP address is assigned by the facilities IT or MIS group. The only condition that the IP address must meet is that it can only be a static IP address. This means that no other devices can use the IP address assigned to the SOAP server. SOAP Client Abilities When Using A SOAP Server The primary use for the Pow-R-Command 100 SOAP Server is to provide SOAP clients the ability to send/receive simple commands and status to/from the Pow-R-Command network. Generally speaking a SOAP client can be any number of applications including Building Automation systems, Web Browsers, and office tools such as Microsoft Excel. The only condition that a SOAP client must meet is that it in fact has been programmed to send/receive SOAP messages over HTTP/Ethernet. As of the date of this document, the Pow-R- Command SOAP server is equipped to handle 1,000 concurrent SOAP requests at one point in time. Each of the requests are held by the SOAP server until the request has been processed & answered, or for 30 seconds, which ever is sooner. Once either of these conditions is met, the request is automatically erased from the SOAP server. Currently, a SOAP client can request the following from the SOAP server: Send Request For Status Of Switching Devices, Inputs/Input Level, Output/Output Level, Counts, & Alarms. Change Set Points Of Analog Inputs Override Switching Devices, Inputs, Schedules, Groups, & Outputs to On or Off status. RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device RS-485 Over Twisted Shielded Pair Ethernet Over CAT5 Max Distance 300-Feet From Hub/Router SOAP Client IP Address: Ethernet It must be noted that a SOAP client is not capable of: Assigning or Reprogramming Groups Stored On PRC100 Controllers Creating Time Schedules Stored On PRC100 Controllers Creating Holidays Stored On PRC 100 Controllers Despite all of these added abilities, the Pow- R-Command 100 SOAP server is not intended to completely program an entire system. In order to program all nodes and associated inputs, outputs, groups, time schedules, and holidays the Lighting Optimization Software is required. For more information on the Lighting Optimization Software, please see Technical Document TD E. SOAP Server IP Address: Typical Web Service Directory Language (WSDL) File <?xml version="1.0" encoding="utf-8"?> <!-- This is a WSDL description of the CH web services API. --> <definitions XMLSchema"> Network Access Device (Ethernet Server Shown In Figure) Ethernet Over CAT5 Cable Max Distance 300-Feet From Hub/Router Workstation With Lighting Optimization Software targetnamespace="urn:hisolutions" xmlns=" xmlns:his="urn:hisolutions" xmlns:soap=" xmlns:xsd=" xml:lang="en"> <!-- Schema defining complex elements and data types --> <types> <documentation>this section contains a schema for all the custom data types and/or custom elements needed for the messages to be passed back and forth in this web services definition. Even though everything in this schema breaks down into just collections of strings and booleans, every element that contains others needs to be defined as a type. </documentation> <schema targetnamespace="urn:hisolutions" xmlns=" <complextype name="statuslist"> Figure 8: Network With SOAP Server, IP Addresses, & WSDL File. Figure Is For Illustration Purposes Only SOAP Server & WSDL As described in this document, in order for a SOAP clients s messages to be understood, there has to be a standard for actions available and format for request at the SOAP server. This standard is created in a Web Service Director Language (WSDL) file loaded onto the SOAP server. To the date of this document, a standard WSDL file has not been created for and by the HVAC & lighting control industry. However, Eaton s Cutler- Hammer has developed a WSDL file for the SOAP server, which provides the ability to carry out & understand commands described in this document. This WSDL file is loaded onto the SOAP server prior to installation. With this WSDL file, integrators can create SOAP clients to communicate with SOAP server. A copy of the SOAP server WSDL file is available upon request.

11 Page 11 Effective: July 2003 Applications For A Pow-R-Command 100 SOAP Server The applications for the Pow-R-Command 100 SOAP server are numerous, and are being discovered as the market is educated on the potentials of using SOAP based communication. However, one application is obvious and already in practice. This application is the ability to remotely monitor and command the system in a rich graphic environment without the need for software on each client machine. Traditionally, when an application called for the use of custom graphic screens, the Custom Graphic Screens and Data Logging Software (See Technical Document TD E) was sold. If that application also called out for the ability to display those graphic screens and the data behind them on remote terminals, the Web Server Software (See Technical Document TD E) was sold. All of these software components were loaded onto one server, which was called upon by multiple clients. Each of these clients could view the data from the server in a standard Web Browser, and would not need any resident Pow-R- Command 100 software to do so. Figure 9 illustrates the application using Custom Graphic Screens & Data Logging Software as well as the Web Server Software. Network 1 Facility 1 Network Access Device IP Address: (Ethernet Server Shown In Figure) RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device Network 1 Facility 2 Network Access Device IP Address: (Ethernet Server Shown In Figure) RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device Workstation & Server. Installed On PC Is Lighting Optimization, Custom Graphics Screens & Data Logging, and Web Server Software Packages IP Address: Ethernet Wireless Access Point IP Address: User Type: Maintenance IP Address: Client Application: Microsoft Internet Explorer User Type: Maintenance IP Address: Client Application: Microsoft Internet Explorer User Type: Maintenance IP Address: Client Application: Microsoft Internet Explorer User Type: Engineering IP Address: Client Application: Microsoft Internet Explorer User Type: Sales IP Address: Client Application: Microsoft Internet Explorer User Type: Facility Management IP Address: Client Application: Microsoft Internet Explorer Figure 9: Remote Access To Networks Using Software & Server

12 Page 12 Effective: July 2003 Looking at the traditional approach to this application, there are a great deal of software packages necessary. In addition, the Web Server Software is only designed to display data on a Web Browser. In order to simplify this and to allow applications other then Web Browsers to receive/send data, a Pow-R- Command 100 SOAP server would be used. For this a Web Page or a spreadsheet (from Microsoft Excel) would be created and programmed as a SOAP client. Inside the Web page or spreadsheet would be a series of elements, which are based on data from the system. To update the state of the elements, the client program could either be modified to automatically poll the system or allow the user to enter a command to poll the system. Each time an update occurs, the SOAP client sends a request to the SOAP server, which in turn either retrieves the data from, or sends a command to, the network device. Once this action has been carried out, the SOAP server would send a SOAP formatted response back to the SOAP client. The response would either contain a confirmation that the command had been carried out or the data the client originally requested. All graphics used to display this data would be created by the system/web developer for the facility or a third part integrator. Like before, each of the clients would not require any resident Pow-R- Command 100 software. In addition, there would be no need for the Pow-R-Command 100 Custom Graphic Screens & Data Logging Software, Web Server Software, or a PC to act as a PRC100 server. Figure 10 illustrates the application using the SOAP Server. Network 1 Facility 1 Network Access Device IP Address: (Ethernet Server Shown In Figure) RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device Network 1 Facility 2 Network Access Device IP Address: (Ethernet Server Shown In Figure) RS-485 Network On Twisted Shielded Network Cable Max Network Distance 4,000-Feet From Network Access Device SOAP Server IP Address: SOAP Server IP Address: Workstation. Installed On PC Is Only Pow-R-Command 100 Lighting Optimization Ethernet Wireless Access Point IP Address: User Type: Maintenance IP Address: SOAP Client: Custom Maintenance Application User Type: Maintenance IP Address: SOAP Client: Custom Maintenance Application User Type: Maintenance IP Address: SOAP Client: Microsoft Internet Explorer User Type: Engineering IP Address: SOAP Client: Custom Design & Control Application User Type: Sales IP Address: SOAP Client: Microsoft Internet Explorer User Type: Facility Management IP Address: SOAP Client: Custom Facility Management Application Figure 10: Remote Access To Networks Using SOAP Server

13 Page 13 Effective: July 2003 Start-Up When Using A SOAP Server When a system is purchased and installed in a facility, a factory authorized technician is sent to the job site. The technician programs all nodes and checks to make sure the installation of the network is correct. The technician can also provide training for the facilities maintenance staff for all system components. When a SOAP Server is purchased, the Cutler- Hammer technician will only program, troubleshoot, & train on Pow-R-Command 100 system components. Cutler-Hammer does not provide start-up and integration for SOAP based communication. However, if required start-up time can be purchased to assist an integrator with establishing communication to/from the Pow-R-Command 100 system through the SOAP Server. Notable Standards Being Built Around SOAP & XML As mentioned, the use of SOAP and specifically XML is widespread. Currently, there are two very notable standards being constructed around SOAP & XML. The first of these standards involves a previous standard well known to the integration industry. This standards is OLE for Process Control or OPC. Currently, OPC is based on Microsoft s DCOM model, but is progressing towards an XML version of the OPC standard. Currently the Pow-R- Command 100 system has an optional OPC server available for use with a system. For more information on the Pow-R-Command 100 OPC Server please see Technical Document TD E. The second is a standard being developed by Microsoft, which is known as a.net architecture. In the most basic terms, the Microsoft.Net standard creates a model, tools, and standards for efficiently communicating. The.Net architecture uses technologies like XML and adds them to other standards and distributed network models to form a very powerful platform for all applications to communicate across. Part of the.net architecture can be seen on many Web Sites for use with security and user identification. For more information on Microsoft s.net architecture please visit In many situations, integrators will use development tools designed for.net applications to establish communication with the Pow-R- Command 100 SOAP Server.

14 Page 14 Effective: July 2003 Pow-R-Command Technical Resource Library For additional information on Networks and components, please refer to the appropriate Technical Document. As of the date of this document, Technical Documents for the System are as follows: Title: PRC100-System Overview PRC100-Switch Override Controller PRC100-Telephone Override Controller PRC100-Universal System Controller & Enclosures PRC100-Networking PRC100-Lighting Optimization Software PRC100-Human Machine Interfaces PRC100-JCI-100 Controller PRC100-Protocol Exchanges PRC V dc Dimming Electronic Ballasts Control PRC100-OPC Server PRC100-SOAP Server PRC100-Custom Graphics & Data Logging PRC100-Web Server Software PRC100-Universal I/O Module PRC100-Six-Channel Relay Output Card PRC100-Network Signal Repeaters Publication Number TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E TD E For the most current list of documents on the system, and available downloads, please visit Eaton Corporation Cutler-Hammer business unit 1000 Cherrington Parkway Moon Township, PA United States tel: Eaton Corporation All Rights Reserved Printed In USA Form No. TD E