Is this newscast in our future?
The PGSI isn’t a reality today, but the collapse of the northeast power grid on August 14, 2003 is an indicator to some that a higher level of utility automation system integration is warranted. The concept of a real-time stability measuring stick is an extreme example of what the future holds for sharing information between utilities and the public, but today’s real-time automation systems are poised to benefit significantly from modern integration technologies, technologies already embraced by the realtime world of IT. This article examines how utility automation systems will benefit from XML Web Services integration technology. For the purposes of this article, a real-time automation system is defined as any utility system expected to process and respond at or near actual event time. Some will argue that in the nottoo- distant future this definition may well include virtually every utility computer system and process.
What are XML Web Services?
“Web Services” is actually a catchall name for any integration friendly software application created using a new set of standards developed to allow software services to be shared across large-scale distributed computing systems. Even though the name implies the use of the Internet, the standards and the resulting integration technologies provide robust machine-to-machine and system-to-system connectivity solutions being embraced at the department, inter-department, and enterprise level on private corporate networks.
At the core of XML Web Services, and one of the most important standards used in the creation of a web service, is the Simple Object Access Protocol (SOAP). SOAP is a vendor neutral integration protocol that standardizes network communications between software applications. Simply stated, SOAP is a general-purpose protocol for sending messages from one software application to another. The power of SOAP is that it can be used to invoke remote procedures between systems in a standard way that is platform, programming language and geographic location independent.
A second standard and a valuable component of web services is the Web Services Description Language (WSDL). WSDL is used to “expose” data sources to data consumers without a need to address or understand the differences between the participating systems.
A powerful integration tool known as the WSDL file, programmatically describes an interface to a private and often proprietary system. The WSDL file acts as a published rulebook for accessing valuable data sources. In some ways it acts as a contract or agreement between a data producer and a data consumer. A web service publishes an agreement – in effect it tells dissimilar computer systems, “I have this core functionality and data to offer, if you will request it in this way”. The powerful result is a loosely coupled and secure relationship between the data source and the data consumer.
A third specification, one that is growing in value in the software development and integration community is UDDI (Universal Description, Discovery and Integration). The UDDI specification enables businesses to publish electronic information about their core business as well as information about web services the company hosts. The three software giants, IBM, Microsoft and HP each host their own public UDDI registry for the benefit of their customers and synchronize their content with each other on a regular basis. The use of UDDI as a centralized repository of web service descriptions, including published locations of WSDL files is expected to play a significant role in ecommerce on the public Internet and is positioned to play a vital role inside corporations with large private intranets. UDDI will likely play a significant role in private and public utility integration schemes.
These three standards; SOAP,WSDL and UDDI come together to create XML Web Services.The result is robust, real-time integration between software applications.
Most real-time systems are still islands of automation and information silos.
Until just a few short years ago, almost every component of real-time systems, from the individual hardware components, to the protocols used for system communications were built on proprietary technologies. This is due in part, to the mission critical nature of utility automation systems and a genuine need to perform reliably in real-time with the utmost regard for safety. Historically, everything from remote terminal units to operator consoles was sole-sourced from the original vendor. In recent years, significant effort has been put into standardizing many aspects of automation systems. One only needs to look at the speedy adoption of DNP 3.0 as the de-facto standard protocol for SCADA system communications to see that significant benefits can come from standardization. Even though standardization is taking place, the motivating reason for embracing standards has not been to turn systems into powerful sources of business information through large-scale integration. Very few utility automation standards have originated from a desire to share information or functionality with other utility business applications, channel partners or competing utilities. Instead, most standardization work has been to create an open and more competitive procurement process.
Automation Systems will become data providers in a larger information network.
Today, there are many different automation systems operated by every utility. Many more systems are deployed across the landscape that makes up our tightly coupled power grid. One of the challenges for utilities, system managers, and IT departments is that there has never been cost effective, standards-based integration connecting these mission critical systems to each other and to corporate information systems. Ideally, utilities need to transform their mission critical systems into real-time data sources that can co-exist with and support the growing information requirements of not only the local utility, but the interconnected network of utilities and customer base.
The IT world knows all too well that legacy systems and disparate data platforms are too valuable to toss out or rebuild. Rarely is an enterprise- class business system dumped because a newer, more robust system comes along. Instead, the IT solution is to provide robust integration capabilities that squeeze even more value out of those critical business systems. Innovative technologies are migrated into the enterprise and are expected to co-exist with the systems already in use. Legacy automation systems also represent significant capital investments, not easily abandoned and replaced. Automation vendors can now play by the same rules as IT and use modern integration technologies to transform closed automation systems into open, real-time data providers. By leveraging the power of XML Web Services, utility engineers and system operators will be able to provide access to disparate automation system data sources in the same way, using the same technology, the IT world is using to deliver access to disparate corporate data centers and legacy business systems.
XML Web Services offer loosely coupled, system-to-system integration.
The ability of one computer system to “describe” its capabilities and available services to another is one of the most important benefits of XML Web Services. This important feature helps guarantee loosely coupled, system-to-system integration.
Example: SCADA systems are highly tuned, complex systems designed from the ground up to deliver a real-time view of a power system to skilled system operators. It is also true that some (not necessarily all) of the real-time information collected by a SCADA system has significant value to many other computing systems inside and outside of a typical utility. For this example, let’s imagine an external system or entity would benefit from knowing the status and availability of every transmission line operated in a utility’s service area. For this example, no distinction needs to be made between external systems owned by the utility and systems owned by third parties.
An interface needs to be implemented between the SCADA system and the system interested in accessing this vital status information. XML Web Services is an integration solution that will allow the owner of the SCADA system to publish a realtime interface without regard for the external system. It is important to remember the role of the Web Services Description Language (WSDL). The WSDL file is a published rulebook (specific to the provider system) that makes the announcement; “I have this core functionality and data to offer, if you will request it in this way”. Armed with this digital rulebook and proper authorization, any third party software provider can make sanctioned, real-time requests (remote procedure calls) to the SCADA platform.
The problems solved by using web services integration are not trivial. The loosely coupled nature of this standardized method of integration allows the SCADA system owner or the third party to make upgrades and changes to their own system without impacting the other system. Third party systems won’t be affected if and when the SCADA system is upgraded or replaced. The original functionality will be provided by the new SCADA system and any additional functionality will be described to the third party system via the WSDL file.
Accurate and automated responses will force system- to-system integration.
System operators of real-time automation systems almost always have access to pieces of information that help explain or identify the reasons for certain activities on a system. Published maintenance schedules, for example, and verbal communication with field crews prepare system operators to treat an open transmission line as a normal condition, instead of treating the condition as an emergency. The cascading blackout of 2003 may be providing proof that knowledge about local system conditions is not enough information to properly manage a dynamic, highly connected power grid. Many other examples exist that show significant value can come from real-time, machine-to-machine or process-to-process integration at the local utility level and the wide area network level.
The multiple sources of information made available to system operators helps to guarantee accurate responses to system events. Not every system event is an emergency, but most require immediate analysis and quick action. In some cases, the proper action may be to do nothing at all. Let’s revisit the example of a third party system monitoring the real-time status of transmission lines. In reality, a real-time alert of a transmission line being out of service is probably not enough information for most systems to work with. Other pieces of data would normally be required to derive any useful information about the condition. How long will the line be out of service? Was it scheduled and accounted for in other areas of the system? These are valuable pieces of “big picture” information, not often provided in a single realtime data stream.
Only the third party entity knows for sure what information is required in order to perform their function. An automation system owner does not need to know what is done with data collected via a real-time XML web service. Web services will allow third parties to submit ad-hoc real-time queries to multiple automation systems, work management systems, any system in fact that helps provide a computerized big picture.
Integration is a two-way street. Will utilities want to integrate with customer owned systems?
The obvious answer to this question is yes. Many techniques are used by utilities to achieve higher levels of interaction with customers and their systems. Everything from utility owned control devices to meters fitted with signaling equipment are used to interface with energy consuming equipment. Even the time tested telephone call to enterprise energy managers is slowly being replaced by email alerts and web page bulletin boards. History also shows that utility companies appreciate two-way communications to obtain feedback from systems. Real-time feedback can be a helpful tool for gauging the success or failure of a particular program. In light of all this history and with so many programs continuing today, it would be hard to imagine a utility not wanting to integrate with a customer system if given the opportunity.
The not so obvious answer may be that a highly integrated information network will give customers enough information to make informed decisions about energy use that they were never able to make before. Significant advancements are being made in the world of industrial, commercial and residential automation. The standardization of protocols and the acceptance of networking technologies like Ethernet, wireless and TCP/IP in automation environments is making it easier and easier to create a web of services that could ultimately result in coordinated programs between utilities and their customers. Web Services integration has the potential to do away with proprietary black boxes that interrupt power at the worst possible time.
But what about security?
Unfortunately it will probably always be true that critical data and critical systems will be the targets of individuals interested in doing harm. For this reason, the standard concerns and all the safeguards normally associated with networking need to apply to XML Web Services. Modern integration technologies, including XML Web Services can help create important lines of demarcation between mission critical systems and the external network. The days of giving unfettered access to databases (e.g. ODBC and SQL) are probably behind us. Only data elements should be passed over the demarcation line, not important hints about the structure of the database or the system.
The capabilities of a web service interface need to match the requirements of the integrated network. There is no reason to publish a bi-directional interface with control capabilities if the goal of the integration is to create a read-only data source. On the other hand, if two-way access is required, the highest level of care in all areas of security is warranted. The power of web services needs to be respected and hopefully understood by the provider. Some individuals may argue that the layers of security imposed by the IT community far out weigh the work being done to add security to some automation protocols like Modbus™ or DNP 3.0, but that hot topic is material for future articles.
Conclusion
Modern integration technologies, including XML Web Services are being made available to utility automation designers and managers at a time when utility business managers, customer care representatives, Regulators and even John Q. Public are demanding real-time information about the state of the power grid. Even if a Power Grid Stability Index isn’t in our immediate future, deregulation and the changing relationships between energy producer, seller, deliverer, buyer and user are creating a need for integration that has never been considered before. Given the availability of the Internet and the connected world we are all growing accustomed to, we have the potential to create an information and control network that extends from the power plant to our pop-up toasters. One can quickly see how the standards behind XML Web Services; including SOAP, WSDL and UDDI are poised to have a significant impact on existing and future utility automation systems.
- The temperature in New England today will be above normal, with highs expected in the upper 90’s.
- The Power Grid Stability Index (PGSI) is expected to hold steady today at 85, down 10 points from yesterday due to increased load on the grid and scheduled transmission line maintenance in northern Ohio.
The PGSI isn’t a reality today, but the collapse of the northeast power grid on August 14, 2003 is an indicator to some that a higher level of utility automation system integration is warranted. The concept of a real-time stability measuring stick is an extreme example of what the future holds for sharing information between utilities and the public, but today’s real-time automation systems are poised to benefit significantly from modern integration technologies, technologies already embraced by the realtime world of IT. This article examines how utility automation systems will benefit from XML Web Services integration technology. For the purposes of this article, a real-time automation system is defined as any utility system expected to process and respond at or near actual event time. Some will argue that in the nottoo- distant future this definition may well include virtually every utility computer system and process.
What are XML Web Services?
“Web Services” is actually a catchall name for any integration friendly software application created using a new set of standards developed to allow software services to be shared across large-scale distributed computing systems. Even though the name implies the use of the Internet, the standards and the resulting integration technologies provide robust machine-to-machine and system-to-system connectivity solutions being embraced at the department, inter-department, and enterprise level on private corporate networks.
At the core of XML Web Services, and one of the most important standards used in the creation of a web service, is the Simple Object Access Protocol (SOAP). SOAP is a vendor neutral integration protocol that standardizes network communications between software applications. Simply stated, SOAP is a general-purpose protocol for sending messages from one software application to another. The power of SOAP is that it can be used to invoke remote procedures between systems in a standard way that is platform, programming language and geographic location independent.
A second standard and a valuable component of web services is the Web Services Description Language (WSDL). WSDL is used to “expose” data sources to data consumers without a need to address or understand the differences between the participating systems.
A powerful integration tool known as the WSDL file, programmatically describes an interface to a private and often proprietary system. The WSDL file acts as a published rulebook for accessing valuable data sources. In some ways it acts as a contract or agreement between a data producer and a data consumer. A web service publishes an agreement – in effect it tells dissimilar computer systems, “I have this core functionality and data to offer, if you will request it in this way”. The powerful result is a loosely coupled and secure relationship between the data source and the data consumer.
A third specification, one that is growing in value in the software development and integration community is UDDI (Universal Description, Discovery and Integration). The UDDI specification enables businesses to publish electronic information about their core business as well as information about web services the company hosts. The three software giants, IBM, Microsoft and HP each host their own public UDDI registry for the benefit of their customers and synchronize their content with each other on a regular basis. The use of UDDI as a centralized repository of web service descriptions, including published locations of WSDL files is expected to play a significant role in ecommerce on the public Internet and is positioned to play a vital role inside corporations with large private intranets. UDDI will likely play a significant role in private and public utility integration schemes.
These three standards; SOAP,WSDL and UDDI come together to create XML Web Services.The result is robust, real-time integration between software applications.
Most real-time systems are still islands of automation and information silos.
Until just a few short years ago, almost every component of real-time systems, from the individual hardware components, to the protocols used for system communications were built on proprietary technologies. This is due in part, to the mission critical nature of utility automation systems and a genuine need to perform reliably in real-time with the utmost regard for safety. Historically, everything from remote terminal units to operator consoles was sole-sourced from the original vendor. In recent years, significant effort has been put into standardizing many aspects of automation systems. One only needs to look at the speedy adoption of DNP 3.0 as the de-facto standard protocol for SCADA system communications to see that significant benefits can come from standardization. Even though standardization is taking place, the motivating reason for embracing standards has not been to turn systems into powerful sources of business information through large-scale integration. Very few utility automation standards have originated from a desire to share information or functionality with other utility business applications, channel partners or competing utilities. Instead, most standardization work has been to create an open and more competitive procurement process.
Automation Systems will become data providers in a larger information network.
Today, there are many different automation systems operated by every utility. Many more systems are deployed across the landscape that makes up our tightly coupled power grid. One of the challenges for utilities, system managers, and IT departments is that there has never been cost effective, standards-based integration connecting these mission critical systems to each other and to corporate information systems. Ideally, utilities need to transform their mission critical systems into real-time data sources that can co-exist with and support the growing information requirements of not only the local utility, but the interconnected network of utilities and customer base.
The IT world knows all too well that legacy systems and disparate data platforms are too valuable to toss out or rebuild. Rarely is an enterprise- class business system dumped because a newer, more robust system comes along. Instead, the IT solution is to provide robust integration capabilities that squeeze even more value out of those critical business systems. Innovative technologies are migrated into the enterprise and are expected to co-exist with the systems already in use. Legacy automation systems also represent significant capital investments, not easily abandoned and replaced. Automation vendors can now play by the same rules as IT and use modern integration technologies to transform closed automation systems into open, real-time data providers. By leveraging the power of XML Web Services, utility engineers and system operators will be able to provide access to disparate automation system data sources in the same way, using the same technology, the IT world is using to deliver access to disparate corporate data centers and legacy business systems.
XML Web Services offer loosely coupled, system-to-system integration.
The ability of one computer system to “describe” its capabilities and available services to another is one of the most important benefits of XML Web Services. This important feature helps guarantee loosely coupled, system-to-system integration.
Example: SCADA systems are highly tuned, complex systems designed from the ground up to deliver a real-time view of a power system to skilled system operators. It is also true that some (not necessarily all) of the real-time information collected by a SCADA system has significant value to many other computing systems inside and outside of a typical utility. For this example, let’s imagine an external system or entity would benefit from knowing the status and availability of every transmission line operated in a utility’s service area. For this example, no distinction needs to be made between external systems owned by the utility and systems owned by third parties.
An interface needs to be implemented between the SCADA system and the system interested in accessing this vital status information. XML Web Services is an integration solution that will allow the owner of the SCADA system to publish a realtime interface without regard for the external system. It is important to remember the role of the Web Services Description Language (WSDL). The WSDL file is a published rulebook (specific to the provider system) that makes the announcement; “I have this core functionality and data to offer, if you will request it in this way”. Armed with this digital rulebook and proper authorization, any third party software provider can make sanctioned, real-time requests (remote procedure calls) to the SCADA platform.
The problems solved by using web services integration are not trivial. The loosely coupled nature of this standardized method of integration allows the SCADA system owner or the third party to make upgrades and changes to their own system without impacting the other system. Third party systems won’t be affected if and when the SCADA system is upgraded or replaced. The original functionality will be provided by the new SCADA system and any additional functionality will be described to the third party system via the WSDL file.
Accurate and automated responses will force system- to-system integration.
System operators of real-time automation systems almost always have access to pieces of information that help explain or identify the reasons for certain activities on a system. Published maintenance schedules, for example, and verbal communication with field crews prepare system operators to treat an open transmission line as a normal condition, instead of treating the condition as an emergency. The cascading blackout of 2003 may be providing proof that knowledge about local system conditions is not enough information to properly manage a dynamic, highly connected power grid. Many other examples exist that show significant value can come from real-time, machine-to-machine or process-to-process integration at the local utility level and the wide area network level.
The multiple sources of information made available to system operators helps to guarantee accurate responses to system events. Not every system event is an emergency, but most require immediate analysis and quick action. In some cases, the proper action may be to do nothing at all. Let’s revisit the example of a third party system monitoring the real-time status of transmission lines. In reality, a real-time alert of a transmission line being out of service is probably not enough information for most systems to work with. Other pieces of data would normally be required to derive any useful information about the condition. How long will the line be out of service? Was it scheduled and accounted for in other areas of the system? These are valuable pieces of “big picture” information, not often provided in a single realtime data stream.
Only the third party entity knows for sure what information is required in order to perform their function. An automation system owner does not need to know what is done with data collected via a real-time XML web service. Web services will allow third parties to submit ad-hoc real-time queries to multiple automation systems, work management systems, any system in fact that helps provide a computerized big picture.
Integration is a two-way street. Will utilities want to integrate with customer owned systems?
The obvious answer to this question is yes. Many techniques are used by utilities to achieve higher levels of interaction with customers and their systems. Everything from utility owned control devices to meters fitted with signaling equipment are used to interface with energy consuming equipment. Even the time tested telephone call to enterprise energy managers is slowly being replaced by email alerts and web page bulletin boards. History also shows that utility companies appreciate two-way communications to obtain feedback from systems. Real-time feedback can be a helpful tool for gauging the success or failure of a particular program. In light of all this history and with so many programs continuing today, it would be hard to imagine a utility not wanting to integrate with a customer system if given the opportunity.
The not so obvious answer may be that a highly integrated information network will give customers enough information to make informed decisions about energy use that they were never able to make before. Significant advancements are being made in the world of industrial, commercial and residential automation. The standardization of protocols and the acceptance of networking technologies like Ethernet, wireless and TCP/IP in automation environments is making it easier and easier to create a web of services that could ultimately result in coordinated programs between utilities and their customers. Web Services integration has the potential to do away with proprietary black boxes that interrupt power at the worst possible time.
But what about security?
Unfortunately it will probably always be true that critical data and critical systems will be the targets of individuals interested in doing harm. For this reason, the standard concerns and all the safeguards normally associated with networking need to apply to XML Web Services. Modern integration technologies, including XML Web Services can help create important lines of demarcation between mission critical systems and the external network. The days of giving unfettered access to databases (e.g. ODBC and SQL) are probably behind us. Only data elements should be passed over the demarcation line, not important hints about the structure of the database or the system.
The capabilities of a web service interface need to match the requirements of the integrated network. There is no reason to publish a bi-directional interface with control capabilities if the goal of the integration is to create a read-only data source. On the other hand, if two-way access is required, the highest level of care in all areas of security is warranted. The power of web services needs to be respected and hopefully understood by the provider. Some individuals may argue that the layers of security imposed by the IT community far out weigh the work being done to add security to some automation protocols like Modbus™ or DNP 3.0, but that hot topic is material for future articles.
Conclusion
Modern integration technologies, including XML Web Services are being made available to utility automation designers and managers at a time when utility business managers, customer care representatives, Regulators and even John Q. Public are demanding real-time information about the state of the power grid. Even if a Power Grid Stability Index isn’t in our immediate future, deregulation and the changing relationships between energy producer, seller, deliverer, buyer and user are creating a need for integration that has never been considered before. Given the availability of the Internet and the connected world we are all growing accustomed to, we have the potential to create an information and control network that extends from the power plant to our pop-up toasters. One can quickly see how the standards behind XML Web Services; including SOAP, WSDL and UDDI are poised to have a significant impact on existing and future utility automation systems.
